Why Some Developers are 20x more Efficient Than Average
Have you heard that statistic as well? That a good developer is 3x more productive than an average one, but that a ‘Great Developer’ is over 20x more efficient? Do you believe this to be true? I do. With this article I would like to highlight the traits that these highly efficient people share in my opinion.
In the past 10+ years I have had the opportunity to hire over 100 people and have interviewed easily ten times as many. During that time I have learned how to ‘feel out’ the people who have the potential to become really good. And some of them turned out to be amazing.
I am not talking about the literal ’superstar’ or ‘rockstar’ here, about people who really believe that they are better than others, who are arrogant or expect different treatment because of who they are. Such people are more toxic than helpful and will never achieve 20x efficiency. I am talking about people who are of course extremely good at what they do, but in addition, having one of these people on your team will make everyone else also more efficient. They are not individual heroes, they multiply their own efficiency with that of their teammates. Leadership is therefore one very strong aspect here. But let’s get to this one after the other.
The qualities I want to discuss in this article are Personal Culture, Excellence and Leadership.
Personal Culture
For lack of a better word, I am putting everything under this label that has to do with attitude, values and the inherent motivations and drivers of a person. Developers who become 20x more efficient than average share a lot of the following traits:
Broad Interest and Curiosity. In my opinion, great developers are usually very knowledgeable in many things outside of software engineering. They are interested in how the world works in general, they read a lot and have several channels where they inform themselves. They like to discuss and value other people’s point of view as a source of more information to process. In my opinion, in the context of software engineering, broad interest and curiosity are essential for the actual task of software engineering as well. I like to have coffee with the candidates I interview before and after the interview to see what kind of interests they have also outside of work.
Why is this the first trait I am listing? Imagine you have a planning meeting where the project manager or PO is explaining to the development team what the next set of features is about. These meetings have the purpose to make sure that the dev team understands the big picture of the problem at hand so that the right solutions can be found. It is essential to really make sure that the problem statement and the use cases are well understood by the dev team. It is worth while spending time in such plannings to really understand everything, so that the outcome of the development effort, often several weeks and months later, or even just at the end of the sprint, is actually the solution to the right problem. Usually, there are one or two people per team who ask some clarifying questions to the PO, and then everyone collects the requirements, nods in agreement and walks off. Too often I see that the developers are not that interested in the big picture and problem statement, but only as far as they can see how it is relevant to their code, and to an understandable technical challenge to be solved. A technically skilled PO can break things down to that level so that the average team will get nice chunks of technical work that will mostly succeed, but too often the outcome is not quite as expected and several iterations are needed to get to the desired result.
Not so if you have a Great Developer on the team. This person will challenge the PO on the most crucial aspects of the project and does not let go until she understands the motivation behind every requirement and user story. This person will also make sure the whole team is involved and prompts automatically for the opinions of her teammates in the discussion, helping the PO out in managing the flow of the discussion. She will kindle the interest of everyone in the room in the challenges and corner cases in a fun way, proposing to research unknowns if they are relevant to find better solutions. It can happen that the team and the PO jointly realize that there are still several unknowns that need to be clarified before any development on the given topic can start, which results in spikes or in the PO having to go back and do more research. Then no development effort is wasted on things that could have been found out up-front, thanks to the interest shown in understanding the big picture. The efficiency gain here is easily more than twentyfold. This is what I mean with putting broad interest and curiosity to action in the development context.
Having fun solving problems. The exceptional people I worked with all share this trait. Whenever a problem is not obvious but has some challenges, you can see there is a spark in their eyes, the wheels have started to turn in their brains and suggestions for solutions or approaches start coming immediately. They obviously have fun while doing it, bouncing back ideas, and there is a lot of energy freed up in the process. This kind of fun is one of their main drivers, and also drives their interest and curiosity. The risk here of course is that of losing focus or jumping too quickly from one problem to the next, but this is where the Great Developers find the balance: have fun solving the problem at hand, and to still have fun from actually delivering the solution according to the definition of done. Knowing what tasks to be involved in and what problems to delegate or delay is where experience comes to play. And since they have fun solving problems and have solved a lot of problems in the past, it goes without saying that they are really good at it.
Great developers can involve themselves in discussions also outside of their domain of expertise and provide invaluable insights in any discussion. Inviting these people into brainstorming sessions, architecture meetings and bug hunting sessions has two benefits: one, you get an outside perspective, two, the energy of these people is contagious and acts again as a multiplier on the team. More often than not, solutions or just action items that are developed with such people in the room are going to be much better than without them.
There is no failure. A positive mindset is the final cultural trait that I want to highlight. Great Developers are so efficient because they can immediately pivot and re-try if something does not work. They know that making mistakes is a huge part of software development, and that it is also a great source of education for themselves. They consciously make use of mistakes to get better. They want to learn and grow through failures, and not just their own. So they don’t take failures personally, but will highlight it as opportunities to learn something new, talking about their own mistakes freely and willingly. Great Developers will raise the morale in their teams, as they keenly will point out what to learn from each other’s mistakes as well, congratulating and encouraging those who were at the source of the new insight. This not only improves team morale but also the willingness to experiment, which is an essential driver for innovation and improvement. Through great developers, teams will be better faster, and therefore their output is easily 20x higher than average.
Excellence
The second set of aspects that comes to play when measuring efficiency is excellence. The people I talk about have a very high internal bar when it comes to their work and they take pride in doing things well. There is of course the risk of overdoing excellence by too much polishing and refactoring, but that would lower efficiency, so the great devs I talk about have learned through self-aware experimentation where to set their bars so that their work is clean and as nice and simple as possible, but not more.
Self-Awareness. One of the best indicators for potentially great developers in interviews is their level of self-awareness. The standard questions of ‘what are you really good at’ and ‘where would you like to improve’ are not surprising to these people, and they come back with answers that show that they have clearly spent a lot of time and thought with these questions for themselves. They know exactly what they are good at, and where they want to improve, and why. They plan out their own education and usually ask about employee training programs early in the interview, or to what training resources they have access to in the new company. Another question I like to ask is, ‘what is the last book you read or the last course you took’. Good developers have no problem responding here and propose interesting classes to attend or books to read. Great ones have to be stopped as they will talk endlessly about what they have learned and what they find interesting. This will be often one of the most important aspects for them when choosing a new employer, even more so than the salary. Great Developers actively seek feedback from their peers and managers to know where they stand and especially how to improve, also to measure their own personal goals. They will tell me as their manager what they want me to do for them, I don’t have to guess and find out in sometimes tedious 1:1s what their next interest might be.
Quality. Highly efficient developers are so efficient because they produce high quality code. Efficiency is gained mostly by having as few bugs as possible and being as clean and easy to read and maintain as possible, because this is what saves time and money down the road. That is multiplying efficiency with much higher factors than 20. Great developers are adamant about software quality, SOLID and the definition of done. They are very often evangelists of testing frameworks, pair programming and code readability and documentation. They automate everything they can and optimize their processes to improve quality and maintainability. They will actively seek metrics and tools that help them with monitoring the quality of their own work and that of their team.
Structure. Most of the highly efficient developers I met are excellent in structuring their work. The clean structure shows not only in their code but also in how they work, how they prioritize their backlog items and how they describe their stories or their tests. They bring structure not only into code and workflows but also in discussions, bringing people back to focus when there is a digression. Structuring their own time is probably the most important aspect. Since such people are usually highly sought out advisors and peers, they have learned how to organize themselves to have enough time for development as well as for discussions and helping others.
Leadership
Obviously highly efficient people will naturally gravitate towards leadership positions. Unfortunately, companies too often promote such people into management positions where the fun factor for Great Developers is diminished and they may even leave the company because they don’t do anymore what they like and what they’re good at. I will write about career paths in flat and agile organizations in another blog — it is very important to make sure that excellence in development is also seen as a highly valued career path in a software engineering organisation, especially for such people. But right now I would like to describe what I mean with leadership in this context.
Communication. Great Developers are usually very good communicators. Due to the fact that they are good in structuring their work and their thoughts, they can explain themselves very clearly. Since they have broad interests, they can talk in metaphors and visualize their points easily. They are also keen listeners and take full interest in what other people have to say. Most importantly, talking to such a person makes you feel better because they will help you to improve your own thoughts, by asking the right questions and providing insights in any discussion. In short, it is a pleasure to talk to such people. Communication can of course be improved over time, therefore it is also essential for companies to actively train their teams in communication.
What makes a developer Great and highly efficient is when he can make use of his communication skills to drive solutions or expose and solve problems with his team, his PO and management. Here the intrinsic enthusiasm for problem solving and positive thinking are an essential ingredient so that the person is perceived as helpful and motivating. This is leadership in its raw form, which again contributes to make any team more effective as a whole.
Mentorship. Almost all of the highly efficient developers I met were really good mentors and teachers. This also stems from their inner drive to learn and improve: ‘I learn always something new whenever I explain something, just because of the questions I have to answer’, as one of my friends likes to say. Mentorship and teaching others is also invaluable to any company, this is the only way actually to really multiply efficiency when growing a team. New members will only make a team more efficient if they are integrated and educated well, and this again depends whether there are good or even Great Mentors in the given team. A Great Mentor will train and motivate better and faster, which again multiplies the efficiency of the whole team.
Friendliness and Humility. None of the people who I would call Great Developers are arrogant. In fact, they are kind and funny people who are extremely approachable. At the same time, being good communicators, they can also protect their own time in a friendly manner and say ‘no’ in a way that does not hurt others.
So Where Is All the Technical Prowess?
Maybe you have realized while reading through the article that I do not mention any technical excellence when talking about a Great Developer. The reason is simple. In my experience, people who do have the mindset — they are curious, love problem solving, want to learn, have a high standard and are self-aware — automatically will be very strong developers because they will be good at anything they take the time to learn. Most of these people end up being full stack engineers who know several languages and frameworks because they want to learn many things end to end. And because they want to look under the hood and understand how things really work, and this is exactly what sets them apart.
Do You Want To Be Great?
In my opinion it is a matter of attitude and what I called above ‘personal culture’. Just like with any other profession, it takes time and mostly dedication to be truly good at what you do. Not everyone can be a great musician, it takes years of practice to get there, and mostly only those who are driven and truly enjoy what they do will make it to the top. The same is true for Great Developers. You just need to have the drive for it, draw energy from solving problems — and from working in a team, to learn and to teach. And my most important advice would be to keep a positive mindset.
