During my work for a big software company, I have noticed that a lot of people there don’t exactly work. I assume that a similar pattern can be observed in other big companies and that smaller companies are less affected. From my point of view work in the context of software development is limited to four activities:
- Writing Code
- Managing your own infrastructure (both internally and externally facing)
- Selling the product
- Doing customer support
This definition excludes a lot of people. So, what do those non-working people do? Some of them can be lumped into “supporting” rules. They may work in human resources, work as assistants to managers / teams or they might take care of the bookkeeping. While they may drain company funds, they generally don’t get in the way. More interesting are the people that do: The men and women pulling the strings and making the decisions. The leaders. They come in various forms: Some leaders are your superiors and hence have direct influence over your doings. Others have only indirect / soft influence over you. They might be software architects, product owners or lead developers either in your team or in a team you need to cooperate with. All of them are somewhat 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 become problematic.
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 managing / supporting roles involved in the process, but if you boil it down, they are optional. This might not be true in huge organizations with very involved processes, but it is in small companies / start-ups. And even in huge organization 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 glacial development speed 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’m not delusional: 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. While it is theoretically possible to have too few leaders, this problem very rarely occurs in practice. Instead, examples of too many leaders in a task are legion. 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 teams with 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. Fortunately, I was allowed to work more or less unsupervised once the planning was ironed out. If you’re a developer, be watchful! Topics with too many leaders will turn into a coordination mess very quickly. Also, they tend to be filled with a lot of corporate politics as this is how many of those leaders try to get ahead. Getting caught in political games as a worker is often unwise and rarely enjoyable.
So, after all this talk about too many leaders, you might wonder why so many of them exist in the first place. After all, it is glaringly obvious that no efficient work can take place under such circumstances. Why isn’t this prevented? Well, my theory is that those coordination roles are a great storage for not particularly skilled people. I work in a country with very strict worker protection laws which means that it is close to impossible to fire someone. To make things worse, my current company is extremely tolerant towards low performance and doesn’t even attempt to get rid of any low-performers. Under these circumstances, you have to find a way to occupy all these bad employees, preferably in a position where their incompetence cannot harm the company. You cannot let them work as developers as bad code corrupts the codebase, you cannot let them work in sales or consulting as they will aggravate the customers. So, you find them some internal position where they cannot cause any additional harm. Naturally, they prevent the more productive parts of the company from working, but as this is not directly observable, it tends to fly under the radar. There is no drive to address the issue and bringing it up will only cause a lot of friction. So, my advice is to just live with it unless you are in a position of great power within your company. I want to point out that I don’t consider all leaders as useless. Of course, there a great leaders out there who are highly competent. 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 an email communication. 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 doing anything especially 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.