Thursday afternoon, I’m sitting in a meeting with five other people. It has a very familiar feeling. It’s the third time we have had this meeting with the same participants, even though no new information has come to light since the first one. We are discussing some new feature, but no one seems to know how exactly it should behave. It’s normal with new products. Still, the feeling that we are not making progress is ever-present. The discussion is not progressing and the development cannot start until we decide on all the details. This feels like a responsible approach. We want to ensure that no mistakes are made, we don’t have to redo something later.
The reality is that we are paralyzed by fear. We are afraid to make a mistake, to be wrong, to take a step forward. We claim to be agile, we have all the ceremonies and processes in place, yet we refuse to move forward and iterate as necessary.
This is a comfortable situation, it feels like no harm is done if no bad decision is made. We can argue about the new feature for weeks, and as long as we reach common ground eventually, we can say that it was necessary to properly specify the task at hand. Standing still has an apparent feeling of safety to it, it helps to avoid responsibility.
But even then, if you keep waiting and hiding long enough, your stalling and the delay it causes become obvious. There comes a point when you simply cannot afford to wait any longer without repercussions. You can no longer search for new information, you have to make do with what you have. You cannot always have a map, but you’ll always have a compass. You can keep looking for a map until the last second, or you can follow your compass and start walking. The terrain will reveal itself as you move.
There is risk in taking the first steps, of course. You might end up with code that needs some refactoring, or maybe even code you’ll never use. But the alternative is much more dangerous. Standing still and delaying decision provides a very addictive sense of safety and responsibility. Once people are used to it, they will have a hard time making decisions, they will be afraid of being exposed to consequences.
The fear of the unknown is human nature, it urges people to turn the unknown into something familiar. When the uncertainty is too much to handle, they will look for someone to push at least some of it onto. If they cannot find anyone suitable, they have no choice but to create processes, ceremonies and methodologies. They claim these processes are in place to streamline work and improve performance, but in reality, they mainly exist to absorb the uncertainty.
But these processes do not come for free. The more rigid the process, the higher the costs. Having more meetings uses a lot of time, yes, but the real cost is more subtle, almost hidden. When a process dictates how a team must work, it blocks their creativity, takes away their insight and nullifies their experience. It completely breaks their momentum. These rigid processes can suffocate people. They punish mistakes. They punish progress that’s made differently than they require it. They only reward when someone follows them perfectly. It teaches people that this is the only safe option. As long as they follow the process, they are safe regardless of how much progress is made. It is a very dangerous message to send.
The alternative, to let the uncertainty flow down to the engineers, is no better either. The engineers will have to slow down to manage it. At that point, the wheel is already in motion and the cost is already being paid, it’s just not accounted for yet.
As delivery inevitably slows down, management will feel pressure to act. They turn to the managers who provide their best tool: processes. There is no other choice, and a process is logical, familiar and feels safe, so management takes it.
At this point, developers have no choice but to follow the new processes. It provides them with some safety as long as they follow them, they don’t need to be the scapegoat anymore. But they are still not allowed to do their jobs properly, their hands are tied. The best engineers will either stop caring, stop trying, or leave the company altogether.
The focus of management is now on the process itself. Whenever there is an issue with performance and delivery, they will look at the process. They update it, they refine it, but nothing ever really changes. No amount of process will recover what is already lost.
To resolve the situation and break these cycles, balance is needed. Not everyone is equally well positioned to create and maintain it. The more authority one has, the more delayed and filtered the information one receives. The closer one is to the execution where the friction, mismatch, and human cost show, the less authority one has. Too much delay, and you are too late to do anything, too little authority, and you cannot make a difference.
The ones in the best position to act are the leaders. They are the ones who are close enough to execution to feel the pain, but still have some authority and the necessary skills to provide feedback. They can stand between management and the engineers. They must provide feedback so the uncertainty can be balanced between the processes and the people. If they fail to push back when needed and embrace conflict with management, the balance will break.