The Myth of Lone Wolf 10× Developer
You cannot be multiplication factor if you’re alone.
Grow People. Image Credits: https://www.flickr.com/photos/xverges/5866575567
I remember the time when I was assigned as Tech Lead for a small group of developers in 2007. That was an abrupt decision from the management as my lead suddenly left the company. My junior role was cut short and I’m suddenly the Lead Developer. I underestimated the role. I could get the project run but I did a lot of things which almost killed the project and my team.
I thought I was the smartest people and could order people around. My code was the very definition of the best-est clean-est code and I could write code 10 faster than my peers. It turned out, I was wrong. I neglected my team growth. I did not know how to delegate and relinquish your code to the team. Even if I worked hard and write code, my team capacity and capability stagnated. I became a lone wolf, not a team player, much less a team leader.
You Get The Best Talents, Now What?
The 10x Developer?
There is a notion that there was a genius 10× developer. This developer is so skillful so that he can do 10 times amount the work of the other developers. Companies try to find this 10× developer. Some use the term ‘_rockstar_’ or ‘_ninja_’ to communicate that they search for a highly competent developer who perharps churns code 10 times as much as the other developers. They can just throw work to him/her and they will do it 10 times as quickly. Companies who don’t have learning culture usually fall on this trap.
Personally, I don’t believe in this notion of 10x because it’s hard to measure and quantify the multiplication factor of a developer. I had a privilege to meet and work with some very competent developers. An on lesser extent, with a few developers who thought they were the 10×s who was clearly weren’t. I learnt that the competent developers turned out not the ones who crank code fastest and these people can only survive in organisation with growth culture. Real 10× developers empower team and increase their capacity and capability.
Having Lone Wolf Is Actually A Risk
Being smartest guy in the room does not really add value to a company. In my opinion it’s a huge risk. If I were part of executive team, I might not see it as an achievement or advantage. What organisation want is 5 smart and productive people, not 1 smart person who works alone leaving 4 others in the cold. If this guy was hit by a bus, the other 4 guys would not know what that 1 person was doing. The ‘Bus Factor’risk is too damn high making it so risky.
The Bus Factor
Edmond Lau in his book “Effective Engineer” wrote that there are high leverage activities and low leverage activities. An example of high leverage activities are mentoring. A distinguished developer understands that he/she is more valuable teaching and mentoring the team rather than showing off his smart-assness to his colleagues.
A distinguished developer enjoys developing and spending time with people. “Copying” his breadth of knowledge to other people seeing them grow and succeed. This is the truly multiplication factor.
Multiplication Or Addition?
If you’re just adding to the workforce, it’s addition factor. Five people may do work faster than two people but their capacity and exposure stuck. This is a red flag for an organisation who keep hiring without clear career path from the bottom to top.
Distinguished developer multiplies himself so that the people who less experienced grow their capacity to match him/her. In a hypothetical team above, if one distinguished developer coaches and teaches 4 more developers the sum of the parts are greater than if he/she do it alone.
When the others start to get more proficient, eventually they teach another developer again. This butterfly effect is the multiplication factor. The sum of team capacity and capabilities grows over time exponentially. This is good for organisation. A developer who only thinks about code without considering their team capabilities is not a multiplication factor. He/she is an addition factor who adds team capabilities but not growing it.
Teamwork and Communication
Mentoring drives communication. A distinguished developer spreads his/her knowledge with the goal of the less experienced developers understands it not to fulfill his/her ego to be proven the smartest in the team. If the other developers cannot understand, it’s usually the failure of the mentor, not the mentee.
Mentoring Is About Growing People. Image Credits: Pixabay
Mentoring also drives trust. It is so easy to overlook this if the organisation does not have learning culture. A trust is very important as it removes lot of waste of negotiation and infighting. Team with strong bond of trust is very productive.
Shared Ownership
Problem with developers are they consider their code is them. They define themselves with their code. So when other people changes their code in a way that he/she does not prefer. He/she feel somewhat offended.
It’s easy to spot if you have this kind of developer. The team is in constant fear to change the code. The feedback loop stops. It will be so rigid, nobody wants to touch it nor they understand the reason of decisions and considerations when the code was written.
A distinguished developer knows how to teach the practise as well as the reason on the decisions on each line of code. Best practises in software development like SOLID design, TDD is not to be thrown away. But rather than being the ‘test/coverage _police_’, he/she becomes the ‘test/coverage _steward_’. He/she takes care of the test and guide their team to achieve the goal via test and other good development practises.
Conclusion
The 10× developers may be real and not a myth. However, lone wolf developer cannot be a 10× because he’s not growing the team, thus he could not be the × (read: multiplication) factor. To be the ×, a competent developer should be a team player and become the mentor of the less experienced team members. It creates trust and build better communication.
