Our corporate rules, customs and processes are there for reasons. We usually know what those reasons are, or we make assumptions, but often we forget the context behind them. That can lead to problems. Here are two examples…
1. The case of the many gates
My friend Gus Power tells the story (better than me, and may correct it below) of an analysis session he ran with a couple of dozen corporate stakeholders. They were mapping their development and deployment process, which involved a very large number of approval “gates” that significantly slowed the process down. Apparently the process spanned many, many meters across the wall of a barn-sized room. Everyone agreed the gates were part of their process, and everyone agreed they couldn’t be removed. But when Gus asked how one particular gate came be, only one person knew. This was someone who had been with the company a very long time. He recalled that the gate was introduced for one particular project, because the system was being developed by an external company that wasn’t trusted, and so there was a lengthy, detailed, check added. But that was over a decade ago, and the external company had long gone.
The attendees had almost forgotten the context, but once recalled everyone agreed it could be dispensed with.
2. The case of the shielded developers
I once worked at a company that developed software for corporate clients, and which was demonstrated fortnightly to clients by product owners. Then there came a time when it was found that developers were becoming distant from the clients and their needs, and it was suggested that one way to counter this was for them to demonstrate to the client rather than the product owners. This would allow them to listen to the clients’ questions, and understand their needs better, as well as getting direct validation of their work. But there was a long-standing mandate that the developers shouldn’t do this. The team had to question the status quo, “Why don’t the developers demo? Surely there’s a good reason for this.”
Again, the reason was historic. One particular client, in the distant past, had been very difficult to deal with and the product owners wanted to protect the developers from unpleasant and confrontational conversations that they drove. But the current clients were quite unlike that, so the reason no longer stood. They started to undo the custom and help the developers understand their clients better.
What I take from this is that we need to remember not just what we do, but the context for those rules and customs and processes. This helps us adapt more effectively, and stops us getting weighed down by irrelevant process.