Search this blog

18 July, 2019

What makes "10x" engineers. A complete hypothesis.

This happened on Twitter recently:


It's a long thread and I censored the author's name because it doesn't matter and I don't want to add to the hate that already naturally happens on any social media these days. 
To be honest, I'm still not entirely sure it's not just a parody, but I think it isn't. Regardless, it seemed a good excuse for a blog post.

Let's for a moment forget about how good or bad the term is. I don't particularly love discussions around words. I've never used "10x" in my career and I don't find it particularly great (also because it's linked to a certain start-up culture that I don't particularly enjoy), but I don't really want to open that can of worms.

What's wrong with a description of a "10x" engineer like the one above? 

I hope it's obvious but I'll spell it out. It tries to describe an engineer not in terms of the work they do, the actual output and results, but in some kind of mystical terms.
Like you can infer people's skills by looking at how they dress, what they eat, what time they come to the office and so on.

It doesn't help that the attributes this person uses as signals for a "10x engineer" are all kinda on the introverted side of the spectrum, to be charitable, as introversion per-se is a test of some kind of smartness. It's close to the old Hollywood trope of the computer guy being a weird, overweight, sexually frustrated white guy.

Ok, now that we closed the chapter on the critique of random people's tweets, let's get to something more interesting... 

Do "10x" engineers even exist? What are they? And what makes them?

Let's start from that last one. 

What's a 10x engineer? Typically we think of "10x" engineers as people that are much more productive than the average when working with code. Code "wizards", "ninjas", "rockstars" or whatever else cringe-worthy moniker teenagers use.

In my experience, 10x engineers do exist. Even controlling for seniority, knowledge, and skills, productivity is not uniform among people. I hope this is not controversial, one can know something, be even experienced in doing a given thing with a good track record, and yet not be as effective at doing it as others.

Should you hire only "10x" people? Definitely! Sort-of. In a way... We all look for excellent people, of course, and being able to distinguish good from great among a given seniority level is certainly important.
That said, there are lots of ways to be excellent beyond coding. In a decently-sized team other aspects might even be more important, mentoring, coordination, project management and so on. As things grow code usually tends towards being an implementation detail, so to speak, secondary to product and people concerns.

Even if we just look at coding, there are lots of kinds of engineers, people who are great at handling huge, foreign code-bases, people who are great at fixing things, people who are great at creating new things, people who are great architects and so on...

Lots of things in which you can be "10x" - but still, the concept of productivity being separate from skill generally holds.

These multipliers are also of the hardest to assess in interviews because again we're saying it doesn't correlate with simply what a person has on the CV or their ability to answer technical questions. Correctly characterizing where this productivity comes from is thus of utmost importance.

Why are some people more effective than others, given the same skillset? Where does that effectiveness come from? Is it their choice of editors? Their typing speed? Some sort of flow-related supernatural focus? I think not.

First Hypothesis: Output = Skill * Effort * Allocation

Skill is knowledge and experience, what we usually mostly correlate with seniority levels. As an analogy, I would say this is the value of the chips you have, at a gambling table.

Effort, given the same workday, is mostly focus. It's a time management skill, the ability to execute your tasks in good-sized chunks. In the gambling analogy, this would be the number of chips you have.

Focus is partially environment-related, but what we don't say often enough is that a lot of it is a skill. A lot of it also relates to how much a person likes doing a given thing, how fit he is for the job at hand. Effective managers that try to hire and allocate people to do the things they are passionate about, can thus help to get the most from the effort multiplier.

The last aspect, what I called allocation. This is how you spend the chips you have. Second hypothesis: correct allocation is what "makes" a 10x engineer.

In other words, we all have a number of chips to spend each day on our tasks. And controlling for seniority levels more or less effectively capture this number, there isn't that much variance in that.
The part that has a lot of variance is the allocation. Not in what to do, as in prioritizing this bugfix to that feature (even if such skills are also fundamental and have very high variance we capture them well in job categories, think technical director versus principal engineer for example) but how we do things.

Do I use a scripting language, should I implement things in C, or maybe I should learn that fancy new language everyone's talking about? Do I rely on a library or write from scratch? Do I need to understand the overall architecture of this software? Do I need to understand the specifics of the functions I'm calling? When it's appropriate to be sloppy? Should I jump into prototyping or I need to learn about the state of the art first? Should I go deep or wide?

We always have a limited amount of resources, ability to keep things in our brain, of doing work. And software design has a lot of different dimensions, abstraction versus specificity, generalization versus integration, high-level versus low-level concerns and so on. 
The ability to navigate this design space and selecting the right tools for the job, both in terms of concrete artifacts (code, libraries, languages, IDEs) and of abstract methodologies, makes a huge difference. One thing is to know about things, the other is to be able to critically evaluate tradeoffs and allocate (your) resources well.

Third Hypothesis. The reason why "10x" skills look mystical is that we don't have a solid theory for allocation choices.

When we have a design space that lacks a solid theoretical framework to navigate it, all success looks random, unteachable, and mystical. This is why "10x" engineers are both rare and sometimes described in horrible ways like it was done in the twitter thread above.

Too much of programming is still an art, eventually some people "get it" after lots of exercise, but we don't really know how to replicate that success.

We accept that somehow of the huge talent pool of software engineers, some will somehow find a way to be productive at some things, and some will be less successful.

---

Update: I was made aware of this, which is a much more concise way of vehiculating the same message:


It's great that I'm not alone in this...

5 comments:

Anonymous said...

I'd agree that the multiplier effect of multiple contributory factors makes for the various "x10" (or x20, x100, whatever) factors, I'm not 100% behind the explanation for the 'allocation' factor being personal commitment and focus.

I'd suggest that much of the allocation factor is a by-product of 'good' (though sometimes accidental) management that has the right engineer in the right place. Opportunity to bloom is important, especially given the hinderances that otherwise reduce focus.

Some of it is just standing on the shoulders of giants, or being surrounded by a supportive environment. And once that initial bit of luck has pushed the x2-4 engineer forward they gain momentum and opportunity to reach xN, and then later other realities strike and many fall back a little.

Luck, opportunity, focus, on-going commitment, and others doing all the ancilliary admin!

WH said...

I also see that very, very, very few programmers and managers understand economical aspect of programming... that the farther the bug is from the programmer the cost of fixing gets exponential.

So most think only of speed of development, but nobody understand the stability and status of the code programmers write. Well luckily for me I'm one of those obsessed with stability, cleanliness and commenting of the code and get lots of work to clean and more or less fully redesign the old an crappy code (i.e. fast written code that nobody wants to touch as it's normally a spaghetti western).

So instead of searching for 10x, 100x guys, maybe they should start searching for those that at least know what they are doing.

at least in my view...

Anonymous said...

I've experienced both modes myself.
Having some 20 years of experience as engineer I have been a 10x engineer and a lesser one.
I have always been very motivated and never list interest in tech and have been constantly keeping myself up to date.
Still, the environment matters so much in how you perform. Working with like-minded, driven people, boosts your performance. But when I worked at a company where they had a fairly complex financial product, but without any clarity or comments in code, nor any other documentation about functional or technical matters or decisions. The colleagues also didn't have time to explain stuff, nor did they care, I felt extremely bad at this company and was not able to really be productive, so I got the lousier and dumb jobs to do like deploying stuff and all, the jobs that the existing employees didn't like doing.
Needless to say I eventually left. For a company where they take time to bring you up to speed, and in no time I'm really performing at 10x....

c0de517e said...

PhilipOakley: that's not what I (tried to) say. Allocation is not commitment, Effort is. And Effort is also related to "job fit" which managers can help with, I do agree and mentioned that.

WH: this cuts both ways, lots of people do not understand the economics of programming, that's true, including the fact that code debt is debt, which is not always bad. If well managed, debt is a great way to push for growth. Badly managed debt is toxic...

Anonymous: totally

TomK said...

I think what is missing that different people have different abilities, and some can solve more complex problems, and difficult problems. It's the attitude, and the ability to be focused under pressure. The more senior, the more likely to be able to think on a larger scale. This combination is what makes 10x => be able to see the system, and now how to deal with the problems, what compromises are survivable (not perfect, but does not cause cascading errors) and be able to communicate this to other people. The swiss army knife people.
Management loves these rare kind people, and they "kill" them very quickly. The reason they are so rare, that by the time to learn how to do this, they learn that its not good for their health - and learn to delegate, or burn out, Because that "10x" is just another human being, and they hopefully know their limits.