Playmaker: The Reality of 10x Engineer
oferka.medium.com
oferka.medium.com
He was a 10x catalyst for the team though. Everyone came and talked to him about their problems, he motivated people to learn new skills, and he knew at least a couple developers on every one of our partner teams.
If I wanted to cut through the BS and find out what was really going on, I'd just ask him. "Oh John's team is actually behind schedule, their PM is full of it and their lead is in denial, they'll actually ship a couple weeks late at best."
Was he a 10x engineer in terms of code written? He had his moments for sure (some of which had huge business impact), but his real value was all the connections he had formed.
If anyone has tips for how to sell the value in this, please let me know
They love metrics and that sort of thing, that's why it's hard to quantify even though it's clearly valuable.
But yeah, I used to do this just for my own interest of learning. Companies can't accept that only one or two persons are doing this. They would say - its a part of the job.
One thing you can do is keep tab of problems and create a common resource point for all the team. And use some kind of way to show hours saved. Long shot but it holds a substantial promise.
Consider an engineer who is dedicated to performance. In the wrong organization, this kind of person can be harmful or neutral. However, if the same person at Twitter in the "fail whale" era, they may be a key contributor to keeping the organization afloat until more substantive changes take effect.
In a B2C company, product engineers are more evident. At a B2B in a sector that isn't self-evident, the same product engineer may not have the domain expertise to contribute in the same way.
It is one aptitude that many effective engineers have, though.
The real magic, as you noted, is in understanding the business and being an expert in creative problem solving. A 10xer might develop a tool that thousands of people in the company use and saves millions of hours of time. Or they might design a system with the absolute minimum of complexity, that is a joy to work on and reduces turnover and increases feature velocity. Or, they might just learn to say NO a lot and cut scope creep and allow the company to deliver what's actually important.
I imagine some people don't believe in 10x engineers, because they work really boring jobs where creative problem solving isn't that important. When the implementation is straightforward there's not going to be that much of a gap between the worst and the best. But even in a boring job there is ample room to be a 10xer, you just have to think outside of the box more, understand the business, and understand what's causing friction in implementation.
In more serious/long-term companies, since the interview process is more difficult, you don't usually encounter .1x engineers and what I've described doesn't happen.
All in all, there's room for everyone (.1x and 10x)
Since it is a single person task, they cannot impact anyone negatively.
However, the most interesting fact in my opinion is that within the same organization the difference is only 0.3x. Either the organizational environment determines your productivity or the organization determines which kind of developers get there. The experiment does not tell us anything how the productivity of a developer changes when he changes organizations.
Whether it's normally distributed or not I don't know. Some of the variables that underpin engineering skill are independent, but software careers have a tonne of path dependence where the types of software and problems you work on feed into the types of software and problems that you get to work on in future and that has a big impact on your skills and that particular variable isn't independent.
I still work with the assumption that the distribution is normal just cos it's easy to conceptualize. So maybe it makes more sense to think about the 2, 3 and 4 sigma engineers than the "10x" engineer.
And yes, they will make your team 10x better, as can will decisions which will help the whole team be more productive, or allow you to hire juniors, simply because good code and architecture is simple to understand and work with.
It's directionally correct and that's all. It's not precise, but it's accurate.
Probably varies depending on the organization too.
There are things brilliant programmer can do and concepts they can realise or creativity they can apply that a poor programmer couldn't dream of.
But it's never quite so simple as 10x, never so easy to quantify as their being able to complete a given task faster or produce more work.
What I have seen far more often however are programmers finding sneaky ways to appear more productive. Cutting corners, hacking things in and - an often overlooked technique - happening to have a such a good knowledge of their own pile of crud messy code that they can in fact produce solutions _considerably_ more quickly (because you know your own mess better than other people's).
None of these types of programmer are good for an organisation, some in fact are positively toxic and very destructive. In many cases a better programmer would take longer, sometimes considerably more so. But by perpetuating this 10x idea things get topsy-turvy and it's the poorer coder who gets categorised as brilliant and the brilliant coder who gets categorised as poor.
Another aspect of the 'rock star programmer' meme (which this is a variant of) is somebody who's genuinely very sharp can often be good at coming up with ideas but lousy at implementing them and worse at taking criticism. I've seen an extreme example of this in my career.
Often the best solution requires careful thought, consideration and design. The best programmers are the ones who weigh up the RoI and, while remaining practical, think things through carefully.
Unfortunately I've worked at a startup (from employee #1 to multiple VC rounds) where the CEO believed in this meme and seen the damage it does first hand.
- ability to learn quickly
- understanding how to debug and track down problems
- not afraid to jump in where needed
For me the 10x engineer is the one who will jump in on react one day and then rust the next. They'll write ansible scripts and automate SSL renewal and then fix a CSS bug the next day.
They'll talk through problems with anyone on the team and help get through the block.
Think of people like Miguel de Icaza ( https://github.com/migueldeicaza ) who have such knowledge and skill to build complete popular programming languages (Mono), Cross Platform Mobile Platforms (Xamarin), Spreadsheet Applications (Gnumeric). But have no problem building simple iPhone apps in swift.
Think of people like Anthony Sottile (https://github.com/asottile) who works on most of the developer tools us python devs use on a daily basis (tox, pytest, virtualenv, etc). Who maintains and builds ubuntu and debian repos for every new release of Python so we can get it easily (deadsnakes). But spends time to explain simple concepts like using "--rm" with docker run to developers.
If you have worked with someone like them, you know you are in the presence of a 10x engineer. There is no doubt in your mind.
Would you consider someone a 10x engineer if they can crank out a super-fancy backend service in 1 weekend that nobody wants to pay for or actually use? I know a lot of developers who occasionally fall into this trap (myself certainly not excluded). They can very enthusiastically produce output at the drop of a hat, but then we frequently have to put this output in the scrap bin and figure out how to recover the wasted time. This is why for most developers we have to have explicit design review sessions to make sure we are staying focused on the important value drivers. I have to make sure our work activities are well-scoped and broken down into small enough pieces to prevent elaborate trips into Alice's Wonderland.
Note that when I talk about value-add, that also includes paying off technical debt. Determining what debt to pay off is just as important as determining what new features to roll out. Determining how to balance debt vs feature development is one of the most arcane and dark magics. This is where the 10x thrives.
I've been missing this opinion in virtually every productivity discussion on HN the last few weeks, at least, but could never be bothered to write the comment. Thank you for taking the time!
They would perhaps be a 9x engineer, but that's still fine.
I don't think a 10x engineer, like most people, would want to be "optimized" at all costs.
And since you mentioned "1 weekend", I think that says it all. It's their spare time, and if they want to use it for coding, then that's their choice.
Most software that is written is regrettably garbage in terms that business owners actually care about. If you want to do something hard & correct (aka valuable), that almost always means rigorous engineering/planning to make sure everything lines up.
We wouldn't expect a structural engineer to be able to employ one of their hobby designs for actual use, nor would we ever want to entertain that idea. I feel similar thoughts should apply to software engineering, which in some cases is also life safety critical.
Trying to plan a software project up front is a great way to miss the mark and fail to deliver value.
Going with a "hold before tape before weld" mentality to prototyping and experimentation, we can get a lot of real-user data out of just putting something quickly out there and refining it as we receive feedback on it.
This approach is based on the fact that most of our good ideas aren't that good, so we optimise for the case where were wrong, and try to plan as little ahead as possible -- because any planning is based on imperfect information and requires speculative work that is likely to need to be thrown away.
In contrast to manufacturing where we need only to minimise work-in-progress, in development, we also need to minimise design-in-process -- also known as planning.
This is a way in which product development is different from manufacturing.
In manufacturing we can stamp our variability. In development variability is both desirable (it's how we innovate) and quite large, so we must obsess about maximising our use of feedback to guide our designs.
There's more on the perspective in Reinertsen's book on the Principles of Product Development Flow. I highly recommend it for anyone, but particularly someone who knows a bit about manufacturing but wants to effectively translate this knowledge to product development.
In a competitive situation a person might be 10% better but win 10x as often as the next best person. This is often taken to mean they are 10x better however.
This was measurable because of a joint venture between Siemens and Ericsson, in the '90s. Each sent 500 engineers. They had six months to produce a deliverable, that could not be late: the classic Death March project.
This engineer was responsible for assigning tasks to the others, and to himself. Each engineer got two-week tasks. Come 2nd Friday, if somebody's task wasn't done yet, he did it himself, over the weekend.
At project end, fully half the code committed to the delivered product was his.
The project was unusual in other ways. Stress is objectively measurable given blood samples, which they took. His were the only that did not show rising stress. They took samples again months after the project ended. Stress levels (in the others) had not declined.
Death March projects are really, really harmful: physically harmful to engineers, but also to companies that hope to get something from those engineers afterward.
He knew someone else who coded 10x faster than he did, wearing out 2 keyboards a year. So, he wasn't proud. 500x was enough for him.
Thinking it over, it must have been 250 engineers each, 500 total.
or there could be another possibility: You think you have 10x engineer on your team, but actually you don't have them. You just keep employing a lot of 0.1x engineers that are unfit for their position/level/grade
I think the latter view is why companies like amazon/netflix fire a lot of engineers that they think are 0.1x or less than 1x
Please don't take me back to hp in 2012.
Now we’re no longer talking about productivity but about value. Why a company decides to pay well above the average for an individual is going to depend on a lot of things, starting with whether they can even afford to pay this much.
Edit: Making these pay levels all about productivity, in yourself or others, ignores a lot of other avenues that can increase your value.
In all walks of life, there are the weak, the strong, and all colours in the middle. Why do the strongest need to be labeled with an exact number? It implies there's a sort of fixed scale, that someone could be an 7x or 8x engineer. It's a form of gate keeping in the same way that being "senior" engineer was/is a coveted title to be earnt.
The best people should be celebrated and rewarded accordingly, but we should move away from absolutist titles that push people to strive for a completely subjective label.
This was before the popularity of the MBA. I think what happened is that there is a massive oversupply of management, and it’s harder for engineers to keep skills current, so senior engineers tend toward business activities. Of course this means juniors stagnate technically as well, so the only way forward is through entrenching oneself as management.
What you’re describing is a 10x leader, and you’re not going to get 10x from a newcomer to a team that already has a leader. More likely you’ll get an exit due to ‘bad fit’.
Consider also that 10x is the expected benefit of leadership. Those that seek a 10x engineer should probably look at the 1x manager.
I agree with yosefk's observation. The people who are consistently 10x more effective are, in my experience, those who manage not to deal with unavoidable-accidental-complexity in problems. It's not their only strength, of course -- they are also very good at what they do.
But e.g. if your work depends on another person responding to your work in some way (e.g. interfacing to a buggy system you have no visibility into), it doesn't matter how fast/good you are - the progress is throttled by the other party. I haven't seen anyone 10x their way through such a setting.
Yet this is what almost all companies that are looking for 10x engineers primarily test for during interviews; their ability to write code. Seems to be a mismatch there.
Additionally many developers are costing more than they gain, the 1/10 developer, but more like the negative developer. The ones you need to get rid of, but mostly gather around senior management, CEO and blocking progress and playing politics. They usually are promoted to managers, and that's where the big trouble starts.
Most complicated work is too hard for any normal developer (the 95%), you need to get the developers who can get it done.
It's simply binary, not 10x or rockstar. Either it works or not.
We all know that start-ups work because they are small and focus on problem solving, not dealing with bureaucracy and administrative inefficiencies.
Look at the whatsapp acquisition. It was touted so much because the company had only 50 engineers.
High revenue per headcount is a good indicator of successful execution, good hiring practices and organizational structure, and a solid culture.
If you can achieve the same results with 5 people that a company needs 20 people for, you'll obviously be the more profitable and desirable company for a VC to invest in.
For example, it makes little sense for a company to use a different web framework every year. It makes sense for individual developers to accumulate a large list for their resume.
Likewise, it makes not sense for a company to optimize for a large headcount. It does make sense for an individual manager because leading 100 people looks better than 20 on his resume.
Whereas if you work at a place that has good management, people are motivated to work because they are well respected and not micromanaged. Suddenly if you work 100%, so are your coworkers working 100%. You aren't 10x. So you have to work on boosting your coworkers.