One of the challenges we face as engineering managers is how people react to process differently. Sometimes it’s like we’re talking about entirely different things – we propose something we expect to be lightweight, and people react like we’re instituting TPS reports or time-tracking in six minute intervals (normal for lawyers, everyone else: hell no).
Let’s talk about people
So, why do people react so differently to process? One significant variable is how people respond to expectations. I really love Gretchin Rubin’s framework on the topic: The Four Tendencies.
First, the difference between inner and outer expectations: inner expectations are those you set for yourself, while outer expectations are the things other people expect of you.
The framework categorizes people into four tendencies:
- Obligers respond to expectations from other people. They struggle meeting their own expectations.
- Upholders respond to all expectations – including those they set for themselves.
- Questioners question all expectations, and respond only to expectations they think make sense.
- Rebels resist all expectations.
If you’ve ever wondered about the elaborate strategies some people come up with to do things that come very easily to you, you’re probably an Upholder. If you love spreadsheets, you’re probably a Questioner. If you ever feel resentful that you’re doing everything everyone else wants, but nothing for yourself, you’re probably an Obliger (or a woman living in a patriarchal society). If you just want to be free, you probably won’t be reading about process, but you could be a Rebel.
This is relevant because when we’re trying to create change – and process is a form of change – we need other people to adopt it. In some ways, your process is an expectation that you need to set for your teammates, and this is a helpful framework for how people can, and will, respond to it.
Obligers are pretty good at accepting process (until they rebel, but that’s out of scope for this post). Upholders are a little more critical, but, as long as it doesn’t conflict with some other expectation, they will probably go with it. Questioners might adopt your process, but first you will have to answer all their questions satisfactorily, and Rebels are almost certainly going to resist your process. Don’t take that personally; Rebels resist everything.
Let’s talk about process
What even is ‘process’ anyway? One of the many dictionary definitions is: ‘to subject to or handle through an established usually routine set of procedures’. In other words, process is how we get things done in a consistent way.
Good process creates consistency that removes unnecessary decision-making and helps things move faster. Bad process removes creativity, stifles freedom, and adds unnecessary overheads through rigidity. Of course, we’re always striving to create the good kind of process, but we can get it wrong. We can also fail to suitably evolve process over time, or we can inherit bad processes. It’s always worth thinking critically about what we will gain – or lose – through changing process. Questioners can be relied upon to force us to think through that!
When considering organizational change, I think about three characteristics of process:
- Process as an agreement about how we work.
- Process as a way to answer questions.
- Process as culture.
Process as an agreement about how we work
Processes that function as an agreement about how we work help people to know what they can expect from each other (or in general).
For example, we might agree that we are doing code review in a certain way, using Git Flow, releasing every other Thursday. We might have agreements for what topics are covered in meetings, what can be asynchronous. We might have a process for how we approach taking vacation – what we communicate, where, and when.
In large organizations, that agreement is often enforced by more and more arduous processes, but in smaller companies, these are often lightweight and informal.. It might be enough to just state the agreement and ask people to adhere to it.
Process as a way to answer questions
Processes that function as a way to answer questions often centre on documenting and retrieving state.
For example, we might commit to certain formats for project updates, use certain tags to indicate the status of an issue, or have a shared calendar for important team events (meetings, releases, vacation).
As organisations grow, there’s more and more value to being able to consistently answer questions like, ‘who is working on this’, ‘how’s this going?’, ‘when might I expect it to be done?’ Particularly interesting to me are the processes that answer questions that might otherwise not get asked – for example, noting office hours for people in leadership answers the question of ‘when can I talk to $person?’.
Process as culture
Much like how evolution accentuates certain characteristics and eliminates others, processes that determine office culture often reinforce (or undermine) an organization’s stated values.
It might be how you structure meetings to make sure everyone speaks – or not. Or how a performance cycle promotes and supports a growth mindset and continuous improvement – or not. Processes that treat emergencies as emergencies and try to reduce them, or processes that reinforce a hero culture.
When process meets people
Process is often sold based on the ideal value it creates. Similarly, people may resist it because of perceived overhead. It typically always begins with an agreement about the problem that needs to be solved. In the end, many processes touch all of these aspects and in turn, these aspects can help create buy in. Some examples of processes I’ve introduced:
That time we started a daily standup
I once took over a team that was really struggling and, to my dismay, one of the issues that quickly became apparent was that I could not consistently expect people to show up for work. There was a high expectation of autonomy, no real management training, and an absence of typical norms, or HR processes. This created many issues, one being that people often felt so isolated that it seemed like no-one cared if they were making progress or not. If they were discouraged, they had no-one to turn to, and the next day it might just take them longer and longer to open the computer and try again.
One of the most impactful processes we put in place was asking people to do a daily standup, in text, at the start of their day.
- This helped make sure that people showed up to work each day as everyone was expected to post at least one message in the group chat. If they didn’t post, someone would notice.
- It answered the obvious question of ‘what are you doing today / what did you do yesterday’, but it also created insight into the question of ‘is this person stuck?’
- It was the start of shifting the culture to one where people communicated more, and helped each other more proactively.
Of course there was the expected pushback from people who just did not want accountability, but the most interesting pushback came from those who had high intrinsic motivation and high self-esteem. These people typically knew what they wanted to get done any given day and did it, and if they needed help they had people to turn to. To them, this process was an unnecessary overhead and they didn’t see the value of it or why it should apply to them.
It’s reasonable that people who are generally effective are resistant to processes that are designed to highlight – and address – ineffectiveness. Outlining the desired cultural norms beyond the process – more regular communication, better surfacing needs for help – was much more compelling to them than the process itself, and helped create buy-in. The real value of this process was that it created a foundational change in team communication, which led to many more interesting and impactful changes to come over time.
That time we scaled hiring
I spent 2019 leading a ‘developer experience; team. The main focus of the team was to scale up the hiring process to enable hiring 100 people a year. In 2018, around 30 people had been hired, so 100 was a big jump. Almost all of the people involved in hiring had stopped working on it, however, so the number was pretty irrelevant – it felt like we were starting from scratch. We had a hiring process that was minimally documented, and relied too heavily on individuals who frequently dropped out from participating because they were burnt out and/or resentful.
In Q1 of that year we managed to hire just 8 people. In Q3, we hired 25. What changed? So much process.
- Originally the agreement – which wasn’t sustainable – was for a few people to do a lot. We changed that agreement to one where a lot of people did a little. This improved so much. By making the work more manageable, we increased engagement and enjoyment. By removing 1:1 dependencies, we were able to eliminate bottlenecks and reduce time in the process. Anything incoming got allocated to someone with availability, whether it was an interview scheduled from an interviewer pool, or a code test allocated to a pool of code test reviewers.
- We removed the ambiguity. Instead of intense 1:1 training, we adopted consistent rubrics throughout and calibrated people against them. Every interview covered the same points and every code test evaluated the same things. This changed the question from ‘what do you think?’ to, ‘how does this interview/submission evaluate against the rubric?’ This was a much easier question for the interviewer to answer. Even better, this reduced subjectivity, making the process more fair and consistent, and improving confidence in the evaluation.
- We shifted the culture to make it clear that this work was visible and valued. We provided ongoing training and calibration, creating“‘review’ groups made up of people who were particularly great at interviewing, or reviewing code tests. Beyond providing support, we worked really hard to make sure people knew this work was appreciated. We adjusted and added process to support a culture of appreciation – crediting people involved in any new hire, and sending out quarterly tokens of appreciation, from custom swag to handwritten thank you cards.
This example is one huge process with many sub-processes, but the individual details of these are not that interesting. What was interesting was the north star of a scaled and sustainable process, and the core idea of many people (ideally everyone) doing a little. Ensuring all sub-process supported this goal was key. When I consider the missteps we made, the majority of them stemmed from forgetting this north star and being reactive, or succumbing to pressure.
That time we experimented (on each other)
Sometimes I’ve been lucky enough to take over teams that don’t have huge and pressing problems. This is invariably much less stressful, but one thing I’ve found is that teams without obvious and pressing problems can be more resistant to process.They think they are doing fine, so what could possibly need to change?
How do we even know how a team is doing? It’s much easier to measure a team’s progress than its state. When I want to get people out of this defensive mindset, I use the concept of ‘experiments’. ’Team experiments’ are designed to improve team dynamics or effectiveness. But… experiments themselves are a process (we track them, review them, and iterate).
- The concept of ‘experiments’ frames the agreement about process – the idea of testing things out. Not everything has to be perfect.
- The process question is reframed as ‘what could we try?, which is much less threatening.
- Experiments support a mindset of continuous improvement and openness to try things. Over time this mindset shifts the culture of the team.
In my current team, one of the areas where we have conducted a lot of ‘experiments’ is our onboarding process. It was clear when I joined that we weren’t doing a great job onboarding people, and so with each new person we hire, we try to make it a little better than it was for the person before. Every new hire conducts an ‘experiment’ on the next new hire, to address something that they felt could have been better in their own onboarding. This has included things like having 1:1s with every member of the team, having a welcome social event, and collecting bits of advice from people on the team for the new hire. But the best shift has been the mindset, because over time onboarding has become a collective team responsibility.
Process -> change
Real change is both individual and systematic. Process changes systems, and shifts in mindset change individuals. Addressing both together is key to creating meaningful organizational change. It doesn’t really matter what processes you execute if people don’t believe in them, and any mindset you create will be short-lived if it’s consistently undermined by process.
When approaching something that looks like a process problem, consider:
- What is the desired culture?
- Where is the ambiguity?
- How do we want to work together?
Constructing a narrative around identity can appeal to the Rebels, while clarifying ambiguity can be a way to connect to the Questioners. More consistent agreements about how we work together will help both Obligers and Upholders, because not only does it set a standard for them to aspire to, but it also helps them to understand what to expect from other people.
Creating process might be part of your job, but it’s not your job to create, or enforce, it. Process by itself does not create organisational change, but it is a valuable tool that, when executed properly, helps to drive things forward to where you want them to be.
