The brain consumes about 20% of the body’s energy, and that’s why we are by far the most dominant organism the world has ever seen.
From the point of view of IT development, I would say that formal processes represent about half of every company’s brain:
- A good deal of its memory.
- Many of its practical skills.
- A powerful device for enriching the knowledge, skill and performance of the individuals it employs.
- Much of its control of perception and behaviour.
- Much of its capacity for further development.
- Quite a lot of its capacity for reasoning, balance and coordination.
- Most of its basic language and social skills.
On the other hand, most companies’ formal processes – their lifecycles, the standards and procedures, their operational mechanisms, the processes embedded in automation and tools, their ways of working – are designed more like the brain of a crocodile. (The analogy is more exact than you might imagine.)
- They are spread out across the organism.
- They barely speak to one another.
- They are almost never tailored to the practical needs of their users.
- They are seldom created with a meaningful outcome or benefit in mind.
- They are never tracked or measured to see whether they are doing their job.
- They are seldom fixed even when they plainly aren’t.
- They have no effective direction or ownership.
- They are formally changed in an arbitrary and impulsive manner.
- They are often overridden of just ignored.
- They are never changed to anticipate a real problem.
And so on.
Without major evolutionary leaps, processes like this will never evolve into something truly intelligent. Or perhaps like the crocodile’s brain, their lack of rational structure means that they will never get much better.
Why is this?
It is, I think, because we don’t bother to invest in them to the extent necessary. Perhaps we just can’t believe that they need maybe 20% of all resources. Perhaps, like that of the brain itself, the significance of these processes is lost on people who, almost by definition, cannot see what these factors contribute. After all, we only need to invest so much in a corporate nervous system because most of the useful things an organisation does require a span of knowledge, control and attention no individual possesses. Hence the paradox of processes – they are installed because we cannot manage such vast and complex systems, but even when they are installed and doing their job perfectly well, we seldom construct, implement or support them in a manner that really improves our view of the whole. We are still cogs in a machine but, although the processes we have created may mean that the machine now works better, now it’s the processes we cannot grasp as a whole.
So what needs to be done to improve our grasp? No, I’m not going to say ‘use Agile’. Although that often helps, its effects can be quite local, especially in an organisation that is not really adopting Agile more as a sop to the developers than to truly transform itself.
Rather, I’m just going to suggest a few things that can be done to make any process environment radically more healthy:
- Engineer processes properly in the first place!
- Make it a collective activity, don’t under-estimate how much effort it will take, or the hidden cost of getting it wrong or the value of proper ownership and development.
- Start with a clear end in mind – and constantly test processes to see whether they are doing their job.
- Make sure everyone understands what the processes are for – i.e., don’t allow people to wander blindly through their work, just ‘following procedure’.
- Train everyone and train in detail. The ROI on training is higher than the ROI on almost anything else in management.
- Not training is not only completely counter-productive but also extremely demoralising and defeats the purpose of hiring intelligent, capable people.
- Do not over-engineer processes:
- Define standards and processes in terms of functional goals, not detailed technical steps, so they can be implemented and adapted locally.
- Conversely, explicitly maximise local discretion and flexibility, so decisions made remotely cannot inadvertently force absurd actions locally.
- Make sure that you can fix any problems with the process.
- Instrument the processes to make sure they tell you how well they are doing without having to ask specially.
- Have an intelligent waiver/exemption process so local teams can escape the worst excesses of processes that don’t suit their purposes.
- Part of every well-defined process is the possibility of changing it. It will need changing, and you need build that option in. So make sure that all processes are owned, with clear local accountability and authority to improve. Invest in the time and re-training needed to do that.
There’s a lot more, but if you are already doing all this, you probably have other things you should be focusing on instead.