If you meet the 10x X on the road …
The 10x Engineer, once again … sorreeee ;-P
Yes, it’s been done already, from many angles. Some claim it doesn’t exist. Others posit that a very few engineers may merit such a title, but that those same engineers are invariably damaging, if brilliant, jerks. A few wise-guys will even promise to elevate you to those dizzy, 10x heights. And now, I’ve decided reluctantly to address it: I feel there is just a little more worth saying on the topic.
The 10x idea goes back way further than the mid-2010s, when it became a lowkey lulz-ish meme.
The epithet ‘10x Engineer’ came from a 1970s book: The Mythical Man Month. Since then, the analyses it presented (it found a few programmers to be ten times more effective than their peers) have been utterly debunked. The current consensus is, if somebody seems to be ten times better than the rest of their team, they must be cheating on some level, and hurting the team’s overall effectiveness. The best thing to do with a 10x-er? Help them find the exit door.
While mostly agreeing with the consensus, I’m convinced a bit more nuance would help. Not all 10x engineers, or wannabes, are the same.
Over the past quarter century — as an itinerant tech consultant to various industries— I’ve worked with hundreds of people who could be called ‘engineers’, in some sense (600 or more of them, easily!) This has included electrical and electronic engineers, civil and mechanical engineers, chemical engineers, transport and logistics engineers — as well as the gamut of computerey folks: software (most frequently) and hardware engineers; data and ML; DevOps and platform; cloud and network; quality and reliability engineers. This gives me a little confidence to suppose that the recurring 10x behaviours I’ve observed are general patterns, and not just due to my poor choice of colleagues.
Here follow my observations on:
- the 10x phenomenon in general
- the various types of 10x-er you may encounter
- how to deal with them as a team-mate or manager
- and what to do if you find yourself becoming one of them
It’s a software thing
Nobody I’ve met from a traditional engineering background is 10x or tries to be. None. Not one single civil engineer, electrical engineer or mechanical engineer. Some of them are brilliant, sure. Some are work-obsessed. Many have an ego: they might love accolades and extra letters after their name. But not a single one of them is desperate to highlight his own genius while poo-pooing his peers. Not one of them tries to be so fast or so cryptic that her colleagues can’t review her work.
Same goes for all the non-software-development specialists in IT and other STEM fields. I never met a 10x-er among them.
‘10x engineer’ is a misnomer. There are only 10x coders.
It’s not ‘a man thing’
Roughly 10 percent of my software engineering colleagues have been female. (It’s becoming more balanced over time.) About 20 percent of the ‘10x-ish’ types that I can remember were female, and some of those ladies displayed the very worst 10x traits. So, these behaviours are not, as some suggest, just boys being boys. They must be, either: something that software development work does to people; or something about the type of person that the field attracts. Or both. (In the examples below, I’ve stuck to using he/him, but only to fit the archetypal characters, as you’ll see.)
Why is programming uniquely blighted?
It’s easy to guess why bona fide engineers are less bullish and more collaborative than programmers. A collapsed bridge is typically more obvious and more lethal than a buggy program. Engineering degrees are challenging, and ethics are baked into the syllabus. Nobody graduates from them still believing they are smart enough to succeed by cutting corners, or by ignoring the input of colleagues.
Software Engineering is different. It has none of the inherent safeguards that stop a doofus from thriving in other fields. The tight marketplace for coders, and the prevailing working practices in software, provide incentives for all kinds of tomfoolery.
We’ll now see how that works in practice, as we review my unscientific and anecdotal taxonomy of 10x’s, in ascending order of nuisance …
10x Type A: Archimedes
The most benign form of the syndrome. This person is technically adept and socially inept — possibly neuro-divergent, definitely shy. Knows more Linux than Linus. When not at work, contributes to open source OS kernels. He tends to over-solve and over-engineer everything. Ask him to sort a short array of usernames: his code will do it in N dimensions, across all known character sets and locales. Ask for a way to check for an item in the array: you’ll get a Bloom Filter.
This person may gain a reputation as a 10x, but is basically harmless. His code will mostly be solid, and meet requirements. A lot of his time will disappear on experiments and side projects, if not closely tracked.
- Managing Archimedes: assign very concretely-defined and specific tasks. Allow ample time for personal projects and study, but only after the core tasks of the week or the sprint are achieved. Sit back and watch him burn tickets to get his golden time.
- Working alongside Archimedes: can be challenging. Practice patience. Avoid pair programming.
- If this is you: think carefully about which jobs to apply for. You’ll probably be frustrated at a web agency or writing business apps. You might like firmware or SCADA development.
- Number of times I’ve met this type: 4
10x Type B: The Ugly Duckling
As with Archimedes, it’s easy to have sympathy for The Duckling. He is different from the rest of the team in some way — maybe gender, ethnicity, education, social background — so he feels a need to work ten times harder than everyone else, to prove his worth.
This type suffers the risk of early burnout and of rare but costly blunders, due to a felt need to perform perfectly, and the stress it incurs.
Managing The Duckling: be explicit about your zero-blame approach to honest mistakes. Choose team-building and social activities carefully, to maximise inclusion.
Working in a team with The Duckling: resist the urge to let him do your work for you. Encourage him to contribute to team discussions.
If it’s you: relax, you made it.
I’ve seen this type: 10 to 15 times
10x Type C: Tolstoy
A.K.A. ‘The Ninja’, because they stay up all night preparing mega-commits that sabotage your sprint.
Tolstoy loves code for code’s sake. His output is prolific. He unilaterally decided to refactor your whole codebase. He has no concept whatsoever that ‘code is cost’, or to ‘keep it simple, stupid’.
Tolstoy is only rarely viewed as 10x, these days, because nobody sane still measures productivity in lines-of-code.
Managing Tolstoy: introduce and share metrics that favour concision, such as Pickup Time, Review Time and Cycle Time. Implement WIP limits and maximum commit sizes.
Working with Tolstoy: “tl;dr” and “YAGNI” are legitimate responses when declining a 200,000 line Pull Request.
If this is you: do a Polonius
I’ve met Tolstoy: 3 times
10x Type D: Patrick Bateman
Whatever Bateman happens to be working on today is the most important and hardest-to-write code ever. Bateman’s core belief is that he’s surrounded by morons. He must protect his precious code by — belittling other programmers, deleting their sloppy work (which is sloppy by definition, because not his), and by gaslighting them.
Bateman might be regarded as a charming high achiever by his boss and by anyone that he doesn’t see as a potential rival. The haunted faces and tanking output of his direct co-workers tell a truer story.
Managing Bateman: isn’t really possible. This is the archetypal problem 10x. If you can’t easily dismiss, maybe you can get him ‘promoted’ into another department and out of your remit?
If you work alongside Bateman: it depends. If you really like your job, call him out on his BS, and keep calling him out, publicly and clearly, with evidence. If you don’t love the job, or you’d rather do engineering than play power games, it might be time to polish your résumé.
‘Oh no, maybe I am Bateman’: therapists are within the economic reach of a software engineer.
I’ve experienced this type: 3 times
10x Type E: Cap’n Ahab
While Bateman may be troublesome, Ahab is far more damaging to team morale and to product stability.
Ahab wants to prove he can do something big and complex. It’s all about the thrilling bigness of big. Because he’s so hyped up about whatever his project is, he can get the rest of the crew on board, and easily persuade senior people to sponsor it. Whether it turns out to be a white whale or a white elephant, Ahab will have the whole team working on it day and night for months or years. All other tasks, including technical debt management and any parallel workstreams, will be quietly deprecated. The end result is total team burnout, often with little or no business benefit to show. It can take a team years to recover from an Ahab (Ahab will already have moved on to do the same thing somewhere else, claiming he’s just led a large team on a hugely successful build.)
Managing: is tricky. Insist on continuous delivery, iterativity, and regular delivery of new value to customers. Ahab is hard to detect, being initially very plausible.
Working with Ahab: try to inject some perspective. Good luck with that.
Avast! I be Ahab! Oh well, now you’ve noticed, maybe take a vacation. Get a hobby, or a life.
I’ve met this type: 2 times.
10x Type F: Baron Münchhausen
Worst of the worst is The Baron. This person lives inside a highly defended bubble of delusion. Like Bateman, The Baron’s code is always awesome (in his own mind). Unlike Bateman, he bears no personal malice toward team-mates, he might even be soft-hearted and sweet. Still, The Baron is worse.
His code is well formatted, and will pass a superficial review. This is because it was stolen from Stack Overflow, ChatGPT, or another team member. It may do something very well: just never the thing it was supposed to. The Baron’s code is accompanied by passing unit tests and integration tests, which only pass because they assert something trivial like 1≥ 0, or because they don’t drive his code at all. The Baron honestly believes that everyone else codes in the same way. Nobody finds his bugs until they take down the production server.
Managing the Baron: Is painful. You’re going to have to be just a little cruel as you attempt to burst his bubble. Chances are, he’ll conclude you’re a bad boss, jealous of his talent. At that point, he might move on.
Working with him: Ouch! Either fix the bugs on the fly, and let him remain in blissful grandiosity, or inure yourself to his sad puppydog eyes and challenge every day. Neither option will be good for your morale.
Could this be me? If you think it could be, it’s not you. The Baron never allows a hint of self-doubt to enter his mind.
I’ve met this type: 2 times.
[And there you have it. This was all meant as just a bit of fun. Please don’t worry too much, if you know you can be a bit like one of my 10x types on a really bad day. We all have our subconscious coping mechanisms for coding under stress. Keep on coding and enjoying it!]
