As a consultant, coach, and advisor, I meet with management teams to discuss crucial aspects of their organisational evolution. My role is to assist them in formulating a winning strategy, a task I thoroughly enjoy despite the occasional feeling of navigating turbulent waters.
However, there is one essential and worrying constant in most of these meetings: leadership is deciding alone, without the collaboration of the people operative “in the field”. While management has the right and the duty of deciding – companies are usually not intended to work as democracies [and yes, I know, there are alternative models here, but let’s keep them for another post…] – it is questionable whether deciding in that small circle is valid, effective and sustainable. Here are some considerations:
1. Taylorism revamped
When a management team makes decisions in isolation, it can inadvertently create a perception of a two-tier system. While some decisions may need to be kept confidential until they’re ready for communication, a more transparent process can help instil a sense of accountability and responsibility across the entire team.
Let me start with an example: years ago, when I was a beginner developer, I admired the CEO of my company: he was a great communicator, knew how to speak to the employees, and gave realistic and powerful messages. I remember him promising us that our future as a company was to delight our customers, go through an IPO and become all rich and famous. He repeated that message several times, but one day, he told us the company had been sold to a multinational corporation. Bye-bye dreams! Honestly, I never counted on becoming rich through that IPO. I also understood the structural problems in the company that led the owners to sell. I understood why the CEO had to keep the negotiations secret. Yet I felt betrayed. I felt I was not part of the same company he was representing. I felt like a powerless pawn.
So, as a result of this, in my consulting practice, I keep in touch with the employees and sense how they perceive the company. I recognised several times that they had the same feeling of being second-class citizens of the organisation. I am unaware of particular studies on this topic, but I sense that this Taylorism revamped has a significant negative impact on employee motivation and engagement. Management must be aware of this impact and consider it in their decision-making process.
2. Cook your own soup
Another effect of management deciding in isolation is that their perception of the company is often prioritised over the organisation’s reality. It’s usually a simplified perception: org chart, people assignments, control structures, etc., all discussed without involving the other employees. Frankly, I often felt like management was talking about a different company than the one I experienced. Assumptions were made that made some/little/no sense, but regardless of how good they were, they were still based on a distorted perception of the organisation.
Well, here are a couple of questions for you, dear manager: When did you last participate in a Sprint Review? Can you mention the three most important issues each team has in your organisation? What concrete observations do you have to evaluate how engaged the employees are? And so on…
As a friendly reminder: Go-See is a fundamental practice for each manager in a company, and it takes time to learn to do it correctly. It’s not about sitting in during a meeting. It’s about understanding the human dynamics at play, hearing what is being said and perceiving what is not being said but still otherwise communicated: a glance, the tone of voice, the body language…
3. Management decisions are holistic decisions
Of course, I don’t expect the average manager to understand all of the aspects needed for making complex decisions, and this is why, in any company, there are dozens of brilliant people who understand the domain they are working on.
But then, as a third and possibly most worrying aspect of management deciding alone, it’s managers again who decide how to structure a project, define deadlines and budgets, and plan intermediate steps – without involving the developers. Okay, there might be one architect or two, but the people who will have actually to do the work are not engaged from the beginning, with some dire consequences:
- Motivation: you, dear manager, gave me the goal, so it’s your goal, not mine. Especially when the goals given are “stretched” (or, as I prefer to call them, “stupid”), we cannot expect developers to accept something they don’t see as feasible. The late Ed Yourdon analyses these dynamics in his seminal book “Death March”.
- The decisions are based on a simplified model of reality, i.e., they are doomed to fail when confronted with the technical details. Sometimes, it seems that management talks about products as if they were to be built with Lego: take one module and the other, attach them and ship them. Sorry, it does not work like that. Decisions based on simplified models fail, the developers will not feel responsible for that, and the disconnection between management and employees grows and grows…
- The third aspect is that we’re missing some essential options that can be opened when business and technology collaborate because we do not have the relevant technical expertise at the table. From a recent discussion with a client: “We need to provide a forecast, a plan and a budget forecast to our client, i.e. we need to run a heavy upfront analysis”. Yet, other options exist: a walking skeleton, lo-fi prototypes, and evolutionary architectural approaches that allow for more flexible product exploration. However, finding intelligent solutions requires involving the technicians from the beginning and optimising the priorities so that the developers evolve their Solution and Business Domain competencies as fast as possible to propose more targeted technical opportunities and solutions.
What are the alternatives, then?
- Move away from a two-tier organisation (and, in some cases, more than two!) and have, like the agile manifesto says, “business people and developers working together daily” (https://agilemanifesto.org/principles.html, principle 4)
- Promote learning the business domain and the solution: the more developers understand the product, including the business aspects, the better the technical opportunities will be.
- Promote participation and co-development: no product is “just business” or “just technology.” Magic happens when you create an effective synergy between the two, powered by a motivated group of humans bringing together their skills!
- Involve the people impacted by your decisions: This is a fundamental principle of change work in ELSE and a fundamental concept of agility from day one.
Sure enough, real agility is not easy, and it will be bumpy, but the rewards can be huge!