When someone introduces a process it’s usually to help them. If top-level management introduces a process for people on the ground then there’s a danger it will help the top team at the expense of the people on the ground delivering effectively.
In our organisations we all want comprehensible processes. We want to be able to get on with our work, producing some kind of value, without worrying about the non-value aspects of what we do. That’s why it’s important for processes to be clear and comprehensible—easy to work with and within.
Sometimes it’s important that those processes are consistent from one area to another, so we can more easily join up information and activity. Related to that, having clear interfaces between areas is important—if two areas cannot be internally consistent, and least they can fit together well.
Traditionally process comes down from the top. The workers work, and the managers tell them how to work. The managers have an overview of work across several areas and can see the bigger picture. Making sure all the work contributes to the greater benefit of the organisation is certainly essential. So we end up with organisation-wide hiring processes, budget processes, and so on.
But when managers devise processes it’s typically tilted in their favour. This isn’t out of malice, but out of expediency. They want their lives to be simpler, so they make sure the processes are consistent. For example, they may want everyone to report in the same way so that they can compare different areas more easily.
However, seeking that consistency can too easily come at the cost of doing the work effectively. In tech teams that might mean an enforcement that all teams should estimate their stories in the same way, or account for their work in a way that best suits the executive team, or produce reports in the same format. This helps the managers, but it can be damaging to the team’s work and, consequently, to the organisation as a whole.
Scrum was daring when it proposed the idea of “self-organising teams”, giving them freedom to devise processes and working practices of their own, while ensuring they were responsible for the outcomes.
Recently I read about Hilcorp, which elevates this idea to the organisational level. The CEO explains:
I like to think of the business as a dog with a tail. The dog represents all the main sources of value creation at Hilcorp—the actual oil and gas fields and the asset teams working them every day, especially those people in the field who are closest to the wellhead. Everyone else is the tail, and it’s their job to help the asset teams succeed, including the management team. Our simple precept is that the tail should never wag the dog.
When we introduce processes we need to consider who they benefit. People who do the work have the expertise to know what processes and working practices most help them get the work done.
niksilver.com 