It has been well known for decades that some developers are much more productive than others. Based on a classic research paper, the term “10x developer” is sometimes used to describe these developers. In 2019, I contributed to this topic by making the different categories of developers more fine-grained with my developer skill matrix. This post is still highly relevant, but there is one topic that I have only briefly mentioned in it: the level of growth in quantity and quality of output that one can expect from a developer. I think that substantial growth is rare and that this has great implications for management.

Here’s a quick recap of the development matrix, just in case you’re not familiar with the original blog post. The matrix looks like this: developer matrix

The x-axis measures the raw output of a developer, while the y-axis is the quality of this output. There are four different categories of developers: plants, glaciers, volcanoes, and stars. While the ideal team consists only of stars, most teams contain some mixture of the four different categories. Here, the topic of personal growth comes back into play: If we assume that every developer improves over time, then we will end up with a team full of stars sooner or later. Sadly, this is not how it works in reality. There are developers with decades of experience who are still plants or glaciers. Also, there are junior developers who directly start their working lives as stars or who quickly become stars after having been a glacier for a while. While developer performance might improve over time, it is more likely that everyone will stay at his current level for the foreseeable future. This means that a low-performing team won’t improve substantially with more experience. Most likely, it will stay more or less the same.

This rather inconvenient fact implies that a more active management approach is needed to help a struggling team. Hoping that the team will be the exception and have significant growth is not an option. Instead, stars, or at the very least, glaciers, need to be added to the team so that the average output level and the average quality level increase. Naturally, this isn’t easy, as correctly assessing the skills of a potential new hire is difficult, and good people will be in high demand. Hence, it can be a good idea to look inside the organization for any high performers with a proven record who are willing to make a change. Poaching internal talent like this can be very effective, but it is unlikely to make us friends.

Before we add any people to the team, we first need to assign each member of the team to a category and assess the full picture. A team full of glaciers is not a bad situation, even if the team output will be rather low. Due to the team members’ high quality of work, productivity will remain stable over time as only a low number of bugs are introduced. Here, it might even be an option to not do anything and just accept the low output. However, doing nothing is not an option if there are any volcanoes on the team. Because of their high output and low quality of work, these developers are highly corrosive to any codebase. If they are not stopped, they will introduce so much poor-quality code that all progress will grind to a halt. Given that growth from a volcano to a star is unlikely, volcanoes should be leveraged for prototypes and any other work where quality isn’t important. Adding a lot of static code checks can slow them down, and deep code reviews of their code by a glacier or star can also be helpful. There is no great way to deal with a volcano. It will be frustrating and difficult, but it is necessary. Even letting them go is preferable to letting them continue their harmful work.

Plants are much less important than volcanoes and should be ignored until everything else is addressed. Their low output balances out their low work quality. In the end, it doesn’t really matter whether they are part of the team or not. In contrast to this, the stars are critical to the team’s performance. Any star on the team needs to be kept happy and productive. This is the most important thing a team manager should worry about. Losing a star will hurt even more than having a volcano run rampant. Sidenote: It’s very likely that the stars and the volcanoes on the team will clash as their working styles are too different. In that case, it is essential to back up the stars. This is one of the many reasons why awareness of the skill distribution in the team is so critical for managers.

But why is growth so rare? My theory is that a lack of growth is caused by a lack of self-reflection. To grow, we need to reflect on our behavior and see where we went wrong. If we don’t reexamine the code we wrote, then we will not grow. Learning from our errors also requires that we take responsibility. We need to admit that it was our fault. It’s easy to blame someone else for the sloppy code we wrote a year ago. Maybe the requirements changed at the last minute, or we just didn’t have enough time. These things might be true, but they are still excuses. In the end, we operated the buttons on the keyboard and nobody else. If we don’t accept this, then we will not learn, and as a result, we will not grow. As this is a hard thing to accept, many developers don’t grow.

Conclusion

Developers rarely grow. Hence, a low-performing team won’t get better over time. Instead, new, high-performing developers need to be added to the team to address the problem. In addition, any team members with high output but low quality of work need to be kept in check to prevent permanent damage to the codebase.

If you liked this blog post, please share it with somebody. You can also follow me on Twitter/X.