High Performance Individuals and Teams
pablasso.comWhether or not "10x programmers" exist, I can say for sure that 1/10th programmers exist. I know a few in that category. And it really amounts to the same thing.
> Whether or not "10x programmers" exist, I can say for sure that 1/10th programmers exist.
Not in this context. The term “10x programmer” comes from an observation that there is a factor of ten variation between the best and the worst programmers. So the worst programmers in this context are 1x, and 1/10th is meaningless. People hear “10x” and assume it’s ten times the average, but that’s not the case.
More information here: https://www.construx.com/blog/productivity-variations-among-...
I think the post of the parent is a bit tongue-in-cheek; I read it mostly as “I don’t know whether there are a few developers that are significantly better than the rest, but I do know there are a few developers that are significantly worse than the rest”.
It’s effectively the same thing, but from a different perspective.
From my own experience, I can tell you that programmers can even go negative with their productivity.
I've had one employee on my team who ignored my instructions, ported a critical tool to a new execution environment, added 20 additional dependencies, and then pushed the broken mess onto GitHub. After sinking some days into trying to get anything useful out of the source code, we eventuality just deleted it.
I think the multipliers also conceal another issue. A lot of programmers have a net negative impact on your code base. They may be "productive" in the sense that they produce a lot of code, but then that code is riddled with bugs that drag down the whole team's velocity.
If you're 10x of a negative impact then you just produce bugs faster.
It doesn't take broken code to have a net negative impact. Any code at all is liability, so if you're writing code, it better be worth it. Figuring out what produces value is surprisingly hard, so I would bet the majority of code being written has a net negative impact.
And then don't get me started on marginal profit. Producing some value is a lot easier than producing marginal value that outweighs marginal costs. Now we're talking a smallish fraction of the code being written.
> Even more important than finding great engineers is to avoid bad ones.
After reading that sentence, I thought to myself, "How long did I go from the start of my career before meeting someone of whom I genuinely thought, 'this person is so bad they should definitely be fired asap'?". In my case, I think the answer is somewhere around 20 years.
My takeaway from this is that at even with ~18 years of experience, my former self would probably not have appreciated the importance of this advice, as I had rarely or never encountered such a person thus far.
I felt similarly as an IC, but my perspective changed as I shifted into management.
I didn’t believe that “negative value” engineers existed when I was working on the front lines alongside other good engineers. In reality, I was seeing the end result of competent management teams who effectively filtered out negative employees in the hiring process or quickly dealt with anyone who became problematic after being hired.
Being a negative value engineer isn’t just about writing bad code or being incompetent. Those things are trivially obvious in any technical interview. The reality is that negative value usually comes from behavioral issues. Engineers who are constantly sowing discord against the company or management can bring down entire teams. Engineers who create conflict and destroy morale are toxic for productivity and will drive away your best team members. Engineers who can’t ever ship anything on time because they can’t manage their own time or they have pathological perfectionist tendencies will sink your schedules. Ironically, negative value can often come from those with great technical chops who are unfortunately mired in personal issues.
Managers can compensate to some degree with intense attention and guidance for those individuals, but at what cost? Obviously managers should make an attempt to correct behavioral problems that are dragging the team down, but at some point you need to do the inevitable and replace the problematic employee with someone who can perform without the behavioral issues.
It’s not just a question of whether or not someone can write good code. It’s a question of whether or not the team and company are best served by keeping a troubled employee as opposed to reallocating that finite headcount to a new candidate.
Exactly, to use the framing of "Speed of Trust" by Covey, trust has multiple dimensions, if you only focus on the skills and results dimension you end up with toxic employees with malicious intent or who have a profound lack of integrity and leave a trail of carnage throughout the organization. Whether you need to have a hierarchical managerial system to rectify this is another question, high functioning teams are perfectly capable of making this assessment themselves.
Another underappreciated factor are mental health issues. The chances are high that you will run into people that have undiagnosed ADHD, OCD, Aspergers, autism, bipolar, anti-social disorder in software engineering, or even that you might have a mental health problem yourself without knowing it.
I’ve gotten rid of the engineer you describe.
He was technically proficient but lacking in literally every single other ancillary skill for an engineer or a human being.
He could write complex code but it was overengineered and overcomplicated imposing a huge maintenance burden and making it brittle. His whole team was “Wow, he must be so smart!” but when asked on what basis he’d chosen the approach he’d taken instead of the naive solution he got rude and defensive. Nobody else on the team could maintain his code. (It wasn’t bad in isolation, just inappropriate in context.)
Presented with a problem to solve, he would not write something that made sense for the business, designing around requirements that did not match what a reasonable person would assume. When more explicit requirements were included, he complained he was being too restricted.
When presented with a problem to solve, he would not solve it in a way that made sense in the overall technical landscape (I need to serve some absurd number of requests, should I write the most efficient program possible but restrict it to a single instance, or write something less efficient that’s horizontally scalable?).
He was not interested in learning new things. When presented with different technologies, he instead began a solo rewrite of core company systems to ones he was more familiar with because “that’s what I’m more familiar with”. When it was explained that we’d moved away from those systems because of certain problems, he powered ahead with “Yeah, but that’s what I’m more familiar with.” When the foot was finally put down, the answer was “Fine, I’ll use the tech you use but if I have any problems I won’t fix it someone else will have to figure it out.”
He sat idle for weeks because one of our internal company tools was poorly documented that he needed it to do his job (no one thought to document it beyond the inline help because that had been sufficient thus far...). Seeing this tool used daily for two weeks, he did not try it, did not ask his teammates he saw using it, his supervisor, or anyone else for help. He checked the internal wiki and when he failed to find a clear explanation he just... did nothing. Until he got fed up with not knowing what he was doing and scheduled a meeting with the CTO, his supervisor, and ops to walk through every wiki page one-by-one and demonstrate that it was not documented on that page. That meeting was cut very short but probably still easily cost $600.
In every meeting everyone he dealt with walked away with a bad taste because he was rude and interrupted people constantly. He did not bring ideas on technical merit but instead “well I always...”. The biggest thing we emphasize with all our engineers is “data”. Decisions are based on data and documentation, not feelings and opinions. He pushed things through on sheer stubbornness and got upset when he ran up against people that refused to accept that.
His supervisor was not a strong, confident type and within about three days of being hired he’d steamrolled him and started completely overhauling how the team works causing deadlines to be missed as everyone on the team became confused about how to do their job.
And when all of these things were repeatedly discussed with him, explaining what the problem was, why it was a problem, and how we expected an employee to behave... he disagreed there was an issue and carried on as he was.
I did not do the hiring in this case, but I resolved the issue. For that team it was a brief couple week interlude where some guy showed up, wrote some “really smart” code and tried to do some other really smart stuff, then was gone before any of it really got implemented and life went on as usual.
Which is all to say I agree...
Awful engineers don’t have to be technically incompetent, there are a lot more skills involved to being an engineer than just writing code. And if you’re not actively opposed to it, a good manager can smooth over deficiencies in some areas so nobody ever notices.
And if you’ve never worked with an awful engineer, that’s likely a result of a lot of other systems doing their job. If you hired everyone that applied to our company you’d end up with mostly unqualified engineers... and a couple of drywallers. Every improvement past there came from a deliberate action by somebody.
> He was technically proficient
> He was not interested in learning new things.
So, sounds to me like he was only proficient with one specific technology.
Unfortunately it was only my second or third job, but I’d met a number of people in school for whom it seemed obvious they would not be able to cut it in the real world.
But the line you quoted reminds me of a supposedly apocryphal story involving Dustin Hoffman staying up all night to play a scene where his character is exhausted, and Laurence Olivier asked him, “my dear boy, have you simply tried acting?”
Bad coders have a large blast radius on poorly managed teams. No amount of culling people will make up for a complete lack of leadership skills in the organization. If you are leading, some people will not like where you’re headed and find someplace else to be. Others will rise to the challenge.
My dear boy, have you simply tried managing?
My take away from your comment is that bad engineers are genuinely so rare to meet that false positive from following the advice should heavily outweight any advantage of it.
I think that strongly depends on the environment. I’ve worked in a lot of big corporates, and negative value engineers are exceedingly common there. I’ve also seen them in quite a few early stage startups that don’t have particularly strong technical founders. In those situations the first technical hire will often become the technical leader, and if that person is useless then the technical direction of the company is doomed. Companies like that usually don’t last longer than a couple of years, but there are quite a lot of companies like that.
Startups that have survived long enough to get a product to market, and have a reasonably sized small team, would represent a survivorship bias against having negative value engineers. At which point they will have grow to the point of rotting under the weight of large-corporate inefficiency before any additional negative value engineers would be able to infiltrate their ranks undetected.
> the first technical hire will often become the technical leader, and if that person is useless then the technical direction of the company is doomed.
It'd be interesting if there was somewhere to read about such companies.
Maybe they don't realize themselves -- if the founders aren't technical enough to realize that the technical leader is the very wrong person
They might never realize why things didn't go their way, and blame other things instead
> false positive from following the advice
Is that accidentally not hiring someone who would have been a good fit?
I was probably 6-7 years into my career before I encountered such a person. It was my first formally titled “software” role, having spent the years prior making software and calling it “websites”, for a mostly brochureware design firm. I had terrible impostor syndrome. But I recognized that a member of my team was simply not up to the task. And was very well liked by the team, so no one had spoken up.
But I was gaining responsibility, including (informal at the time) leadership of this individual. And it was a liability to the team, and to me, and ultimately to the person in question. So I spoke up. I felt terrible about it, I feared alienating everyone, and I feared I was putting the person in financial and career risk. But I didn’t see a way to bring them up to even a standard where their presence wouldn’t be a net negative, and I knew I wasn’t up to the challenge of carrying that weight. So I did what was best for the team.
The person was ultimately let go. And they did ultimately find a role that was better suited to them. So all is well. In hindsight I don’t think I should have been so torn up about it. It actually sucks to be in over your head, knowing it or not, and it’s possible finding a more fitting role is a better place for growth into more challenging roles.
I’m not sure how to conclude this, I’m not sure if there’s even any value sharing it. But I guess for anyone reading who finds themselves in my position (newish, relatively ascendant, full of self doubt but certain that a peer is in the wrong role), I would recommend trusting your gut. And I would say that there’s a lot of room in tech for a lot of people at almost any skill level. Just not always on your team. And that’s okay. They’ll very likely be okay.
> I feared alienating everyone
It seems you didn't alienate them in the end? When looking back?
What would you consider a bad engineer? Are we talking about the utterly hopeless or those who might only have an attitude problem? If it's the former I've perhaps encountered only one in the last ten years. If it's the latter it's almost every month.
> What would you consider a bad engineer? Are we talking about the utterly hopeless or those who might only have an attitude problem?
Those categories aren't necessarily disjoint. There can be many aspects, many of which are described in the paper. But in my experience, one of the more pernicious combinations is the sincere belief that one already knows nearly everything worth knowing, coupled with a complete lack of curiosity (or perhaps it was merely utter laziness).
When that happens, a person stagnates. In the case I saw, a person with decades of experience was effectively performing only marginally better than someone who had just begun their career. The major difference being that a person who has just started is often well aware that they have a lot to learn. Or even if they're not, if they're curious then there's at least a good chance that they will figure that out in time.
I have met plenty of bad engineers so maybe it's just luck.
Engineers that can't write simple code and always over engineer. Engineers that have no concept of encapsulation and use globals all over the place. Engineers that have no concept of perf. Engineers that can't ship and noodle the same piece of code for weeks that others would have finished and moved on in a 1/10th the time. Engineers that are all talk no work.
That last type sticks out where the engineer would basically walk around and stop at people's desks and talk their ears off but never actually finish any code. People complained. The boss said "they have a family so I don't want to fire them". I don't know how to answer that.
I wonder what would happen if you also started walking around and stopped finishing code. Would the boss keep you too, or would you get fired despite having a family?
Considering the Dunning-Krueger effect, my Imposter Syndrome is sure that I must either be a bad engineer, and that it's just a matter of time before I mess up in a situation because I incorrectly evaluate my skill level at evaluating my skill level... etc. or that I'm a decent engineer.
I've been trying to avoid that meta-evaluation spiral for years by semi-regularly checking with third parties to confirm that I'm generally the person I believe I am.
So far, so good.
Edit: Almost forgot: The whole point of this introspection is to point out that the self both is and isn't a decent guidepost for evaluating others.
One framing that I found useful (by Covey Jr I think): Capabilities, results, integrity, intent. A bad engineer is so deficient in one or more of those areas that it leads to issues of trust from which a snowball starts to roll downhill. The team will have performance issues or might to start losing people and so on.
A well intended, stand up person who can't code will have a negative impact because their team mates will have to carry their water.
A person with high technical chops who delivers great technical implementations but publicly berates people and has temper issues and throws their team mates under the bus in order to get ahead will also have a negative impact on the performance of the team as a whole.
It's a testament to where you work. If you worked in sweatshops firms, who effectively hire anybody who is willing to work without any sort of coding test, there is an amount of developers there who are incapable of developing anything.
If you worked in startups in the valley, there's usually a pretty decent high technical bar to hiring.
"If you find a project where only one person know what is going on, chances are that person is not good at writing code for humans, not that is a coding god."
This is hard for many to grasp, but if you get the opportunity to lead enough teams it will become clear. And it makes sense, if you think about it. An individual who ended up owning a particular piece of a codebase will be incentivized to obfuscate and obscure their code in order to maintain full control over it. It's job security and furthermore if it's a valuable piece of the product then it can keep praise and rewards centered on you. We should also not be quick to blame the individual for perpetuating this, the right incentives need to be in place to reward both team progress and individual progress.
In my experience, the far more likely explanation for a bus-factor for an area of code is not that they want it to be that way, but because the organization has stretched them and other coders thin enough that it's hard to fix that.
An organization can get surprisingly far with a huge number of bus-factors, and doing a learning-by-fire session whenever someone burns out and quits.
If the engineer who's a bus-factor on that project is willing to help others learn and recognizes tech debt but isn't given time to fix it, that points to organizational issues to me, not to any engineer being bad nor attempting to have job security.
"An organization can get surprisingly far with a huge number of bus-factors". So much this.
Some managers see high bus factors as a sign of success: "we are a team of specialists: it's so much faster to give a problem to X than to have Y come up to speed on X's code base."
This, of course, sets X up for (invisible?) pressure not to take holidays or get sick. And because problems don't occur evenly across your code base, chances are that one of your devs gets far more bugs to fix than the others. And because the pressure at your org is to go fast, there WILL be bugs to fix. "Testing is too slow", etc.
If you don't care about the bus-factor, you can have 10 projects with 10 developers. Actually, even more than that, because one developer can work on multiple projects in parallel, or at least have one active project and one or more mostly stable projects where they are the only person doing maintenance.
But of course with 10 projects you will need at least 15 managers...
> An individual who ended up owning a particular piece of a codebase will be incentivized to obfuscate and obscure their code in order to maintain full control over it.
That's fair, but I've also seen an orthogonal effect happen maybe more often where an engineer structures code just naturally in a way that fits them well, but is poorly understood by others. Not due to the incentives of maintaining control or job security. But simply because the engineer wasn't talented at making good code for other humans, and there were very few incentives to write code good for other people, at least early on in the design.
It's also that sometimes they stay on that codebase because they weren't the best engineer, and all the better ones move on to bigger things.
Or they were the best and the ones who left were the worst ones. The argument can be made both ways.
Or they are a junior or expert beginner engineer that thinks good code means checking off as many design patterns as possible. I've seen this a lot.
Maybe I've just dealt with good cultures but I find this a bit cynical. Normally when there have been too few people who knew a section of code, it was because:
- The area of code has a high ramp up, high risk, and few new work incentivizing ramping up on it.
- The curse of knowledge makes it hard for the person familiar with the code to know what is needed for others to understand it. Incentives are needed to encourage learning by others to force the maintainer to better understand how to explain things. This isn't a judgement on the person in their general inability to write code for humans nor is it about obfuscation.
You need incentives for the maintainer helping others to learn. AND you also need incentives for the others to start learning.
I am living right now this situation where I am the maintainer of a large chunk of code, I would like to have at least a second pair of eyes looking on what I do, but the others are all busy with their own tasks and no one learn from the others.
> We should also not be quick to blame the individual for perpetuating this
This part at least, I agree with. Whenever I see code like this it is a symptom of a larger product development issue.
- unreasonable deadlines
- overpromising to external clients
- no coding standards (enforced by linter and code review)
- no automated testing
- no code review process
- using new languages/technologies without first gaining some experience about best practices
Early on, a startup definitely needs engineers that are going to work autonomously, cut corners as needed, not be a perfectionist, etc. The technical cofounder/CTO/team leader should still be setting up a culture of high quality code. Coding styles and some automated testing make it easier to move quickly and ramp up new team members or for old team members to circle back to old code.
I've never met an engineer who was deliberately bad to ensure their job security. Most of the time the developer is just plain bad at their job, and any job security that results from writing reams of spaghetti code is just a happy accident.
> It's job security and furthermore if it's a valuable piece of the product then it can keep praise and rewards centered on you.
That's part of it, but training people is also very difficult. If you know a system well it takes a day to add some feature, but it takes a few days of frustration to train someone else.
If those are actual numbers (a day versus a few days) then that should be an incredibly easy decision. A few extra days is nothing compared to doubling your capacity to deal with problems in that system!
That is a few extra days for one task. 6 months later you'll still be training the person, though the overhead will still be lower it still will be slower than doing it yourself. Then the person might leave and you start all over again.
This seems like the common mistake of trying to optimise for individual efficiency at the expense of the rest of the system.
Yes, overhead will be higher, but since capacity also will be higher, cycle time will go down much more (non-linear effect) and you'll extract important value and feedback out of the tasks sooner, easily paying for further capacity improvements.
IME, this isn't so black and white.
In some situations, that engineer has a very strong mental model of the business domain they're modelling in code. It's a model forged by years of experience in the domain.
The model has complexities, but they are generally a minimal set necessary necessary to span the domain.
At first sniff, new engineers might find the code overengineered. It's a Chesterston's Fence dilemma. Except, in this circumstance, you have the builder there to explain the fence, and IMO it's wrong to assume malfeasance (obfuscating for control), when there are other contributing factors.
IME, the way to resolve this ambiguity is paired programming and communication. After the 2nd or 3rd session, the mental model should prove to be transferable or not.
Never attribute to malice that which can be adequately explained by incompetence.
Bus-factors are usually an organizational smell. What I mean by that, even if the individual is doing it on purpose (in order to control people in their gate keeper role or to have heroic tales to tell) the failure is the organizational structure and culture who allows empire building to happen in the first place.
I don’t work in this kind of environment. What is an example of a common team based incentive?
Team-based incentives are not particularly common yet, though they are growing in popularity. It's pivotal that a team has some choice in who they are teaming up with in order to align motivations and incentives to achieve. A simplistic incentive is an autonomy based award. If a team completes a project ahead of schedule then they can spend the remainder of the allotted time to work on whatever they please. Sort of make your own 20% time. You can see how hard this is to get right though because if you let the product managers set schedules then they'll make the deadlines too short. If only the engineering team sets the schedule and is incentivized to come under schedule then they'll consistently over-estimate. Requires trust and balance between the team and the stakeholders.
All that said, when you talk to really high-performing teams many of them will say that they value just continuing to get to work with that same set of individuals. It's a reward onto itself to get to work with people whom you really enjoy working with.
First, and I really want to point this out. The author's sentance you are quoting doesn't have fully correct english and due to that is missing meaning. You're reading into it what you want.
Second, applying the assumption they are obfusicating code to maintain control or ensure job security paints a lot of people with a very, very wide brush. If you asked why or spent time understanding why, then you'd get a lot closer to the truth of whatever the situation happens to be.
Third, Arthur Schopenhauer is attributed with the statement "Talent hits a target no one else can hit; Genius hits a target no one else can see." High performers tend to hit targets nobody else can see and that tends to be a very disorienting experience for all involved because systems end up behaiving in unexpected ways. Some people call it code obfusication, some people call it forcing people who are looking to break things to understand what they are doing before they do it; both are forms of organizational dysfunction which is pandemic in the industry.
Subtly demonizing these people as "inhuman", or as you are doing right now, painting them with a wide brush, illustrates one of the serious problems that high IQ and high performance staff face. Namely, they get scapegoated and harassed by groups of people.
At one org I found a bug causing 8 figures a year in inventory shrink caused by 2 lines of SQL Code that had been there for 10+ years; a contractor had come in, implimented a fix, and nobody had ever questioned it. Millions of dollars of inventory were being stolen by staff. Now imagine how disorienting that is to the entire end to end org. Believe you me, the c-suite wanted me gone after that and not because I wasn't doing a great job, but because I was fixing organizational issues that made them look bad and they wanted that stopped. They hired a high performer, encouraged it, and then when it got too bad for them, they got rid of them.
It is fully possible that some of these situations exist where there's a toxic, narcissistic fascade being sold to maximize profit. It happens. But I doubt that is the norm.
Is this an issue of organizational incentives? It's an issue with organizational structure, not recognizing people for who they are, and not aligining staff's interests because in this world we have this f'd up idea that we're just here to make money for shareholders or be the ATM machine for ownership. If running a company as pageantry makes them money, then they do not care.
This is why many high performers often create a niche money-making product that doesn't take up a lot of their time to get cash out of, then move on to working on other things that make them happy.
Why waste the effort if people don't care?
I've worked with 10x-ers. They do exist.
In my experience they're extraordinary people in many, many aspects. More than anyone has a right to.
Besides the god-like ability to solve problems, they were amazing mentors, and clear communicators focused on what's right for the team at the time.
They were universally liked and working with them makes you a better professional.
Software is a a team sport, successes is hard to come by on your own.
Some people make it a false dilemma: either there are "mythical" 10x developers, or it is about teamwork. Then they prove the teamwork is important... and therefore 10x developers do not really exist!
But in fact, there are people who are 10x developers and are great team players. And there are also people with great technical skills, who are completely toxic. And there are also people with mediocre technical skills who believe themselves to be gods, and for some reason management seems to believe them. All of these are real, and I have met them.
For good cooperation, both the 10x developer and the rest of the team need to be good team players. Because some people are unable to teach, but also some people are unable to learn. Some people are condescending to those with less experience, but also some people are hostile to those with more experience. If the team works well together, the 10x developer can set the project architecture right, teach other team members to follow some good principles, and then all together do seemingly miracles.
I also worked with 0.5x-ers. Whose presence alone would drop value in half.
> Even more important than finding great engineers is to avoid bad ones.
I don't know how many Jeff Deans and John Carmacks the OP would turn away in order to avoid a bad engineer on the team, but for me the answer is zero.
If you do hire them but your process can't tell the difference between them and the bad engineer they work with they will get frustrated and quit soon. The most important part to keep good engineers is to ensure they don't have to work alongside bad engineers.
I can't imagine a situation where I couldn't tell the difference between either of them and a bad engineer. I'd either be pair programming with them and learning a lot or be pairing with a "bad engineer" and suffering.
Sometimes people making the decision about hiring are not programmers themselves, or happen to be the bad engineers. In both cases, the difference between a good and bad engineer can be invisible for them.
I’ve been fortunate in my career thus far, since I was about 14 or so, to have always been in the company of at least one “10x”’er on each of my teams, as the cliche goes. They’re dispersed through various companies nowadays - Stripe, Twitch, Google, FB, Discord, etc etc. But it was interesting and beneficial for me to work alongside them if only because I had decent role models to follow.
This article first puts up a straw man and then switches gears halfway into a different subject. See if you can spot it.
There is no exaggeration. Some people are just far more in tune with the mental models required to do good software work at both a micro and macro level, that any time I see someone trying to play it down I have to ask if these individuals have worked with one of these precocious talented folks.
I also sometimes struggle to understand why anyone would write an article like this. You obviously want to hire the best you can for the best price you can. Anything else is a silly coping mechanism that you can’t face with honesty.
I want to read an article that’s straightforward about how much good work 10x’ers can do and how influential they can be for rest of the team. But this isn’t an article anyone would bother writing because they’re too busy making money to have dick measuring competitions on an online news board.
I feel the same way, anyone who does not believe in the 10x engineer has just never met one. Sometimes the software they produce is absolutely stunning.
> I feel the same way, anyone who does not believe in the 10x engineer has just never met one.
Food for thought: The interpretation of a 10x engineer is not consistent. Putting my manager hat on, I ask: Can I replace 10 of my average engineers with this one person? The answer is never "yes".
That's because a team does more than just technical stuff. There's documentation, dealing with customers, bureaucratic stuff, etc. If you don't do these well, much of your brilliant engineering gains will go to waste. A brilliant engineer may be harder to replace than the average, but he/she is not a 10x engineer. Perhaps a 2x.
Producing an equivalent result in less time than a less capable engineer is not the main benefit of having some really good engineers, at least not at all companies. It's being able to perform work (and well) that requires more knowledge/ability. I know quite a few people who can't be replaced with 2 average engineers, but that's not because they work at a >2x faster pace, it's because I wouldn't trust an average engineer to do their job.
> Can I replace 10 of my average engineers with this one person?
Yes you can in plenty of situations. 10 mediocre engineers creates a ball of mud and gets bogged down in technical debt. Beating that as a good engineer isn't hard at all. What you can't do however is tell a good engineer to maintain the ball of mud created by your 10 mediocre engineers.
> Putting my manager hat on, I ask: Can I replace 10 of my average engineers with this one person? The answer is never "yes".
Well, yeah, people aren't interchangeable cogs. A person that is capable of delivering 10× value per unit of working time when properly employed probably isn't a drop in replacement for 10 1× developers. And managers thinking of people as interchangeable cogs where productivity multiples work by simple substitutions that way are great at getting ~sqrt(N)× (or less) output and quick burnout from N× (N > 1) developers.
> That's because a team does more than just technical stuff. There's documentation, dealing with customers, bureaucratic stuff, etc.
Yeah, and all of those things are things a developer can be better at than average, not just technical design and coding. Sure, there's some high productivity developed that are average or worse at some but much better at one area, there's also high productivity developers that are better than average across the board.
> A person that is capable of delivering 10× value per unit of working time when properly employed probably isn't a drop in replacement for 10 1× developers.
I find that claiming they produce 10x value per unit of working time, while also pointing out that they aren't interchangeable cogs, as a bit odd. If they are not interchangeable (which I agree they are not), then you shouldn't compare their productivity so glibly. At the very least, you need to state up front your method of valuation, which was why I said in my comment that "The interpretation of a 10x engineer is not consistent."
I've never found a manager, or even a company, that could put even a remotely accurate number to the value a tech employee is providing. In sales, perhaps. But with this kind of work, the error bar is large enough that any such estimate is useless.
And then confound that with the fact that the value of your work is dependent on other people - both in and out of your team. Being able to extract how much you produced from this mishmash is usually not possible.
So at best, your scenario of assuming someone is producing 10x value per unit of time is little more than an interesting thought experiment.
Lest "different people have different roles" is a confusing factor, let's eliminate the uncertainty. Say I have a team with many responsibilities (including non-technical ones), and it is every developer's responsibility to do these. You will likely never find a 10x employee there. You'll find someone who may be 10x better on the SW coding side, but he won't achieve those multipliers in his other responsibilities. His real value will be lower. In reality, managers will often shuffle roles so he is not hampered, and assign him to do only the thing he is great at, but that won't mean that he is producing 50% of the value in an 11 person team (which is what 10x means), when you look at the total output.
There's a reason why in game theory, if you need me to achieve something, I can demand half the value even if I only contribute 10% - because 50% is the stable solution (assuming you can't find an alternative to me, of course).[1] People who are replaceable get lower pay, but there's a reason almost no "10x" engineer gets 10x the pay. It's because they literally are not worth 10x to the company.
> Yeah, and all of those things are things a developer can be better at than average, not just technical design and coding
For sure - just not 10x. The reason I mentioned these other "bottlenecks" is that they don't scale as well as other technical/engineering work. And this is why most people viewed as 10x engineers aren't. To be clear, I don't doubt that a person is 10x better than the average in doing X, but I've found that X is always a very narrow scope. I want to see how much more he is contributing to the whole compared to others, and have yet to see a multiplier as high as 10x. If you cannot leverage your 10x productivity in X into 10x better documentation, 10x better promotion, 10x better testing, 10x better customer skills, then your productivity in X has those bottlenecks and your multiplier is less than 10x (in practice, rarely more than 2x for the "whole").
Of course, I work in a big company. I can believe 10x engineers exist, for short intervals, in a small company or a startup.
[1] Growing up, I really hated game theory, but too many decades on this Earth has shown me that the results largely reflect stable outcomes in society. I continue to hate it, but I don't ignore it any more.
> Lest "different people have different roles" is a confusing factor, let's eliminate the uncertainty. Say I have a team with many responsibilities (including non-technical ones), and it is every developer's responsibility to do these. You will likely never find a 10x employee there.
Yes, if you're team is so poorly managed that has neither top-down not bottom-up organization for efficient task distrobution but instead features mechanistic, blind task distribution, you'll both decrease output even of a team of whatever overall competence and minimize the performance differences on the team that aren't do to absolute superiority on every type of task. Which is why, whether it's agile self-organizing teams or other bottom-up approaches on one side or any kind of top-down management theory on the other, every approach to managing work is about.
> To be clear, I don't doubt that a person is 10x better than the average in doing X, but I've found that X is always a very narrow scope
I find 10× in a narrow scope to be very rare, though it probably happens somewhere. Something more like 3× in a narrow scope of focus personal tasks (e.g., the more complex design and coding tasks) and providing a 2× multiplier on the rest of the team by helping choose efficient direction of focus, identifying problems proactively early, and otherwise keeping the team from wasted/misdirected work that otherwise would get done is both more common than 10× in a narrow field and a bigger productivity win.
Honestly I don't know if there's any case where a team of 10 on a project would outperform a (good) engineer or two.
Half of the 10 engineers will do nothing, the other half will have different views of what to develop and will face off one another heading into opposite directions.
Usual development work in a company does not require 10+ workers and couldn't be split over 10 workers even if you had that many.
> Can I replace 10 of my average engineers with this one person? The answer is never "yes".
That’s because the “10x” is an order of magnitude difference between the best and the worst, not the average.
https://www.construx.com/blog/productivity-variations-among-...
Fair enough. In that case, I would expect a multiplier much larger than 10x. :-)
Definitely encountered folks who fail on FizzBuzz and similar problems.
Note that the worst doesn't even finish so the difference is infinite. 10x is the difference between the fastest and slowest of those who could complete the project.
Or, alternatively, the 0.1x engineer and the -10x engineer. (Or worse, the -10x PM.)
As the joke goes, "There does exist a 10x engineer, but unfortunately it's in binary"
Yeah. Engineers fall on a distribution. It's just that simple.
OK, now if it were only simple to figure out where on that distribution a particular engineer falls during the limited time of the hiring process.
Can john carmack build 10 crud apps in a week?
Pretty sure he could if he got to practice writing crud apps for a month beforehand and the apps were no more complicated than what a mediocre engineer can write in a week.
Also, one engineer making 10 crud apps would probably share a lot of code between the apps. Which would allow him to make the new ones even faster. And the result would be easier to maintain.
If you instead hire 10 engineers to write 1 app each, you often end up with 10 apps using 8 different frameworks in 3 different languages. And then you will need 10 engineers to maintain them.