process – James Osborn

Good process is a great way to scale your impact. Bad processes stifle creativity and stop progress dead.

So when you think it’s time to add a new process, be really honest with yourself why you want to add it, and ask yourself a few key questions.

Firstly, is it actually going to help? Does it solve the problem you are trying to stop, or does it makes things worse? Get some people to throw some rocks at the proposal. Imagine what happens if you follow the process to the letter, as people’s judgement will fade over time, you can’t rely on that.

Assuming it passes these tests, and is likely to lead to better outcomes and good behaviours, ask yourself if it’s worth the cost? If the impact is big, then it might be worth a new process. If it’s small, why are you bothering? Don’t add overhead you don’t need.

Then ask if it’s really worth the cost. If you add an approval step to every release, then you’ll release more slowly. If three people must sign off a slide, then triple whatever the original cost to create was. If it’s your process, then you’ll need to own these costs. Nothing comes for free, it’s never just pure upside.

Finally, ask yourself how you’ll get rid of the process, or update it when the time comes. It’s easier to add than subtract, especially when you create jobs to enforce a process. What’s your way out? How will you know when a process is embedded into culture? How do you know if you are going through the motions for no real benefit?

Good process accelerates change. Bad process stifles it. Do the work to make it good, don’t just launch and forget.

Don’t force the Process

Requiring a uniformity of process caps the highest potential of your teams.

Process protects us from making mistakes, and can lift every team to a good level. Forcing this is what stops us finding the truly great performances.

We sometime fall to uniformity when we find it hard to measure the outcomes that teams are driving. Measuring adherence to a process is often easy. It’s easy to count the number of widgets that are being created, and it’s easy to see if we’re all doing it in the right way. It’s not always easy to determine if we’re doing the smart things that actually achieve the outsize results.

A classic example of a mistake is to enforce Scrum, or any other particular flavour of agile. The more tightly it’s enforced, the less likely you’ll get a 10/10 team performance.

Instead, go back to the Agile Principles. The best architectures, requirements and designs emerge from self-organising teams. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behaviour accordingly.

An overly rigid process hinders this adjustment. It doesn’t recognise the unique context of the team, and that’s where the potential is capped.

By all means, if your org needs certain things reported, or activities that must be done for legal reasons then you can require that of the teams. Beyond those must do things, you should instead encourage your teams to experiment and find out what works best for them.

The goals of leadership in this model is to share the things that are working, and also the things that aren’t. Giving access to the tools that can support, and taking away the noise that breaks focus.

It’s imperative that you don’t just allow each team to meander through the path to excellence!

So forcing a process can take you up to good, coaching teams and sharing the best outcomes widely will help you achieve greatness.