I think that a lot of clarity can be gained by distinguishing between leaders and workers in the context of software development. The workers:

  • Write code
  • Ensure code quality
  • Manage infrastructure (both internally and externally facing)
  • Sell the product
  • Do customer support

Everyone in the company with different tasks is a non-worker. So, what do the non-workers do? Some of them are supporters. They might work in human resources, work as assistants to managers and teams or they might take care of the bookkeeping. As they don’t have any direct impact on the software development process, they are out of scope for this blog post. But there are other non-workers who do have an impact: The people pulling the strings and making the decisions. The leaders. They come in various forms: Some leaders are superiors and hence have direct influence over the workers in their team. Others only have an indirect, soft influence over a worker: They might be software architects or product owners either in his team or in a team he needs to cooperate with. All of them are part of the development process and may even write code from time to time, but their main job is managing, coordinating and organizing people. And this is where things can go wrong.

There is a very distinct line between managing problems and actually solving them. At some point in time somebody has to do something to fix an issue. There might be a lot of leaders involved in the process, but if you boil it down, they are optional. Even in huge organizations with highly involved processes magic can happen if two or three developers from different teams just sit down together and start solving a shared problem. I’ve seen a lot of unnecessary friction and delays caused by leader-only communication: Details get lost, statements distorted and everything becomes complicated and slow. Every task needs to be planned, prioritized and documented. Afterwards, the developers need to be assigned and then, finally, some work can actually take place.

I accept that some level of coordination is necessary in a big development organization. However, one needs to limit the amount of manpower invested into coordination. If too many people are leading and too few people are working, then progress will be slow and tedious. I like to keep this in mind by calculating a leader-to-worker-ratio for topics that I’m working on. It is trivial: You simply divide the number of involved leaders through the number of involved workers. The smaller this number is the better. In general, you are in trouble as soon as the leader-to-worker-ratio gets close to one. Some readers might consider it utterly ridiculous that there are situations in which you have a leader for every worker. Sadly, it can be much worse: I once sat in a meeting where I was the singular worker who was supervised by five leaders. All of them had gathered to discuss what I was supposed to do. Needless to say, the meeting wasn’t overly productive. If you’re a worker, be watchful! Topics with too many leaders will turn into a coordination mess very quickly.

So, after all this talk about too many leaders, you might wonder why so many of them exist in the first place. My theory is that low level leader positions tend to be both attractive and stable. Many companies lack a career path for highly technical minded employees. So ambitious employees are incentivized to become low level leaders (e.g., the manager of a development team) to advance their career. The problem is that the number of available leader positions shrinks with every step up the hierarchy. As a result, a lot of low level leaders remain stuck in their position. As very few of them choose to revert back to workers, either because they don’t want to or because their skills have atrophied over the years, you end up with an abundance of them. I want to point out that I don’t consider leaders as useless. There are many situations where a worker is desperately looking for a leader to make a decision, but often they are conspicuously absent in those situations. A bad leader is always there if you don’t need him and absent when you do.

To wrap up, you should always keep the leader-to-worker-ratio in mind. If you are a worker, you should try to keep the number of leaders involved in a topic to a minimum by being selective in your communication. It is often a bad idea to invite too many leaders to a meeting or to add too many of them to a discussion. You might think that you are doing a good thing by informing everybody, but in practice you will just slow everybody down. Remember: It is easier to ask for forgiveness than to get permission! Also, you should avoid any topics with a high concentration of leaders if you value quick progress and smooth sailing. If you are a leader, you can help by not getting involved in every topic. Only get involved if you have to or if you are asked to by a worker. Your team will perform better and the topics you do get involved in will be more pleasant as you are welcomed there. When you are needed, you should step in with enthusiasm and with the necessary bravery to make hard decisions. If you liked this blog post, please share it with somebody. You can also follow me on Twitter/X.