There’s been a lot of flak over this tweet about recognizing the mythical “10x engineer”—the engineer that is so good that it doesn’t matter if they reduce the productivity of everyone around them.
The list, which you can read below, goes on to describe some of the key characteristics of brilliant but broken engineers. The ones that C-Suite managers and investors love to hire, because it’s easier to spot a heroic misfit than a well-oiled team.
I’m reminded of the people who say of some misogynistic artiste, “We can’t blackball them just because they sexually harassed people—they’re brilliant!” Sure, they weren’t bad, but were they better than all dozen of the people whose careers they ended? We see the productivity of the star, and we fail to see what the team could have done if the “star” hadn’t gotten in the way and left them with to deal with all the crap.
But tearing down someone’s list is easy. What we need is a set of rules that recognizes what the right person looks like. Here’s my point-by-point rewrite.
10x Engineers (the original)
- 10x engineers hate meetings. They think it is a waste of time and obvious things are being discussed. They attend meetings because the manager has called for a “Staff meeting” to discuss the features and status.
- Timings in the office for 10x engineers is highly irregular. They tend to work when very few folks are around. If there is a crowd or all-hands meeting, they are not visible. Most of them are late-night coders and come late to the office.
- 10x engineers laptop screen background color is typically black (they always change defaults). Their keyboard keys such as i, f, x are usually worn out than of a, s, and e (email senders).
- 10x engineers know every line of the code that has gone into production. If a QA or support folks alert an issue, they know precisely where the fault (or bug) is and can fix the same in hours vs days
- Most of the 10x engineers are full-stack engineers. For them code is code, they don’t care whether it is front-end, back-end, API, database, serverless, etc. I have rarely seen them doing UI work.
- 10x engineers can convert “thought” into “code” in their mind and write it in an iterative fashion. Given a product feature, they can write that entire feature in one or two sittings of 4 to 6 hours with a caffeinated drink without distraction.
- 10x engineers rarely look at help documentation of classes or methods. They know it in memory and can recall from memory. They write code at the same ease as writing English. No breaks, no pauce, just type.
- 10x engineers are always learning new frameworks, languages ahead of everyone in the company. They are not afraid of anything new. If there is something new (e.g. blockchain) they gobble up, setup, experiment before anyone is getting started.
- 10x engineers are poor mentors as they can’t teach others on what to do OR parcel the work. They always think “It takes too long to teach or discuss with others, I would rather do it myself.” They are also poor interviewers.
- 10x engineers don’t hack things. They write quality code and know exactly how the code has to evolve, and have a mental model of overall code structure. They write at most one design document, and the rest is in the code.
- 10x engineers rarely job hunt or move out of the company. They move out because you make their life miserable with the process, meetings, training, and other non-value-added activities. If you come across them, hold on to them. Celebrate them.
10x Team Contributors…
- …make sure all their meetings have clear agendas and well-defined action items. They prep attendees with email. They take detailed notes and communicate any decisions to the people who weren’t in the room. They value people’s time and make it clear when they will and won’t attend.
- …make sure their schedules overlap with their colleagues in multiple timezones so that people aren’t stalled waiting for them to make a decision.
- …know what development environment works best for themselves, but they make sure it’s compatible with the tools everyone else in the company uses.
- …have a clear understanding of the architecture and implementation of their products that lets them quickly identify problems and point to solutions. And when they don’t, they know who does.
- …know what their strengths are, and know when to let experts in other domains work to their strengths. They’re very aware of the importance of UX, and the fact that dismissing UX as unimportant is often a veiled attack on women, who stereotypically work in that area.
- …understand the importance of documenting their thought processes so they aren’t the only people who understand their code, and they know the importance of taking breaks and having others review their work and ideas.
- …use Stack Overflow just like everyone else. In fact, because management over-relies on them for multiple, completely different, projects, they probably end up using it more.
- …try to anticipate what tools others will need, and test and set standards for the use of them ahead of time. However, they resist the “object model of the month” club, which results in a lack of a stable development platform.
- …know that a strong team is one where everyone has a voice and everyone can work to their best potential. They mentor, they listen, and they go out of the way to support and promote their colleagues ideas. They know that everybody is bad at interviewing.
- …document their plans, and document what they did. They code for the future. If they have to hack, they document it even more. And they don’t let management forget about the resulting technical debt.
- …like all other people, work best in a supportive environment that values and celebrates all employees.
There are certainly more characteristics of a good hire, I just wanted to address the original list, feel free to add your own characteristics in the comments. And here’s another good list for ideas (h/t Nila).
—Kee Hinckley. Jul 16, 2019 in La Conner, WA US.
I thought I’d add an addendum here after an interesting discussion with someone who has worked for Shekhar and had very good things to say about his management abilities. He followed up to the tweet with this:
And I wonder here if the real issue isn’t the difficulty people have in finding and recognizing good managers who can properly handle both teams and mavericks. Ineffectual managers (fine when things are going well, but useless when things are difficult) are endemic in the industry. I’m still dubious about some of the qualities listed for 10x engineers, but I’ll grant that a great manager can make a huge difference in channelling the various skills and styles of different engineers. Perhaps what we really need here is a description of how to recognize a 10x manager.
I’m Kee Hinckley (he/his). That’s my wife 
