Tell me if you’ve heard the story before. You’re in a startup and it’s growing. At some point, the pain of work gets to be too much. People say things like “This can’t continue!” after their seventh all-nighter in so many weeks. Tasks fall through the cracks. Deployments go wrong for totally preventable reasons. Your entire team sees the writing on the wall: we’ve got to change the process.
So, you do what many managers have done in your shoes, and you change the process! Your people eagerly go along with the changes, because things are too painful to continue the way they are. And your job does get better. For now.
Months pass, business picks up and then you — the smart, more experienced manager that you are — well, you begin to think: I can predict where this is going. We’re doing twice as much work as we were six months ago, and hiring is picking up with a three month lag. In four to six months, the current process is going to break down again because we’ll have nearly doubled the team. Wouldn’t it be better to start a process change now?
This time, however, the team is less pleased with the idea. They don’t see the changes that you see coming on the horizon, because they don’t have your context. “I don’t think this is a good idea,” says Gruff Adam. (Every team has a Gruff Adam). He gives reasons. Half the team looks unconvinced.
What do you do? Push through? How do you get your team on board with the changes you want to implement? How do you do this without seeming like a total tool?
Lens One: Where’s the Pain?
I’ve discovered three valuable ways to look at process change that I think is worth talking about. The first way is to look at process change through the lens of pain: pain before the change, pain making the change, and pain after the change.
In the first scenario above, there was a lot of pain before the process change. This often makes initiating a change trivially easy: everyone is in such a bad state that they’re willing to try anything to make it stop, anything at all, as quickly as possible.
In the second scenario, however, the pain from making the change overwhelms the perceived pain from status quo. People are unconvinced, because they think that the temporary pain they’ll have to go through while changing their workflow isn’t justified. You’ll have to do a lot more work in order to get them to move.
Finally, if a process change results in new kinds of pain after switching, then you might find yourself with a mutiny on your hands. You must always monitor any process change for teething problems; not doing so risks three things: first, it risks your team’s willingness to try new process changes in the future, second, it may result in general workplace unhappiness, and third, it may result in markedly lower output of your team — which implies that you have not been doing your job.
I don’t want to understate how risky these three side effects are. Imagine that you are a designer, and that you are used to working with the software tool Sketch. You come in to work and your boss tells you that you must switch to a new suite of internal tools, with no proper explanation. These tools are inferior to Sketch, but your boss ignores your complaints, and reminds you that the busiest part of the year is coming up, and that you should hurry up and master the new tool.
How are you going to feel? Terrible, that’s what. Every hour that you spend at work would be excruciatingly stressful. If a couple of weeks go by and nothing changes, if you feel like your boss isn’t listening to your concerns, then chances are good that you’re going to quit. At the very least, you would distrust future process changes mandated from the top down; your output at work would also be drastically affected.
As a manager, put yourself in your subordinates’s shoes. You wouldn’t like your boss to make drastic changes to your work life, and you wouldn’t be happy if it seemed like she wasn’t listening to you. So don’t do these things when taking on a process change. Instead …
Lens Two: Tell Them What and Why Before, During and After
The second lens is the fundamental formula for doing process change. It consists of three steps:
- Before doing the process change, tell them what’s going to happen, and why. This is the part where you may encounter resistance, depending on the relative levels of pain before and during the change. Listen carefully, and make tweaks if the complaints are legitimate. More on this in a bit.
- During the change, spend a non-trivial amount of time prodding to get the action to stick. At the same time, listen carefully — through your regularly scheduled one-on-ones, perhaps! — to see if the process change is resulting in new problems. If they are, tweak the process change by announcing what you’ve noticed, what you’re going to change about it, and why.
- After the process change has taken, spend a small amount of time monitoring the output of your team, and the potential problems from this change. Once people accept it as ‘the way things are done here’, you may stop.
A couple of quick notes here.
First, why is explaining things before you change so important? Well, put yourself in your subordinate's shoes. As a general rule, people dislike random changes. They prefer things to be predictable. Giving them a heads-up and explaining why you think this is necessary is a way of giving them a semblance of control over their environment. At the very least, they know what’s going to happen, so they can anticipate the possible changes to their work.
Second, what should you do if you encounter resistance in step one?
In general, the more painful the proposed process change, the more difficult the resistance you have to overcome. You have three tools at your disposal here: first, you can play up the future pain that you want to avoid. A reasonable team should be convinced by your presentation, especially if the coming pain affects them directly. Second, you can find ways to reduce the pain of your proposal — perhaps by asking for tweaks to your suggested process. I’ve found that saying: “These are good concerns, how can we reduce that difficulty while still preventing the pain X?” to be a good way to elicit constructive criticism from my team. Third, and last, you can rely on your positional power to push things through. This last option is obviously the nuclear one, and in principle I think that you should not use it often. But I also believe that some situations merit using your authority; these are often situations where the pain is so vague so as to be difficult to convince your team of.
I know this sounds ridiculous in the abstract, so here’s a concrete example: I once used my positional power to push through a process change for our sales people. If a sales person wanted some customisation done, he or she would need to fill in a form describing the business context, instead of just describing the feature itself. This was because salespeople often filled in suggestions like “put a button here” — which was a terrible idea given their lack of design or product experience. I forced them to do this against their will; my arguments were never convincing to them, partly because they were not incentivised to think of the future engineering costs to our product.
So, one last question. How much time should you spend on designing your process change, getting buy in, talking it over with your team, etc, before carrying it out?
Lens Three: Reversible and Irreversible Decisions
The third lens is to ask yourself if the process change is reversible. If it is, then you're probably better off moving to step two — implementation! — while making it clear to your team that if things don't work out, you can always go back to the way things were before.
The original form of this idea was from Amazon CEO Jeff Bezos. In his 2015 shareholder letter, Bezos wrote:
Some decisions are consequential and irreversible or nearly irreversible — one-way doors — and these decisions must be made methodically, carefully, slowly, with great deliberation and consultation. If you walk through and don’t like what you see on the other side, you can’t get back to where you were before. We can call these Type 1 decisions.
But most decisions aren’t like that — they are changeable, reversible — they’re two-way doors. If you’ve made a suboptimal Type 2 decision, you don’t have to live with the consequences for that long. You can reopen the door and go back through. Type 2 decisions can and should be made quickly by high judgment individuals or small groups.
As organisations get larger, there seems to be a tendency to use the heavy-weight Type 1 decision-making process on most decisions, including many Type 2 decisions. The end result of this is slowness, unthoughtful risk aversion, failure to experiment sufficiently, and consequently diminished invention*. We’ll have to figure out how to fight that tendency.
*The opposite situation is less interesting and there is undoubtedly some survivorship bias. Any companies that habitually use the light-weight Type 2 decision-making process to make Type 1 decisions go extinct before they get large.
This common-sense rule tells us exactly how much deliberation we should spend in step one of the three step template for introducing process change.
I don't think I've ever heard it expressed as succinctly as Bezos puts it, but I do think the difference is quite clear when you're making decisions. I spent no more than a couple of days when pushing through a process change for our code reviews, but I spent nearly two months when working out changes for our compensation structure.
Takeaways
The worst case scenario when making a process change is to have it fail so badly that your team automatically associates future changes with Bad Things.
The best case scenario is when a process change goes off without a hitch, and you earn brownie points from your subordinates as a responsible, attentive steward of output.
The key idea behind these three lenses is to simply see things through the eyes of your subordinates. Imagine how a process change might disrupt your work as an individual contributor. Imagine how bad it feels to have changes dropped down from on-high, with no feedback loop to correct these changes if things go badly. Imagine how powerless you might feel if your manager dictates change after change, without ever evaluating if each change sets in properly.
These three lenses have helped me greatly when it comes to evaluating and executing a potentially disruptive process change. I've used them to switch up our deployment process, to introduce code reviews to the entire engineering organisation, to create new promotions paths for our engineers, and to change compensation across the entire Vietnam office.
I'm hopeful that these three lenses help you as much as they’ve helped me. Process change is often rightfully dreaded. People dislike change, after all, and new, unproven processes can go wrong in many different ways. But, done well, they don't necessarily have to be scary. With these set of lenses, my hope is that you’ll be in good hands.
Listen to the related podcast episode here.