It seems rather obvious that some developers are much better at their job than others. After all, we know that some football players are better than others and we also know that some doctors are better than others, so why shouldn’t this be true for developers as well? In fact, there are studies backing this claim. Furthermore, this variance in skill is known in the industry. For example, Alan Eustace claimed in an interview that one top-notch engineer is worth “300 times or more than the average”. He also said that he’d rather lose an entire incoming class of engineering graduates than one exceptional technologist. According to him, many Google services, such as Gmail and Google News, were started by a single person.

There are lot of things one can nit-pick about either the studies or Mr. Eustace’s statement. The obvious problem is that there is no proper way to measure productivity in the context of software development. Many different metrics have been suggested in the last years and all of them are deeply flawed. Nevertheless, I think it is foolish to dismiss these findings: Developer skill does indeed vary greatly between individuals. Love it or hate it, we have to manage this variance, and this is the point of this article.

So, how do you manage developers with highly different skill levels? In my opinion, the first and most important step is to accept the skill variance. A lot of managers still think in terms of full-time employees (FTEs) who are more or less the same. This is a very convenient view as it allows mindlessly shuffling around developers between teams and projects, but it is completely wrong. Five high-performing developers are not equivalent to five mediocre ones or five terrible ones, even though they all equate to five FTEs. Also, competency is at least partially context dependent: A developer is much more productive if he is familiar with the used technology, patterns and the code base. A great Java developer might only be a mediocre C developer. By reorganizing teams too often and too naively, managers can easily cripple developer productivity.

The next step after accepting the skill variance is to get a good feeling for the distribution of skill levels in your team. I have come up with a simple way to categorize team members:

developer matrix

As you can see, I have divided team members into four groups, similar to the way products are categorized in the BCG matrix. The x-axis measures the raw output of a developer while the y-axis is the quality of this output. This is, of course, a very simplified view, but the “fuzzy” nature of this problem makes it hard to come up with a more precise one. In the lower left corner, we have developers with low output and low quality. I’ve dubbed them plants as their presence in the office does not really make a difference (similar to the presence of potted plants). The low quality of their work is not overly important as their output is so low. They will not mess up your code base beyond repair. Nevertheless, they can cause a lot of resentment in the team. Still, it is probably not a good idea to focus too much management “energy” on them as the return of investment is so low.

On the upper left corner, we have the glaciers. These are developers with high quality of work, but low output. Like glaciers they are moving, but the progress is so slow that it is almost impossible to observe. In general, glaciers are acceptable co-workers as they are very thorough and don’t cause too many problems. Some even have the potential to grow into great developers over time if their slow speed is caused by a lack of knowledge or experience. However, there are some developers with decades of experience who are slow nevertheless. In that case, my recommendation is to just accept them as they are. It is important not to assign any time critical tasks to a glacier as this will lead to a lot of frustration on both sides. As long as this is kept in mind, glaciers are not a threat to the team performance.

Let’s move into the high-output area. On the top right there are the stars. They are the back-bone of a team, the developers who both get a lot done and manage to deliver high-quality work. Often, most of the work in your team gets done by a small-subset of developers (see pareto principle). There is a high chance that some or most of your stars will be part of this subteam. Hence, it is extremely important that these developers are happy and productive. Usually, this means shielding them from as much administrative overhead as possible. They should focus on the critical and hard tasks instead. Naturally, micro-managing them is a terrible idea as this wastes their time and will most likely create a lot of dissatisfaction. When in doubt, opt for a hands-off approach, but keep your ears open for any complaints. As developers don’t get paid in accordance to their productivity, the stars are extremely cheap in relation to their contribution to the team. This is great for the company, but also a bit dangerous as it can cause the developers to feel undervalued.

The last developer group are the volcanoes: high-output developers with a low quality of work. Volcanoes are extremely dangerous and need to be managed to prevent permanent damage to the code base. If left to their own devices, they will erode the code quality over time and hamper the productivity of the whole team in the process. There are two kinds of volcanoes: inexperienced hot-shots who still need to grow into a quality mindset and experienced, serial code-manglers. The hot-shots may be reformed by additional mentoring and training. In the best-case scenario, a volcano turns into a star this way. The serial code-manglers are beyond redemption: They are deeply convinced that they are right about everything and they ignore all evidence to the contrary. They don’t see the point of (automated) testing as they are convinced of their own perfection. Their lack of self-awareness will doom any attempts to educate them. There are only two ways to handle them: You can either limit their output or kick them from the team. The latter is preferable, but often impossible, so I will focus on the former. You can prevent a volcano from blowing up your code-base by adding more quality checks. A good first step is to make sure that merging into the master branch is not possible unless the code compiles and all automated tests are passing. Then, you can add further checks via tools like sonar and check for a suitable code style with something like checkstyle. Mandatory code reviews can also reduce the damage. All these extra hoops will make sloppy development both slower and harder which harms bad developers while keeping good developers more or less untouched. I highly recommend it. Another good idea is to use volcanoes primarily for tasks where quality is not overly important (e.g. for prototyping).

So, there you have it, the four styles of developers. Note that I don’t believe that bad developers are bad persons and vice versa. A star can be a total jerk, while a volcano can be a saint. It is not the only metric you have to consider when building a team. However, it is crucial that the huge difference in developer skill is kept in mind. Ignoring it can be fatal. That said, how do you determine the skill level of developers in your team? Disclaimer: I’m not a manager, so take my recommendations here with a grain of salt. From my point of view, you need technical knowledge if you want to lead a development team. In an ideal case, you can replace any member of your team when push comes to shove. At the very least, you should know what problems the team has to deal with at the moment and who is working on what. I recommend doing everything the developers do in your team to the best of your abilities. For example, you should try to solve support requests. Even if you can’t develop the code fix for a bug, understanding the root cause will help you understand the code base as well as your product as a whole. If you can code, you should take a look at the repository from time to time. The most recent code changes should give you a good idea what is going on at the moment and how high the code quality is. GitHub offers a breakdown of the contributions to a repository which might help you determine who is contributing how much. Obviously, this is an imperfect metric and it should never be used as a key performance indicator. Also, your bug-tracking tool might give you some insights. Sadly, there is no perfect way to gain the necessary knowledge. You will just have to experiment and find out what is working for you. However, this is not a new challenge as most companies have some kind of performance review in place anyway. If you already have “grades” for each of your developers, it might be interesting to cross-reference them against the matrix.

As soon as you have a clear enough insight in your team’s skill distribution, you should determine whether you have any volcanoes in your team. If so, you have to make a plan and act. It is a manager’s job to deal with problematic team members and not doing it will lead to strong discontentment in the team. Larson and LaFasto wrote a book on team performance in 1989. To quote them:

More than any other single aspect of team leadership, members are disturbed by leaders who are unwilling to deal directly and effectively with self-serving or noncontributing team members.

Your team members will know when someone is not doing their job or even actively harming the team. As a manager, you have to face this issue even if it is challenging and uncomfortable. Doing nothing will harm your team and you by proxy. Nobody needs a manager when all things are going smoothly. Only during times of crisis can you show you worth for the team. I hope that the skill matrix helps you in this regard. If you liked this blog post, please share it with somebody. You can also follow me on Twitter/X.