Hacker News new | past | comments | ask | show | jobs | submit login
Playmaker: The Reality of 10x Engineer (oferka.medium.com)
105 points by oferka 7 days ago | hide | past | favorite | 79 comments





I once had an employee who was by no means a 10x engineer, he was honestly lacking in a couple of technical areas.

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.


The senior engineer on my past team was also this way. He had strong domain expertise, but he was definitely not the best technically. But his greatest gift was his ability to bring everybody together and be a strong mentor the junior engineers. We called him a force multiplier, and he was awarded many times for this.

Was this person rewarded for his "glue" contributions?

As a manager this is the most difficult type of skill to quantify in order to get raises approved.

If anyone has tips for how to sell the value in this, please let me know


“We can’t afford to lose this person.” Managers love status and insight. If that’s not enough, improvement is not a primary goal, and likely it’s time to move on.

Might work in a startup but senior leadership at enterprisey companies will not accept that as an answer.

They love metrics and that sort of thing, that's why it's hard to quantify even though it's clearly valuable.


Good leaders will help you and can recall instances where your knowledge helped.

Then they can lose two valuable folks. Sucks to be them.

We had a people choice award for such work. And then you could use that in your appraisal.

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.


Off the top of my head: how about quantifying it like, "If we didn't have this person, we'd waste X person-hours over the course of the year"? That should help you put a number on it.

Yes, but I had to constantly fight for it! I'd have to explain to other leads that, yes, his code velocity isn't that good, but he's also the reason I knew I needed to lend your team support last sprint.

This is what I hope to be for my team as I feel like I'm at least a -3x engineer.

Embrace a growth mindset and develop your skills.

I don't think the 10x engineer idea was targeted at the coding skills itself. Given that, the engineer you mentioned is definitely a 10x

He seems like to be a highly skilled product manager than a developer, both are different roles and people should be motivated for the right track.

No. This idea that developers just write code and leave all the "squishy" problems to the pointy-haired bosses is not only wrong, but actively hurts teams. If you move this person from engineering to PM, they will not function in the same way.

so you valued him for being a little snitch?

Neither of these types align with my definition of a 10x engineer. From my experience, they are engineers that understand both product/business as well as the technical side such that they can drop requirements that add a very small amount of improvement and in turn it significantly reduces implementation cost/complexity. They have the ability to instantly visualize system design and architecture for any features/new items enabling to quickly make these realizations and move fast. At the end of the day the ROI is what matters and SDE resourcing/capacity is the most limited resource. I have seen 100 SDE week projects turned into 4 weeks from individuals with this skillset.

This is exactly it. The idea of a 10x engineer isn't one who codes a similar implementation 10x quicker, that's ridicules and clearly taking the idea too literally. There's a clear upper bound on implementation efficiency, and it's probably below 10x. There is, however, no upper bound on efficiencies gained through creative problem solving.

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.


I agree, the efficiencies of a 10xer are usually in creative solutions to business problems, and 10x would be on the conservative side of what I’ve personally seen achieved. Unfortunately there are also .1x developers that don’t understand the business, or it’s not part of their role. They crank out tickets of rote changes in a pre-existing system. Any large or architectural work is turned into tech debt because they hamfistedly cram it into some existing system or use whatever tech/pattern they’re used to rather than reasoning about the problem and solution from the ground up. This is an organizational problem as much as a personal one. I’ve seen this a lot with offshore workers because they don’t get to see and interact with as much of the business without a lot of effort and support from the org.

I've seen what you described as ".1x developers". It's not a big deal, usually because businesses, that hire .1x engineers, rewrite their entire products every 5 years or so. And when you start fresh from scratch, it doesn't matter if you are a 10x or a .1x: business only cares about pushing something to production as fast as possible. Technical debt will be fixed in the next batch in 5 years... by rewriting.

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)


I agree with your statement. A 10x engineer doesn’t deliver code 10x faster but rather delivers 10x value to the company. They are more than an engineer who plugs code in an IDE. They are a company man/woman who understands the business, business processes and the customer. A 10x engineer can anticipate the needs of the sales and finance teams. They understand how technology can impact the customer or how the business generates revenue. A 10x engineer isn’t always the person who places 1st in a coding competition or knows how to write every sorting algorithm without reference.

Agree with your observation that there is a huge value in having someone that is super technical but still have a deep understanding of the product and business. Exactly for the reason you stated, being able to filter out implementation complexity without reducing the value to customers. In most organizations that I worked on this was done by the first line R&D managers, but I do agree that in some cases people that spent long period of time in managerial role might miss the technical complexity areas. Thx for your comment.

I’ve heard the term Product Engineer used to describe those qualities.

I'd prefer the term Engineer... I'm not sure why the best engineers need a separate job description!

Because there are many ways to be a developer, and it depends on your role and your product to say what is the most effective. Sometimes "10x" is a matter of fit.

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.


Sounds like you just want a unicorn.

Actually, what he describes is just ‘common sense’ from people that think for themselves. The problem is that these people don’t do well in the education-hiring-promotion pipeline. They’re seen as disagreeable and threatening. You can’t change a 100-week project into a 4-week result without trashing a lot of people’s big ideas. They might have one home run, but then get isolated into a corner because nobody wants their work criticized. Then they learn to keep quiet and count out the days to retirement just like everybody else.

Your weekly reminder that the 10x engineer theory is that the best engineers are 10x better than the worst engineers. Which means they are 2 to 3x your average engineer. They aren't going to make your team 10x better unless your team is really bad.

The worst engineers destroy value instead of creating it. Less bad than that are engineers who create arbitrarily small amounts of value for the product and team. The 10x engineer concept only really makes sense as "10x typical".

I've come to call this value destruction process "negative work". Typical negative work activities include injecting that new shiny tool into everything because its new and shiny, refactors that require refactors for a single line change that never happens, writing buggy tests and pushing then writing a follow up task to fix your buggy tests that are blocking the pipeline then not doing that task, only doing 'manual' testing, telling the team a tool doesn't work only to realise the dev didn't know how to use it, endless wiki page re-writes, using stand-up meetings as a bitchfest etc. Fortunately, I've become better at recognizing negative work patterns and removing those dev's from my team. Your team will die from attrition if you don't.

Your yearly reminder that the original use of 10x engineer referred to an engineer who took 10 times longer to the same task as the typical engineer, and has also been variously subverted since in a variety of ways including the “team multiplier that isn’t especially more productive, but is the secret sauce that makes the team 10x more productive.”

I dunno, I've met one person who is 10x better than me and I'd consider myself average. I think they must just be very very rare. It's difficult to measure "better" in some cases anyway - you could have 1000 average engineers and they'd never come up with a bloom filter or arithmetic coding or whatever.

Engineering talent likely falls on some sort of distribution like most everything else in the universe.

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.


This is good to know. I always thought it meant 10x average which seemed absurd. I can certainly attest to having worked on teams where there are one or two developers 10x better than the worst developers on the team. Tbh I think the worst developers are actually negative value because they take so much time from other developers.

One source for the 10x number is the book Peopleware. They did Coding War Games where developer got an exercise. The 10x is the time it took them to code an application which fulfills the requirements. The best is 2.5x compared to average.

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.


"A bad system will beat a good person every time" as Deming said.

No it's not. The "10x" is 10x average.

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.


Taking it literally seems kind of silly.

It's directionally correct and that's all. It's not precise, but it's accurate.

Probably varies depending on the organization too.


I'm not a fan of the 10x programmer concept. I have worked with some brilliant people, some incredibly efficient people, as well as both medicore and poor coders.

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.


It's pretty much all of the things mentioned in the post and comments. You don't really know you had a 10x until they leave then little by little problems show up more frequently, take a bit more time and people to fix, trends upward, then snowballs and no one really knows how they got to this point. Having 10x is like having elves that magically make problems you don't know about continue to not be exist in most everyone's worlds.

At least for me, when I hear "10x" engineer I think of the ones who treat the craft as a craft. There is no "shallow" or "narrow" in them. The possess the important skills in software development:

    - ability to learn quickly
    - understanding how to debug and track down problems
    - not afraid to jump in where needed
I've worked with plenty of "frontend" engineers and "backend" engineers. I've worked with people who are "SREs". These people have specialized and are usually GREAT at their craft. But I don't lump them into the 10x engineer.

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.


For me, a 10x engineer is about rate of value-add. Maybe its some of my manufacturing background, but I feel like the best engineers are constantly thinking about how they can increase the value of the product relative to customers (internal or external). These are the only things that really seem to matter at the end of the day.

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.


So much this. Quantifying the cost of delay and prioritising the things that have a high cost of delay over duration (CD3) in order to get the most value out the quickest (even if that turns out to be paying off technical debt where accrued interest is the cost of delay) is the hallmark of a fantastic engineer (and product owner, and salesperson, and ...).

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!


> 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?

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.


I agree mostly with this. If someone is working on a side project then they are entitled to conduct that however they see fit. However, there should be zero expectations that this output can then magically translate into business value simply because it was undertaken.

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.


> that almost always means rigorous engineering/planning to make sure everything lines up.

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.


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?

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.


I know an, objectively, 500x engineer.

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.


Why were they taking engineer blood samples?

To see. Burn-out has a lot of practical importance.

Finally a decent fucking story. I want to know more.

The joint project was called Ellemtel. I knew the project lead, and the guy who counted up whose code it all was. I don't know if anything was published about the project, I just got these details from them.

Thinking it over, it must have been 250 engineers each, 500 total.


He's CTO at a Canadian company, now. Likes deep-water cave diving.

Please story OP don’t leave us hanging

10x engineer is underpaid senior working as middle/junior. or underpaid architech/principal workong as senior engineer.

Exactly. Everyone wants more developer for the same amount of money, but are they willing to pay?

10x definitely has nothing to do with salary in either direction - you can't conflate productivity with salary and expect to make sense of the world we operate in.

just bump your 10x engineers in grade and salary and suddenly nobody will think of them as 10x engineers. They will be just typical specialists at their place and their level.

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


"I want to take you back to 2012. I was working for HP, leading the R&D group"

Please don't take me back to hp in 2012.


LOL. "Experience is simply the name we give our mistakes" - Oscar Wilde

> ... if so many employers are looking for 10x engineers and some are willing to pay them 5x or even more...

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.


Agree. productivity as in "works faster" is not something that justifies being treated (and payed) as 10x engineer. Evaluating "value" of an engineer is also a topic of itself. At the end of the day, this is a team sport. even when a certain project is super successful (and in some cases it might take few month to see business impact) it's not always easy to know how much each individual in the team contributed to this success. BTW - same is true for failure.

Some well thought out points in this post. I'm of the opinion, though, that the concept of a "10x engineer" just isn't a something to be advocating.

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.


My favorite thing about 10X engineers is that I don’t have to lose my own sleep or salary. I’m pretty sure life is a marathon and if you try to go too fast you will bonk eventually. I hit my threshold but I am glad they haven’t. I used to be a 10X engineer in my 20s but since getting a little older with a family I can’t.

Engineering companies used to be organized by function rather than business. This 10x engineer would be a manager. The person in charge of you was the person that you can learn the most from. Project, program, and financial management came from a business group.

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.


Make your own 10x engineer by investing time and money into your engineers so they get 10x better. You can try to suss out which interviewee was the best, or you can define what makes a 10x engineer at your org and train your current employees to that level. Everyone's has their area where they are 10x, find that for your employees and bring it out.

Very relevant: https://yosefk.com/blog/10x-more-selective.html

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.


The article and comments here matches my observations. There are many ways to be a 10x engineers but basically none of them is about writing better code or solving algorithm problem (outside of a few very specific domains). Writing good code is necessary to be a competent engineer and one need to be competent before becoming 10x, but it’s not a sufficient condition.

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.


For me a 10x engineer is an engineer who gets the work done, in opposite to the average developer who gets the work not done. Eventually in 2-5 years, but who needs that. Mostly not at all, or with huge cost overruns.

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.


If you work in a shitty workplace where everyone is demotivated. You have a good work ethic. In fact if they only work at 10% and you work at 100%. You're 10x those peers. You end up doing 10x the work as your peers because they do nothing.

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.


Nobody wants 10x developers these days. All companies are looking for 1/x developers because then they can brag about their head count to get acquired or to raise more money from investors or banks.

Not sure about the entire industry, but at least for the companies I worked in/with during the last few years, it's the opposite. In most investment rounds/IPO/acquisition scenarios, high HC is a disadvantage. I have seen investors that are actually treating the revenue per HC number as a performance indicator.

Exactly! The idea that having more employees is better is complete BS.

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.


You have to distinguish between the incentives for the company and individuals.

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.


Bad for the company, good for middle managers that can brag about managing 50 eng at their next gig

This definitely happens. It's a legitimate strategy. When the customers come tour your company offices, do you want it to be a tiny little 5-man hole in the wall above a coffee shop in SF? Or do you want an entire floor of a building, with dozens of people drawing things on whiteboards? If the excess headcount will get you the customer, and the contract is worth more than those developers make in a year, then the choice is obvious.

Of course, you have to actually use all of those people, otherwise it's dishonest. And customers aren't wrong is not wanting to work with smaller suppliers. Headcount can be evidence of ability to deliver.

I've met some 10X engineers, not the one's you've described but ones that take 10X the time to finish than they initially estimated.



Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: