The “10x engineer.” Shudder. Wince. I have rarely seen my Twitter feed unite against an idea so loudly, or in such harmony.
I refer of course to the thread last month by Accel India’s Shekhar Kirani, explaining “If you have a 10x engineer as part of your first few engineers, you increase the odds of your startup success significantly” and then going on to address, in his opinion, “How do you spot a 10x engineer?”
The resulting scorn was tsunami-like. The very concept of a 10x engineer seems so… five years ago. Since then, the Valley has largely come to the collective conclusion that 1) there is no such thing as a 10x engineer 2) even if there were, you wouldn’t want to hire one, because they play so poorly with others.
The anti-10x squad raises many important and valid — frankly, obvious and inarguable — points. Go down that Twitter thread and you’ll find that 10x engineers are identified as: people who eschew meetings, work alone, rarely look at documentation, don’t write much themselves, are poor mentors, and view process, meetings, or training as reasons to abandon their employer. In short, they are unbelievably terrible team members.
Is software a field like the arts, or sports, in which exceptional performers can exist? Sure. Absolutely. Software is Extremistan, not Mediocristan, as Nassim Taleb puts it.
That’s why Google’s original BackRub algorithm, developed by two grad students, was so much better than the multiple multi-million-dollar competitors back in the day. There are countless other examples.
But at the same time, software is very much a team sport. Ask any sports fan what happens when a player thinks of themselves as more important and the team. You’ll notice Carmelo Anthony is no longer playing in the NBA. It is widely accepted that the true measure of a team sports superstar is whether they make their team better, rather than how good they are one-on-one.
NBA teams are small; software companies, you’ll notice, are large. The larger the team, or, crucially, the larger it may become, the more important it is that an exceptional performer makes their team better… and the more dangerous and counterproductive an exceptional soloist becomes.
An exceptional soloist will produce reams of undocumented code that no one else understands. (I am reminded of Steve Wozniak’s infamous designs for the game Breakout, which worked for him, but Atari was unable to actually manufacture.) Will their code be more elegant? Maybe. But it may well also be both more terse and more complex, unnecessarily generic and abstract.
The killer question: is their code more maintainable? And it is often the complete opposite. You may get a head start from an exceptional soloist, only to find it turn into irreparable drag, as you bring on other engineers for whom the entire existing codebase is so baffling and complicated that it counts as technical debt.
So if you do find yourself with an exceptional performer on your team, how do you manage them? How can you be a Phil Jackson who turns a soloist into a team player? And the answer is: you have to handhold them just as you would an inferior performer.
An anecdote. Long ago, we hired an exceptionally intelligent young engineer to write some iOS code. He quickly began constructing, from scratch, with mind-bending speed, a fascinating intra-app asynchronous messaging system in which blocks of code pinballed around from one class, and one thread, to another. It was a fascinating, and powerful, approach… but it went against the inherent grain of iOS’s frameworks.
I was also adding occasional code to the project. (Leading to the memorable exchange when he said: “You know, at first I thought you were just some kind of manager,” contempt dripping from his voice as he enunciated that last word, “but then you started checking code in!”, the implication being that I now counted as a human being.) I found myself spending a fair amount of time encapsulating and restraining the remit of his messaging system, while still using its best elements. It all worked out, in the end, on budget and ahead of schedule — but I had to pay at least as much attention to his code as to mine.
If and when such exceptional soloists learn how to be exceptional team players, as this one did, then yes, they indeed give you a multiple of productivity. At it’s extreme that you get something like Jeff Dean and Sanjay Ghemawat. But in modern software development, it’s almost never, verging on never full stop, enough to be an extraordinary soloist. In fact, I would argue that if you don’t understand that you’re part of a symphony, then no matter how good your solos, you were never truly an exceptional performer at all.
Comment