More processes being the answer to every problem often only causes more problems and an unhappy team. This is particularly prevalent in large companies, where there’s a natural tendency to create processes for every problem. Think of things like meetings, checklists, and being required to update documents or wikis. Individually they can make total sense, and no process at all can lead to problems too. However, it’s very easy to inadvertently accumulate too many of them, resulting in not enough real work getting done.
Imagine a situation where a small oversight by one person in a single project leads to the introduction of a checklist that every person must follow for future launches. Next, there’s a perception that people aren’t spending enough time on oncall, so they’re asked to post a summary of what they’ve done at the end of their oncall weeks and have a handover meeting. A few days later, a leader in the company reports a bug, and the team is asked to prevent it in future by having an extremely high level of test coverage before enabling anything. Continue this for a few more months, and you get the idea. On their own, every one of these decisions and processes can make sense. But the team has now evolved to have a complex web of guidelines, rules, meetings, and tasks that must be navigated before any real work gets done, diminishing productivity and just making people not enjoy their work.
A significant problem is the reaction to individual mistakes. Instead of first working with them to make improvements, entire groups are often burdened with more bureaucracy. Performance review systems can exacerbate this problem. Senior members of the team are expected to implement things that improve it, often receiving rewards for creating them. Resisting them doesn’t get you anything (“didn’t organise a meeting” doesn’t sound great) – people may even get negative feedback for resisting such changes, even if it’s in the team’s best interests.
Noticing when things have become overly burdensome can be challenging, as it slowly creeps up on you. A good approach is taking time off. When you return after a break, you’re generally thinking about the actual projects you’re getting back too. Instead you often find yourself wading through procedures like attending meetings, writing reports, and completing training, realising that you’re not much further forward at the end of the first few days back than when you started. Another effective method is to just ask members of a team what percentage of their time they spend doing these kinds of tasks. If it trends too high, determine which processes are genuinely useful, and remove the unnecessary ones.
As is often the case there is a big exception to this idea – that is where having a process for people to blame is useful, deflecting their blame away from individuals. For example, you could design a process where every severe outage has a review. The team gets together to decide how a similar problem can be prevented in future. The review isn’t anything out of the ordinary, or aimed at them in particular – it’s just everyone working through the process. Another exception is where things are legal requirements. The point here is to identify which are important, and remove or avoid the ones that aren’t.
Process paralysis isn’t fun for anyone. While any individual decision to add a new piece of process can make sense, it’s important to be cautious about the cumulative effect. When things go too far, find out which processes are valuable and either remove or make changes to the rest. And remember to reward people for the things they don’t do, not only for things they do.