Orgs: okay you are indistinguishable cogs and we will treat you as cattle
Devs: no wait not like that
Truth is everyone knows that who or which teams takes a task matters immensely. We know that if Bob leads it’s gonna suck and if Alice does it’s gonna rock and finish on time.
Managers know this also.
But we’ve constructed a corporate culture where this is not allowed to be said. So we bend over backwards to pretend everyone is equal and capable of the same things in all areas. Then we secretly make sure somehow by magic the truly critical projects are routed to the people and teams with more reliable outcomes.
The corporate culture serves a very specific purpose of lowering the self-esteem of the 10x folks, keeping them at their place doing 10x work at 1x salary until they burn out. This is scalable, predictable, and serves management's interests well.
It's just if you happen to be a 10x guy, for the sake of your own sanity, learn how to run a business and get out of the corporate swamp. Nothing else will bring you happiness, believe me.
People often forget that the 10x guy is 10x only in the domain he’s been working on, and many chores has been taken away from him by his manager and given to someone else. It is fairly easy to make a 10x someone closer to a 1x just by changing his tasks and giving more chores like CR, bug fixes, more mundane features or GUI etc. Sure it will often be better quality but in areas where it matters less.
Jeff Dean was 10x when he wrote EPI INFO, he was 10x when he worked on profilers at DEC WRL, he was 10x when he and Sanjay Ghemawat wrote MapReduce, and he was 10x when they rewrote Google's search indexer. Maybe 1000x or 10000x, really. It's true that part of that was that he worked on things that mattered instead of things that didn't, and he could have found himself in a situation where he didn't have that opportunity. But it's clearly not just productivity in a single domain, and it's not because someone else was fixing all his bugs.
There are statistical outliers in every single thing that has a big enough amount of samples and that it is possible for there to be statistical outliers.
Maybe you attract those like flies are attracted to honey, but pointing out that an Einstein existed isn't really helpful for approximately all teams of physicists out there, minus one or two teams
I'm not even saying there isn't a huge quality variance in the regular pool of programmers, mind you. Just that pointing out the existence of bad motherfuckers in a population of a few million people shouldn't come as a surprise.
The average person is about 2 meters tall, weighs about 100 kg, can run about 10 kilometers per hour, lives about 70 years, and can shovel about 60 tons of coal in a day (without power tools). If you took a sample of a few million people, it should very definitely come as a surprise to find that it included "10x" people: people who were 20 meters tall, people who weighed 1000 kg, people who could run 100 kilometers per hour, people who lived 700 years, or people who could shovel 600 tons of coal a day.
It should come as even more of a surprise to find "Jeff Dean" people who were 2 kilometers tall, or who weighed 100 tonnes, or who could run 10,000 km per hour, or who lived 70,000 years, or who could shovel 60,000 tonnes of coal in a day.
Your comments about how physicists do physics are equally wrongheaded. Physics isn't any more a matter of shoveling coal than programming is, probably less so.
What made you think I think physics or programming is analogue to easily quantifiable manual labour?
>It should come as even more of a surprise to find "Jeff Dean"
To find them, yes. To point out that they exist and the likely that you'll work with them is statistically insignificant? No.
The thing with intellectual labour is that some insights have immeasurable value. Some statistical outliers have such humongous intellectual capabilities that it's ridiculous how often they'll have great insights.
Of course, that won't stop people from trying to attach some numbers to it, even if their numbers are epistemologically shit.
I'd wager that has something to do with jumping the shark.
People feel the need to chat about 10x developers when they don't even agree what a 1x developer is, and when they do present a definition, that definition is a function of (company, team, project, existing code base) which means there are more possible instances of 1x developers than the amount of developers who have ever lived.
Everyone is better off if they just ditch the "10x" which has connotations that programming nerds will latch on to and just use "highly performant dudes".
No, in the studies in Sackman, Erikson, and Grant's 01968 paper (10.1145/362851.362858), which is the origin of the 10x-developer idea, there were only 12 and 9 programmers, respectively. In both studies the standard deviations were comparable to the means. That means 10x developers were a substantial part of the population, and the rest of the population also has very high variance; it isn't just a question of a few outliers.
Jeff Dean is probably legitimately an outlier, though.
This is just a redressing of the same “everyone is just as good” bullshit. Some people get a fuckload more work done because they go down the right design paths to start with, know how to work effectively, know what pieces to skip, etc.
The same is true in nearly every field. Programming is not special.
I deliberately used “closer to 1x”, but let me respond with an anecdote.
I know several people, each working in a different org, who explicitly manage their managers by demanding to work on issues that have good visibility, are not too short >2 weeks but not too long <2-3 months so they are ready before the next review period. This way they are seen from the outside as very good performers while someone else is doing the less appreciated (but still essential) work.
Sure they are, I'm arguing that their force multiplier has to be taken with the context they are in, and that the change of the context can reduce the multiplier.
I think people also don't realize that high-performers weren't always high-performers. They had to hone their skills, usually by doing years of the right kind of challenging work with modest rewards, and sometimes they can be formed by exceptional mentoring.
But however they got there it took time, it's something that can be cultivated as long as folks aren't treated as fungible.
I disagree, the few really high-performers that I have worked with were high-performers already from the first week with a new technology, from the first month in their first job, and already as a student during practical work they were more productive than most people who had many years of challenging work behind them.
Experience is important and adds up, honing the skills makes everyone better, but it's orthogonal to this issue; there are people that will very quickly outperform someone who has honed their skills for years, and once they have honed their skills in that domain they might perhaps start outperforming them by the mythical 10x ratio.
I guess it depends on how one defines 10x or "high performer". Prodigies and maestro's will always be few and far in-between, is that what is meant by 10x? I don't know. But given the relative abundance of 10x'ers anecdotes in discussions in places like HN, I always just take that term to mean "really good" or perhaps just fuzzy romanticizing-- and not literally able to do the work of 10x "mortals".
Well, he became 10x in the domain, and the other did not become 10x, it's not like he was born with this knowledge, he just took it more seriously and went deeper
No, some people are a lot more productive across broad range of tasks. Often they are assigned tougher/critical stuff though because it doesn't make sense them do trivial tweaks.
Ensuring people work on what they are comparatively best at is a feature. 1x engineers would also get a lot less done if they had to clean the toilets and sweep the floor and many of the other low end tasks others do, instead they assign people who cost less to those tasks.
That’s argumentum ad absurdum though. There may well be people that are useless in a given profession, my point was not about that. My point was that 10x occurrence should be analysed within specific project, work division within the team, etc. For most 10x programmers in a project it does not guarantee repetition of 10x on a different type of project or problems. Matching problem with a team member and ensuring he has a chance to become 10x at it is something that good managers do.
Isn't it insane that there are many 10x engineers who have created enormous amount value (creating patents, leading and executing projects, innovating etc.); Yet, the world will only know about the company or the CEO and never the engineers behind it.
How do you expect the world to know about the others? The CEO is public facing by definition of their duties and the charter. Any other public presense from the organization technically falls under marketing of some sort, even teaching useful generic skills for free (say a publisher promoting literacy in third world nations) is in service of this.
It requires looking into arcane details to know about the engineers behind it. I mean software, especially media productions often include outright credits but few would remember any but leads usually. Precise attribution would get downright absurd in a pure data sense to give coverage that few care about. Say for just a simple who tightened the screw on this part of the cloth mill during its production run, who made the screw, who farmed the cotton, made the irrigation means....
Replicability and productivity atr what leads to technical obscurity ironically - because the automation and scale means fewer people are even in the position to know what to even ask about the details relative to the numbers served. Thus the knowledge remains arcane. Not many people would even know say, that DRAM tries to minimize capacitance and inductance but it needs some of both to function. Let alone who was involved with what subsection of the chip design and design testing process.
The trick is to be a 10x dev and work 0.2x of the time, remotely of course. Everyone thinks you're decent and you get a full salary working 3hrs per day.
Not only are there 10x engineers, I personally know an objectively measured 500x engineer. He is humble because he knows someone who produces 10x what he does (albeit spending twice as much time at it).
The measurement happened as a result of a joint venture between Siemens AG and Ericsson called Ellemtel. Each company sent 250 [edit: not 500] engineers. It was a six month project, the classic death march: if it did not deliver on time, the parent companies would not be paid.
At the end of the project, half the code delivered was his. Had he not been on the project, it would not have been completed on time, so no product would have been delivered. [Edit: Thus, it is not really the line count that makes him a 500x engineer.]
> I personally know an objectively measured 500x engineer. He is humble because he knows someone who produces 10x what he does (albeit spending twice as much time at it).
So your 500X engineer knows a 5000X engineer and he wrote as much code as 999 other engineers combined? (That would make him a 999X engineer, FWIW)
A 500X engineer (per your measurements) would have to write 500 lines of code every day without fail, while all 500 other engineers in the entire company could only average 1 line of code per day. And the 5000X engineer they know would have to write 5000 lines of code per day while everyone else was only limited to 1 line of code per day.
Not just one day, but every single day for six straight months. And all of their managers would have to somehow not notice this disastrous situation for the duration of the project. Come on.
What were you trying to say? You realize a Boeing 747 weighs over 400,000 lbs. And a tiny Cessna 172 weighs ~1500 lbs.
If the planes have the same wingspan, it's likely they're in the same class, and weight is a perfectly reasonable measurement of completion percentage.
A 450-gram partly completed airplane probably has a wingspan of about 1 to 3 meters. If you have a partly completed plane whose wingspan is of about 1 to 3 meters, and it weighs 450 kg, it will never fly. You need to redesign it. Otherwise you have a rocket, not a plane (and there's no guarantee that it's a working rocket).
Maybe, in exceptional cases like the Gossamer Condor, a 450-gram partly completed plane might have a larger wingspan, like 30 meters. With enough thrust and wingspan, you can definitely get a plane weighing 450 kg to fly (or even one weighing much more, like your Boeing 747 example). But if your Gossamer Condor competitor is partly completed and weighs 450 kg, again, you are going to have to redesign it, because a bicyclist will not provide enough thrust to keep it airborne.
If your Boeing 747 assembly is running behind schedule, you probably cannot catch up by adding more ballast to the wings, or prioritizing ballast over riveting, even though lead or DU weights are quick to install, and rivets do not weigh very much. X-ray inspection doesn't add any weight to the airplane at all, but it's the only way to find certain cracks. If your Boeing 747 weighs 500 tonnes, that does not mean that it's a super-complete plane. It won't be able to take off.
So, no, weight is not a perfectly reasonable measurement of aircraft completion percentage.
sure, because they are measuring progress towards completion, rather then the ability to fly
i.e. if a finished plane weights 10,000 lbs all put together, then a in-construction plane currently at 1000 lbs is clearly further along towards completion then one at 1 lbs
Note this applies to the manufacturing,not the design.
It is actually a wonderful analogy with software:
* to a first order, cost of the materials in an airplane are proportional to the weight
* at design time, the weight of the aircraft is minimized. thus, political and management forces cannot change it.
just like software, each subsection that is bolted on has different weights; but if you average it out it is a good measure of progress. and cost.
It's a nice aphorism, but it's a very bad analogy. Before the build of an aircraft is started, the target weight of the assembled product is (roughly) known. Therefore, in the process of building an aircraft, the assembled weight at least goes up from 0 to $target -- in an erratic fashion, but it's still a continuous measurement.
I have never seen a program design specification that even attempted to quantify the lines of code of the end product, let alone be accurate.
The initial comment was related to attribution for "who built" some piece of software based on lines of code. The analogous argument would then be assigning attribution for the built aircraft to whoever produced the heaviest components. Given that that would be illogical, I think the analogy is apt.
The person who told me about this was the person who counted up the code at the end of the project. And, yes, it was 250 from each, not 500 from each parent company. (Memory is funny that way.)
I do not doubt that the numbers were rounded for simplicity. It is meaningless to talk about a 499x engineer.
As was explained to me, this engineer assigned two-week work units. If the work was not ready at the end of two weeks, he wrote it himself over the weekend. So, a fair bit of code was written that did not make it into the final product.
That's a ridiculously wasteful way of managing work. I too can be a 10000000x engineer if I never let others actually merge their code and just write it myself instead.
If you hired engineers like they hired them before coding interviews combined with a decade of the dead sea effect I can easily see a team of 500 barely getting anything done at all. Big organizations are often grossly mismanaged like this which is why smaller organizations can beat them.
mismanaged, yes. But also risk-adverse and encumbered with process. At a big corp you may need 5 or more sign offs on a single merge. I probably spend a good 40% of my time herding cats and babysitting the merge pipeline. There is a lot of overhead you simply won't find in a startup.
It was a way that delivered product on deadline, for exactly that project. Every project has specific needs. If you code to some other project's needs, you do the wrong thing.
For any positive real number X and employed engineer A with positive productivity, I can find an employed engineer B where productivity of A is more than X times the productivity of B.
Proof: Pick B to be an engineer with productivity 0. 0 * X = 0 for all X. Productivity of A is defined to be positive, so is greater than 0. Hence productivity of A is greater than X times the productivity of B.
And, not all projects are death marches. It is generally hard to measure value, which is one of Dan Luu's points. Counting lines of code rarely produces a very good answer, but sometimes that is the best you have. Company revenue can be meaningful. When a contribution that makes the difference between $X million revenue and $0, against 250 years worth of engineers' salaries, it is hard to quibble. 500x is as good a number as you can get.
The multipliers are all relative and seldom in simple metrics such as lines of code.
If you wanted to inflate the numbers in a technically truthful way stick in a complete novice capable of preparing (so they are not negative) but not prepared for a complex field so their multiplier will be low. Use them as your 1X and even burnt out and demotivated employees who don't stand out could wind up performing 50x relative to them.
You don't measure code by the number of lines written, you measure it by amount of productive value. Early engineers at Google were easily 500x ( keep adding more zeros if you want ) more valuable to google than a random swe today
LoC is a terrible metric - did they count the lines other engineers removed?
I was half of a very productive duo on a greenfield project subsystem - a project I joined midway: my partner wrote a lot of code, I estimate ~70% of final lines in the code base were his. What the LoC count won't tell you is all the refactoring, deletion, tests and error handling code I had to add, because his code only worked for the happy path. Can you say he was being 2x more productive than I was? I say no, because he was breaking the nightly build at least once a week before I joined, blocking the rest of the team, this ended when I added pre-commit tests.
When the numbers are large enough, the details don't matter much. Maybe he is really only a 250x engineer? A 100x engineer? It doesn't change the fact that without him no product would have been delivered.
> It doesn't change the fact that without him no product would have been delivered.
I agree. I'm only arguing that there are times when engineers who enable "10x/100x" engineering don't get the visibility they deserve, sometimes until after they quit.
This hits close to home for me as I witnessed my partner being showered with praise for being "super productive" based on LoC alone, code which wasn't close to being production-ready. If you don't care about code quality, and want to be seen by management/people outside of your team as a 10x engineer with minimal effort: you can follow the same playbook.
Agreed. It is rare that you can get objectively meaningful numbers. So, while it is convenient that half the code delivered was his, that is not the meaningful measure.
When I was in school, the standard for engineer productivity was 10 lines of tested code per day, averaged. Maybe we do better today, with fewer footguns and faster compilers. But we expect more meaningful results from a line of code, too.
This really isn't my experience with super productive engineers. Usually they're solving high level technical problems for the company that most employees wouldn't touch with a ten foot pole. It isn't the raw LOC they produce but their ability to translate complex technical problems into elegant solutions for everyone else to take advantage of.
I'm not saying it doesn't exist. I did say 'maybe' after all.
I am also implying the likelihood of it being that, rather than from a particular perspective an organizational detriment looks like a personal positive (somewhat akin to the 'heroic' team constantly responding to pages in production for their services; not like that lazy team that only works 8 hours a day and never gets paged), seems low. As mentioned, when one person seems to be doing all the work, yeah, it might be they're just amazing, or it might be that the project is badly managed, and so the work can't actually be distributed well. Both can also be true.
I too have seen -10x engineers. Interestingly, others in the company also saw them as +10x. Someone who was the silo for a notoriously difficult part of the system was viewed by management as amazing (after all, he just went and got things done! They could focus their attention elsewhere!). When I then had to dig in, with actual production requirements, I found nothing really worked, nothing was designed well, nothing was documented, and the person was impossible to work with.
Assuming you can objectively measure someone like this, either by LoC or delivery times, this is the wrong way to approach any project.
Having a 10x engineer(or even worse, a 500x engineer in this alleged case) is a huge risk for the company, should the engineer want to leave or if they are incapacitated in a tragic event, the company is severely handicapped, ideally a so-called 500x engineer should spend less time writing the actual code and instead mentoring/managing others to scale up their knowledge, should the company do this right, they might not deliver on time, but they'll have a much wider array of experts when something breaks or for the next projects, reduces overall company risk and it's more profitable in the long run.
Yet, they in fact delivered and got paid, and (pay attention!) would not have delivered and not got paid, otherwise. Risk is speculation about the future. Here we have full benefit of hindsight, and the choice taken was manifestly correct, despite all counterfactual speculation.
It’s incredibly reductionist to think that productivity is inherent to an individual when the world is never that simple and there are always a lot of factors involved in any outcome. Even the people that you think are “10xers” will stumble under the right circumstances, and the converse is also true about the people you think are incompetent.
It’s not so much that we built a culture that disallows these things to be said—I’m sure you have the freedom to say that to people if you’re prepared for the consequences. It’s just that it’s such a hasty, unnuanced thing to say, and business decisions should not be made on the basis of rash remarks that aren’t very well thought-out.
I remember finding a site (a design patterns repository page of all things) that explained the nuance of different people having different expected outcomes on different domains well.
But despite searching for it for years I haven't been able to find it again - web searches tend to be bad at finding things that you found before, again.
Anyway, this was described as the "movie producer pattern" (maybe it was director)
I remember it going something like this:
As opposed to the factory worker pattern which describes people who perform simple tasks that are straightforward and are easy to learn and perform and are hence interchangeable, it is more accurate to use the movie producer pattern.
A producer will have shown his or her abilities in a specific set of movies, each with a certain style and genre, which will lend credence to their ability to perform similar work in a similar genres. It's clear however that the specific director will make a large impact to the final movie and will have a personal touch.
For engineers, Susan, who has spent the last decade honing her skills on language VM implementations is expected to be an all around star resource, but would probably be a more trustworthy choice for more VM work as opposed to implementing a graphics engine or database.
(In analogy to a director with a string of science fiction movies who might not be the best choice for a romantic comedy)
> It’s not so much that we built a culture that disallows these things to be said—I’m sure you have the freedom to say that to people if you’re prepared for the consequences.
When people say that "you aren't allowed to say" something, they don't mean the government uses magical mind control rays to prevent your mouth from physically producing the words. "Consequences" are the mechanism by which speech is prohibited in societies without access to magical mind control rays.
(Not to pick on you specifically; I've heard this line a lot lately.)
I mean, I get your point about the government but now you’re just complaining about how being insensitive to other people has the consequence of them fighting back.
Now you’re moving to assume that everything that has consequences is due to somebody being insensitive. It could also be, for example, that the person initiating consequences is entirely too sensitive.
So you’re gonna go around the office to point fingers and tell on people that they’re not 10xers, and then call them too sensitive if they react? You’re talking in abstracts but if you put what you said in context (ie this discussion) it doesn’t make sense.
This discussion is not about me, nor did anyone advocate that behavior. You are making up scenarios in your mind about what other people in this thread are thinking and saying, but these things are all imaginary on your part.
> Even the people that you think are “10xers” will stumble under the right circumstances, and the converse is also true about the people you think are incompetent.
Right, the 10x engineer isn't benching 10x more than you or running 10x faster than you, nobody thinks that 10x engineer means 10x at every possible task.
Nah, it's beyond that. I know a dev that is the most brilliant ux dev I've ever met. He can create beautiful, dynamic, understandable UIs literally 20x than I can.
However, he is just medeicore at must other tasks- constructing a common data model, scaling the backend or analyzing the data be is slower than I am, if he engages at all.
More recently I told my manager that I was intimated by how effective one of my coworkers was at his job (data science and BI.) He laughed and said my coworker basically thought the same of me (doing more standard software engineering.
Highly effective engineers are often only effective at limited aspects of the business of software engineering and it takes a good team structure of diverse talents to make everyone effective, even in the domain of software.
That was my point, arguments such as yours are just arguing with strawmen. 10x is compared to another professional in the same domain. Saying that the engineer isn't as effective at another domain as a professional of that other domain is arguing with a strawman.
It's not really a strawman considering it's EXACTLY what most companies are trying to do: make programmers fungible across domains. Critically; they're doing this because they typically have no visibility into these skillsets from the managerial level, and they typically only have one or two programmers "in a given domain" on a team - even in a very, very large company. The company would like to pretend these people are fungible, and can be interchangeably swapped out, but the reality is they have no immediately replacements on the team.
There's no sense in doing an apples-to-apples comparison when you've only got one apple, an orange, and a pear.
But then you have to ask what metrics are being used to define a 10x engineer. You’ll see that everyone has a different version of that and therefore whether a 10x engineer exists solely depends on the ontological argument for a 10x engineer. By the end of the day 10x is subjective because teams have different needs.
If you can replace an entire team of 10 engineers paid to work on something with a single engineer then that engineer is a 10x engineer, as long as the "10x engineer" didn't originally write the things they work with. That is my definition.
> By the end of the day 10x is subjective because teams have different needs.
Replacing 10 salaries with 1 salary isn't subjective at all.
Of course it is subjective. This is literally what you said:
> That is my definition.
You obviously care about optimizing for salary expenses. Most companies have room to hire more people who can do a few things well, so their definition of 10x would be different because they’ll have different expectations of their employees.
And really, if your definition of a 10xer is some poor fool who’s willing to take the job of 10 people for a single person’s salary, good luck finding someone who wants to spend their lives living that way.
> And really, if your definition of a 10xer is some poor fool who’s willing to take the job of 10 people for a single person’s salary, good luck finding someone who wants to spend their lives living that way.
Right, they are paid more. The going rate for good people is around 1.5x up to 10x for exceptional cases.
Edit: And I am not talking about minimizing cost of salaries, I am talking about how much a good software engineer should demand. If he can replace 10 salaries with one then he has a lot of leverage he should use to get a higher salary, if the company isn't paying him then he should leave for a company that appreciates his skills. Plenty of companies pays premium money for premium talent.
I mean, if all you’re saying is that “better programmers deserve better pay”, then you’re not exactly saying anything groundbreaking and the concept of “10xer” is not going to be necessary to make that point. It should also be noted that the salary that you get isn’t just a product of your talent but also of how well you sell yourself. Amongst many other factors, of course.
Salary isn't just a factor of skill, but willingness to pay high salaries is the same as belief that skill matters a lot. A manager who doesn't believe in high developer skill variation will not pay significantly above market rate, while a manager with strong beliefs in skill variation will pay huge amounts for the right people. Therefore I see any arguments against 10x developers as an attempt to supress wages, likely managers who wants to hire good developers without paying them more than average developers, or developers who are jealous of others salaries. Luckily a lot of companies acknowledges that talent matters a lot and pays a lot for it, and today the highest valued companies in the world belongs to that group.
There are some specific individual engineers who will get a specific individual task, faster than some other specific engineers.
If those same specific engineers get done many general tasks faster than another group of specific engineers on general tasks than they are just better in general. If some other specific task gets done by the other specific engineers better then it is just different domains.
Exactly. Not every task or goal fits every person equally well. A good leader understands this and does their best to find that fit.
But it is in my experience not considered okay to talk about this too openly because people get offended.
You wouldn’t ask your best engineer to lead a marketing campaign or your best marketer to design your servers. They’re smart and would figure something out eventually, but who gets the task matters.
The irony here is that the point of the article isn’t that “10x engineers” do/don’t exist, it’s that “things are more complicated than that”.
Assigning arbitrary labels (like 10x engineers…) so it’s “easy to understand” results in over simplified models that lead to faulty decision making based on invalid assumptions.
…treating everyone equal is perhaps also a faulty assumption, but it’s easy, and dealing with complex systems is hard.
Maybe instead of bitching about equality, which is just a symptom, we should promote using complex models instead of easy trivial ones.
…because just using different easy trivial modes is stupid; it won’t get you any better outcomes.
I like being treated like a cog instead of playing pretend-games of making me feel like a unique flower (but truth is still that I’m a cog). I prefer honesty. I prefer the brutal, unvarnished reality over executive bullshit.
A cog means I have specific responsibility and I will make sure I don't hog down the entire machine. I work well with other cogs - we mesh perfectly. Being treated like a daisy with beautiful narrative of lies would eventually lead to a delusional state of mind, dissent and ultimately negative spiraling burnout.
But one of you really is a daisy, people are not equal, and those daisies are actually what's responsible for most of this machine and it's origins in the first place. Without daisies there will be no place for cogs, the cogs come after the daisies
Even if there aren’t 10x engineers, there are still engineers with different levels of skill and knowledge in different areas.
One of the best engineers I ever worked with was terminated (he was a contractor) as he spent his career on the backend, was told he would work on the backend, and they assigned a complicated React feature to him over his objections that he had no knowledge of the framework or frontend dev in general.
HR didn't care that the person made the company more money than HR saves by doing location adjustments for all international employees combined because HR at the company had no notion of the value of an employee, only the cost, title, level, and location
This is common in large, dumb corporations: HR is the Blob. And if you are being recruited by a company that exemplifies that kind of culture, run away, far, far away.
A 10x'er is by definition an outlier. It would be absolutely silly for a business to build its planning on the existence of outliers in its staff, unless the company is small (< 20) and that individual is a co-founder or someone you can really rely on.
People leave companies for other opportunities even when they like their current job. I have to plan for that, whether it hurts someone's ego or not.
Isn't the "10x" label contingent on engineers being functionally indistinguishably, except some are allegedly 10x more productive? Specialization is what I figure has highest impact on turnaround times in a team setting. Just because an engineer is the most familiar with a component/subsystem - which allows them to make changes to that subsystem faster, doesn't make them an all round 10x engineer.
IMHO it's also an useful illustration that being able to replace people is asymmetric.
It may be that Bob can do Joe's specialization at half speed, but it's plausible that Joe can't do Bob's specialization properly at all, even after a year of training; so replaceability only works one way.
And I have worked with engineers that could do improvements to an unfamiliar component/subsystem faster than the current engineer who is the most familiar with it; i.e. their time of learning+adaptation+implementation was faster than the other persons' implementation alone. And it's not that the other engineer was incompetent, they were quite reasonable.
It refers to people with the same experience with the system. For example, lets say you have two persons working with a system and have worked with it for two years. One of them is 10x as productive in that system than the other. Neither of them had experience with such systems prior to this, so both were equally productive when they started, but one of them grew much faster and is now 10x the other.
Of course if you took those two and put them to work at a new system both would have 0 productivity initially as they learn the new system, but as they grow the differences starts to appear and soon you have a very stark contrast again.
I'm "10x" when working on one part of the system that I'm extremely familiar with but "1x" when it comes to other areas. Similarly, I have teammates who are "10x" in those other areas but wouldn't know where to start when it comes to my specialty.
> But we’ve constructed a corporate culture where this is not allowed to be said. So we bend over backwards to pretend everyone is equal and capable of the same things in all areas. Then we secretly make sure somehow by magic the truly critical projects are routed to the people and teams with more reliable outcomes.
Do you really think that was the motivation? That someone is going to bat for Bob at Alice's expense?
Or do you think it more likely that "equality" is another way of saying both Bob and Alice will never threaten someone in management enough to cost them even a minute of sleep on any given night, and that's all management really cares about at the end of the day.
> But we’ve constructed a corporate culture where this is not allowed to be said. So we bend over backwards to pretend everyone is equal and capable of the same things in all areas.
This is pretty much exactly true. Though I must say being a person who comes in and get plonked on the underperforming team. It'd be really progressive if the Alice character had to take on some fresh blood to share around the knowledge and let new people build rep. Nothing sucks more than being on an underperforming team.
Orgs: okay you are indistinguishable cogs and we will treat you as cattle
Devs: no wait not like that
Truth is everyone knows that who or which teams takes a task matters immensely. We know that if Bob leads it’s gonna suck and if Alice does it’s gonna rock and finish on time.
Managers know this also.
But we’ve constructed a corporate culture where this is not allowed to be said. So we bend over backwards to pretend everyone is equal and capable of the same things in all areas. Then we secretly make sure somehow by magic the truly critical projects are routed to the people and teams with more reliable outcomes.