I believe in the 10x engineer, but
erikbern.com
erikbern.com
Last week I was pulled into the tail end of a project which had just got pushed back to the end of February for complications. The project was now billed at 3 guys, 3 weeks. After spending an hour in a meeting I came up with a solution that is going to be implemented on Tuesday by one guy. Same risk, but a fraction of the work.
I know most of the time when you think about 10xers you think about some kind of math / programming / algorithm god, but don't discount big picture skills. Unfortunately I'm not sure how you teach big picture skills or put them down on a resume.
If you see one of your co-workers doing 10x the work of your other co-workers at high quality, then it's much easier to label them at a 10x engineer than trying to label yourself. Objective vs subjective.
When it came time to learn Spring, this guy flailed, and wrote Spring like it was struts. In addition, he was a pontificating jack ass, real abrasive personality.
The non technical and business users thought this guy was a super star. I've only quit a job once because of personalities, and this was that time.
Maybe he's messy, but nobody pays the janitor millions of dollars to clean up everyone else's messes even if they tell themselves he's important. Rather, they pay the people who made it worth cleaning up the building in the first place.
It's obvious, for example, that we don't need titanium cupholders in a car, but maybe titanium rods _are_ necessary to achieve a particular level of performance.
But in software, you'll see programmers doing the ethical equivalent of putting in titanium cupholders "because it's the best" or whatever, with no regard to the cost.
In my experience, a 10x programmer is a 1x programmer who knows where the value is and spends their time on that.
It's poor code design, poor code management.
It's more like:
- irresponsible house developer builds house very fast and very cheaply but he doesn't care about safety or design
- then building is beginning to collapse and tennants have to hire another developer to fix mistakes of previous developer.
They must pay twice! One time - for creation of the building. Second time - for fixing.
I have a webapp that I maintain for a family member written, by me, in 2005. It was using WebWork (which became Struts 2) and still is, and I am trying to move it to something more modern in bits and pieces. But it's requiring me to learn a lot, which I am trying to do in the limited time I have.
At my work we do way more modern thing, but so much so that I'm not able to do any UI stuff since they use tech I'm not "hit the ground running" capable of doing. But I'm trying.
I hope I'm not abrasive however.
Which language has standard library small enough that people can memorize the whole thing?
My own web projects in java 15 years ago were coded in java and glued by JavaScript (Rhino) with templates in JavaScript, which were compiled into bytecode for speed: fast, secure, simple, 10x faster to code.
They learn for fun. They are endlessly curious. They are incredibly humble and get things done.
They do get more done in their part time hours in the evenings than a full time equivalent. More importantly, 10x really helps with building the quick things quickly and growing them as quickly as possible.
Good lord I sound like a ridiculous fan boy.
However there may be other things he values besides money. Continue to make those great and I'm sure he will continue to enjoy being your coworker.
I have been both subject and observer of situations where someone's performance was amazing in some cases and lacking at best in others. I have experienced being 10x when the situation was right, and 0.5x when it was wrong.
So how do you make a 10x environment on purpose? I've tried on teams I've led, and it is by no means easy. Can anyone with concrete experience share reliable tips?
I think there are two necessary parts:
1. A high level, well-known, agreed-upon plan. Everyone needs to know what they're working towards, why they're working on it, and how they'll do it. This lets people work largely autonomously but towards the same goal, reducing friction. I've been a 0.5x engineer because my manager told me what I needed to build but not why. So, I'd build something, and the feedback would be "no, that's not exactly right, just do it this way". What could have taken an hour would take days while I slowly figured out what he was imagining.
2. As few blockers as possible. Use tools and languages the whole team knows or can learn well. Create a collaborative environment where people can ask questions instead of spending hours working through tiny issues. The manager should make removing external blockers one of their highest priorities.
This is what allows people to work at peak efficiency. I think when there's nothing holding them back, most good engineers are "10x" engineers.
Add to this constant meaningless meetings where everybody is late and unprepared.
I often hear "I will work tonight or on the weekend so I get things done". I don't understand why everybody seems to accept that the workplace environment is bad and nothing can be done. I have raised this to senior management quite a few times but they just shrug their shoulders.
This seems to conflict with ease of management, which might be why this kind of autonomy is rarely granted. Cubicles are cheap and easy to manage, having 50 different environments in a 50 person office and resolving conflicts between them is not.
There's some approaches that partially address this problem, for example "Work from home", which whilst allowing some workplace customization has a number of drawbacks.
I guess the simplest way to go about it from a strictly physical (eg. excluding communication channels) work environment standpoint would be to give people a space and money budget, and treating them like responsible adults with it. "want to wall in and sound-proof your space? sure". "Need 2 different office chairs for your back problems? Put it on the list."
Set a suitable budget cap per person, divvy up available space, and optionally set up a position that handles ordering of things and tracking of funds spent.
Historically speaking, very senior employees get to do this with their own office to a degree. But the output and impact of good software engineers might warrant the same kind of autonomy.
It may be a considerable leap of faith from a management standpoint, but there's some absurdity in managers trusting engineers with business critical systems, but at the same time being concerned about their ability to pick a desk and chair to seat their butts upon.
Then there's the thing with open offices, but that's a cost of communication issue, signal-to-noise ratio kind of thing. Talking in an open office is broad-spectrum and cheap for some of the participants, but information conveyed is not necessarily valuable in the greater scheme of things, in addition to incurring attention costs for everyone else.
It's like radio without the FCC or everyone communicating over the broadcast address in a network.
In my company senior employees seem to view offices as a reward not as a productivity tool.
I do think that senior employees seeing offices as a reward instead of a productivity tool is not ideal. Depends on the organization though, a call centre doesn't follow the same rules as a start-up or an assembly line. Forcing any of these models on the other would result in sub-par results.
It might just be latency, where the structure and nature of a business changes, but the culture and processes don't quite catch up. Software engineers in cube farms like Skype trying to push P2P messaging to mobile. Some mix of sunk-cost fallacies and the slow momentum of behemoths, I'm sure of it.
I do have some opinions on how to achieve these changes, but it'd be hubris for me to suggest them to you, since I'm unaware of your particulars. But I still hope that you get to work in a 10x environment some day. We all should.
There are projects, and there are chores. Everyone wants to work on the projects all of the time, but that is wasteful. When one is productive, they should work on the projects, and when one isn't productive, they should do the chores. That's a habit that can be learned.
The only person who knows what they should be working on is themself. So, autonomy is important. You can't have a person with a habit of using their time most effectively who also isn't in charge of when and how they spend their time. Self-management is a skill that can be taught.
I've likewise experienced both 10x and 0.5x situations. The latter invariably arose from sitting in a corner, divorced from context or support. The former is extremely rare and I've only achieved it on personal projects. But I'll settle for a motivated and healthy team of 5xers any day.
Yes, extroverts, specifically. :)
Even if you've been close friends with someone for twenty-five years (as is the case with someone I pair with for some problems), there's still a fair percentage of your thinking that will have to be focused on social stuff: putting expressions on, conversational behavior, avoiding asides that take a second to think but would require a minute to explain, etc. These are things that tend to occupy the same mental space as where I am thinking about the context of the code I'm writing, and while pairing can bring back some of that contextual thinking in the form of the other person, the bandwidth is so much lower that pairing seems useful mostly for learning, or for sharing a problem that I've already struggled with (so that my deepest thinking about the problem happened while I didn't also have to run sociability at the same time).
It's about making great decisions. That includes using the right tools, using libraries instead of inventing everything yourself, not using libraries when not appropriate and pushing back on a product decision that does not make sense.
a. There are no 10x engineers, just environments where there is a 10x discrepancy in productivity.
b. There are no 10x engineers, just 10x yardsticks.
c. There are no 10x engineers, but plenty of .1x engineers.
Also, I hate the term "10x engineer". Everything follows a normal distribution.
Even if people were to use a new term such as "3-Sigma Programmer" instead of "10X Programmer", the ensuing debates would still be the same.
To make peace with the "10x" label, I suggest people just think of it as a figure-of-speech instead of a mathematical term. We don't get hung up when people say "Star Wars IV was ten times better than Phantom Menace" or "I'm not even 1/2 the football player I used to be."
A normal distribution doesn't preclude the existence of a 10X, just describes the rarity.
Yes, this is why the 60 wealthiest people have as much wealth as half of the world combined.
If you put them all on the same team as a 1x engineer, there will be the perception that one engineer is 10x most programmers.
Evidence suggests that technical talent is bimodal.
If there are plenty of 0.1x engineers, then an x engineer is actually 10 times better. The units doesn't matter if the ratio keeps being the same.
If you were interviewing and on Monday you have a 1x engineer and 9 .1x engineers, you’d assert you met a 10x engineer. Then on Wednesday if you had 9 1x engineers and one .1x engineer, you’d assert you met a .1x engineer.
The dial on a binary 10x engineer goes to 2.
The dial on a hex 10x engineer goes to 16.
But what does that proof? I think nobody doubts that the difference between a bad developer and a good one can be a factor of ten or more. Outperforming a good developer by a factor of ten is a totally different story. It is certainly possible if you have some good insight, if you spot some non-obvious structure in the problem that you can exploit to make your life a lot easier. But doing this consistently is probably at least a rear feat.
So the question is to whom do we compare our 10x engineer candidates? The average one maybe, but the average of what? Your team, your company, the entire industry? I would argue that the age respectively experience structure is really important. When you begin you learn a programming language but it takes some time until you really learn programming, until you reach the point that the languages no longer matters and you are able to focus on mapping your problems to more abstract concepts and typing it out in some language becomes the boring but necessary part of your work.
Possibly related - it's interesting that everyone has heard of the 10X developer, but there's no equivalent concept of a 10X company or department, or even of 10X or 0.1X management.
It's not that the concepts aren't obvious once they're mentioned, it's that - unlike the 10X programmer - they're often mentioned.
Is it naive to wonder if management would improve if managers had to worry about getting tagged with the 0.1X label?
I have met, hired, and worked with engineers of all stripes and tend to think this idea is just a mental way of covering that "we have a guy our company or team relies on to a high risk degree".
10x engineers are a bad sign because it means she or he probably belongs with a better crew... And someday either they'll realize that or leave for another reason, exposing our over reliance on them.
If you think about it, there's essentially no physical or finite limit to how much you can get done in a day with software (outside of, like, typing speed), so it boils down to how fast and comprehensively you can think. So you might think, well, nobody is 10x smarter than anyone else, and that's probably true, but you could certainly imagine someone that has learned 10x more and has 10x more experience and given the right context can apply that effectively.
I strongly agree with the no-jerks part. I think, short term, you can be a jerk and still be effective, but long term if you're unpleasant you'll develop blind spots because people don't want to deal with you. Once you have significant blind spots, I suspect it's very hard to maintain the 10x pace. There is of course, a strong counter example here, which would be someone like linus torvalds (who is both extremely effective, and, by his own admission, kind of a jerk), but I think while exceptions like that exist they're not the common case.
You can be 2x smarter and 2x more experienced and have 2x better research skills and 1.25x better administrative skills/support (time management, office layout, etc.) with the net result of 10x effectiveness.
You can be 12.2% better in 20 different but mutually-reinforcing skill areas.
Or, thought of a different way, an ordinary engineer might solve 90 problems easily but get bottlenecked on 10 challenges. You can approach 10x by solving 99 problems easily and only bottlenecking on one. Being an outlier isn't necessarily a matter of one big advantage, but can be about combining a lot of small advantages.
LeBron James, for instance (arguably the greatest basketball player in the world), isn't really 2x better at anything compared to other top basketball players. He can't run twice as fast or jump twice as high. He's just slightly better at everything. Small things can stack to a large degree. Like, how many programmers know the important keyboard shortcuts in their development environment? Obviously it doesn't take a genius to learn keyboard shortcuts, but shaving 5 seconds off operations here and there can have a huge effect when you start thinking about how that multiplies in timescales of weeks or months. (Not that knowing keyboard shortcuts makes you a great developer, just saying, seemingly minor advantages can be huge multipliers)
So yes, similarly minor things can be huge multipliers , like you say.
[1] http://www.ybrikman.com/writing/2013/09/29/the-10x-developer...
Somehow there are 10s of thousands of people who think they are 10x engineers or have somehow hired a 10x engineer.
That's why they aren't actually all these 10x engineers people talk about.
There are 13,700 professional athletes in the United States [0], compared to 670,000 amateur athletes in the Amateur Athletic Union [1] (there are surely many more outside of that particular group but let's go with it). That gives us a 2% rate of 10x athleticism.
Let's assume that 10x engineers occur at the same rate as athletic exceptionalism (yes, that's silly but why not). According to another questionable statistic, there were 1,114,000 software developers in the US in 2014 [2].
Now we've already established that outstanding engineers occur at the same rate as professional atheletes. What does that give us? Tens of thousands of professional 10x engineers.
[0] http://www.bls.gov/ooh/entertainment-and-sports/athletes-and...
[1] https://en.wikipedia.org/wiki/Amateur_Athletic_Union
[2] http://www.bls.gov/ooh/computer-and-information-technology/s...
The very last two paragraphs of my blog post:
> It’s important to put things into perspective. Star programmers, athletes, writers, and scientists are exceedingly rare. I wouldn’t recommend building a hiring strategy around solely hiring “rock stars”; you’ll end up looking foolish and lonely. Don’t let perfect be the enemy of good: hire the best engineers you can get and give them ample opportunity to develop and get even better.
> However, don’t fall into the fallacy that all programmers are created equal. There is a vast spectrum of ability in any creative profession. On one end are the type of hires that can sink an organization, actively increasing tech debt with every line of code they write. On the other, there are people who can write code that changes what is possible and have an impact that is an order of magnitude greater than the average.
> Most of the 10x factor is most likely explained by team and company factors (process, tech stack, etc) and applies to everyone in the team/company. Intra-team variation is thus much smaller than 10x (even controlling for the fact that companies tend to attract people of equal caliber). Nature vs nurture…
Definitely not true! I have been in companies where 1 engineer outperformed 10 others with everything else being the same and on the same team. It was really obvious too. It does happen. eg, he could handle 10 bug or feature requests in the same time it took some of the other engineers to handle 1.
I believe 2x, 3x maybe 4x but 10x seems far fetched. Are you normalizing for hours worked in your appraisal of performance?
Per the arguments laid out in Peopleware I am opposed to my team members working more than 45-50 hours a week outside of rare crunch times.
I've seen some people read through a bug report and have the area found and fixed in a couple of minutes, and the bug passing QA first time.
I've seen other people take almost the whole day just to track down that same bug in the code, let alone fix it or get it past QA. By that time, the first guy had finished a whole stream of other tasks.
10x definitely exists - hop around a few companies and you'll come across one pretty quick. They are rare, but easy enough to find if you've been through a few startups.
I think the x-factor we are talking about is too abstract to really have meaning. For example, besides speed, my x-factor takes into account things like test coverage, maintainability, code performance, etc. When you make it very multi-dimensional it tends to even people out as folks often have very different strengths and weaknesses.
However, I have seen developers who are incredible in all of those aspects and simply run rings around regular good developers. People who you can give a problem and they've already designed a fairly novel algorithm for best case complexity in 15 minutes to handle it. These people exist and they are not 1x developers, unless creating novel mathematical proofs in 15 minutes counts as 1x ....
Anecdotally, I have.
None of them have been assholes - the opposite actually - once you've gotten to know them. If I were to generalize: most of them are not particularly extroverted, so that may be a cause of misunderstanding.
Some of the 3-5x engineers (they also exist!) have a tendency to treat people as "idiots" until they have proven themselves worthy intellectually/engineering-wise.
I would not be surprised if this also held true for engineers. 10x engineers already distinguish themselves through their work output. It's the 3-5x engineers that are good enough to tell themselves that they produce more than your vanilla engineer, but not good enough that they couldn't get lumped up with them. It's that uncertainty that produces viciousness in the attempt to remove yourself from that set.
Unless your show them that your are a "3+x engineer", they'll try to distance themselves from you to not be tainted by association. I guess it also follows that they will be the ones obsessed with 10+x engineers.
Kings aren't vicious, it's their courts that are.
To provide some context for while I feel this is important, when I first moved into BigCO, there was a period of reorgs in my org entirely out of the control of anyone not in "the powers that be". As such; there was a "generation" of new engineers brought in as juniors who were laterally moved multiple times in a few years. New engineers continued to be brought in, but due to the promotion structure of the org, a lateral transition essentially "resets" you, so new grads were coming in at the same level of people who had been delivering for years.
Now; there's another discussion if this relates to the "3x engineer" thing, which I wasn't even going to get into, but for practical purposes these engineers WEREon average performing multiple X better simply by nature of domain experience and rampup. This resulted in different symptoms from different people; the more zen of my peers simply got saddened about feeling looked over for promotions and started considering other options. Many left for other companies. The less zen (myself included) got more "fierce" as a sister post elsewhere put it, realizing that to "catch up" with the career track, high visibility, high impact projects were needed, and that required pushing harder.
To bring some sort of conclusion out of this rambling mess; I'm not sure your statement of "vicious" is the right word, but needing to stand out from that set seems to be an inevitable consequence of how many promotion structures are built, and being aware of this dynamic, engineers can be both better at their job by staying on top of their internal responses and keeping them productive (why I differentiate "fierce" and "vicious"; you can have the former without the latter I think), and Managers can better stay on top of their team dynamic and keep employees happy by realizing these emotions happen, since I find it's an oft under-appreciated dynamic.
Man that ended up being FAR more of an essay than I intended. Hope there was at least one well expressed thought in there.
In short, they bullied, insulted and did not inspire co-workers positively, instead demotivating them by acting impatient and making fun whenever interacting about work.
Vague statements, but don't really want to get any more specific.
Some patterns I have noticed:
They are really eager to share their knowledge if you invest serious amounts of time with them AND you are capable of intellectually challenging them. The only way I have made this work is in-person. It is really time-consuming, but also quite rewarding.
When communicating with random people/strangers in the company via email they can appear cold/hostile.
None of the people I've worked with have made fun of people. The more common (but still as disruptive) reaction when dealing with "stupid" people over email is to "shut down communication" - only delivering the minimum bare facts that a competent person would require.
Imagine a quick thinker from an accomplished competitive programming and math background who has a raging ego and a chip on their shoulder. From what I've observed some companies see this in interviews and won't hire despite solving the technical challenges significantly better than others.
HFS+ not supporting true case sensitivity was one example. Or "I hate spring/struts/etc." just because they once had to deal with a bad codebase.
A lot of it is just tripping over one's ego to me. I don't think you can become a mythical 10x by placing so many filters in front of your work.
I have found that many people find debates uncomfortable. I love them. They create value.
(In fact, whenever I meet these people I've met from previous jobs, inevitably we end up arguing intensely about random stuff. And enjoying it...)
I think you're right that many 10xrs like to debate, and that value can come out of debate. However the best 10xr Ive worked with was equally at home with a 3+ hour technical debate or collaborating with folks who don't give their best contributions during debates. Brilliant, efficient, effective, collaborative, quick, and humble.
I'm not sure I can be described as "humble". I do however place extreme importance on sincerity, particularly in debates. (Being able to switch positions when proven wrong is another essential part, of course.)
Someone working within their field of expertise, with the tools to get it done, and without the typical roadblocks that stand in the way. Hopefully you've been there and know how it feels.
And maybe you've also been at the other side of the spectrum, working with an ever-changing, badly designed and documented piece of technology, with many surprise problems biting you in the ass, ever changing goals, and bad management decisions.
I've been a 10x engineer at times. But I know I've also been a 0.5x engineer. The knowledge on how to solve a problem and how to find an answer doesn't change, but the perceived throughput of a person definitely does.
And I have worked on projects where nobody knew where things should go but a lot of people had a say in what not to do. So we all ended performing at 0.1x.
Every two-bit company is demanding "10x engineers". That is what doesn't exist. There are not tens of thousands of genius software developers in the world.
If you hire a 10x engineer and get him to move a button two pixels left, and then tomorrow someone else tell him to move the button two pixels right, he won't be a 10x engineer, he'll be a 0x engineer. There's a lot more involved and it compounds. An engineer knowing what to do and what not do (a skill often overlooked) can help immensely, but everyone needs plenty of support to be at their 10x.
In my (limited) experience, those that don't learn this tend to do all by themselves "because the others can't do shit", get overworked and are unpleasant to work with. Those who do are able instead to focus on the most important (and interesting) parts while letting the others taking their boring share.
I don't know if I'm a 10x dev, but I've heard this mantra few times.
It's most annoying when it happens because I actually strive to make something simple. Like I once needed to index members of some C++ STL container, so I used std::map<key, container::iterator>. It went like that:
- WTF? A map of iterators? It's complicated! Remove it!
- But the objects need to sit in this container and this extra index is also required.
- But... but.. It's complicated! Remove it!
Containers tend to persist over relatively large blocks of code, whereas iterator invalidation can be very tricky and most people get bitten by it at some point.
Your computer is extremely complicated, but it can be broken down to parts that are simple to understand in each level. That's pretty much the entire benefit of a good engineer. They know how to make self-contained things whose purpose and interface with the rest of the system is easily understandable.
For example, lets say the 10x engineer wrote fast inverse square root [0]. Most people would look at the code and not understand what's going on. It requires a lot of domain knowledge but provided nice speeedups at the time. Is it more complicated than necessary for some problems? Absolutely. However when used frequently as originally intended that speedup allows for more compute to be spent on higher level components useful to the rest of the team. It would also be a pain to maintain for those unfamiliar with some of the details but can be well encapsulated into a simple function call in a math library.
Thw other case this illustrates is that code evolves and a solution available now to make a system simpler may not have been available in the past. Today the same code for fast inverse square root is outdated in favor of hardware calls, so if observing the code now it is certainly over complicated for the solutions available at hand.
[0] https://en.m.wikipedia.org/wiki/Fast_inverse_square_root
I'm inclined to agree with him.
That's why this whole topic is stupid.
However, I have noticed that whenever I am called 10X guy, something happens and I ultimately end up to being 1x or leaving the company. The following are kind of negative thoughts/symptoms that occurred
1. In most companies - it means doing 10 times work while getting paid just 5-20% higher instead of 10 times higher (here 10 is just an example multiplier).
2. It means I am a workaholic - and others enjoying the benefits of my work because of (1)
3. The above two can potentially result into toxicity build up within me and then within the team. It does happen occasionally and I have to work harder to avoid it.
4. You are not with your own kind (like species on a mental plane and not race/religion) and your growth is limited. I ended up leaving companies or teams when I was called out-performer consistently - not because I was an out performer, but because I was not learning much from the team. (On 4) - I tried to stay in one company like this, because it was hard for them to fire me for obvious reasons. Ultimately I got fed up after few years. I also unsuccessfully tried to get fired by deliberately underperforming, because the severance was too good - but they wouldn't derate me or fire me. Finally I resigned and left on good terms. Retrospectively thinking, I wasted those few precious years of my life
5. One gets used to elitism - and that is a very bad thing. It closes the persons mind. I remember how I disregarded an amazing solution from a junior team member because I was comfortable with my way of doing things. Unfortunately, I realized the mistake a bit too late.
6. If I am a rabbit I am constantly worried about the turtles - they will beat me with consistent performance over longer run because I will get bored of the race.
Also, I don't think having a 10x engineer in a team as a good thing. And if everybody is 10x, then nobody is - which can be good.
I thought being a 10x engineer meant being able to achieve a task which could not be achieved by 10 average engineers.
Does it mean the ability to do 10x the amount of work than everybody else? That doesn't seem extraordinary, that's mostly a case of focus.
In general I dislike the egotism attached to the idea that one engineer is the cause of other engineer's productivity. That's a lame way of self-congratulating.
Almost seem appropriate given the title.
I personally see my own productivity improve by about 4 fold given the right conditions - i.e. being able to focus on the one task at hand, not jumping between projects and not being interrupted with questions every half hour. Anyway that's my comment having not read the article.
I can't claim I was 10x smarter than my coworkers. I wasn't. But I knew how to use tools that were at least 2x better and put in at least 5x the effort. Looking back it's amazing how little effort my co-workers (and boss) did put in at that place. Public sector for you I guess. I soon moved on to greener pastures. Some places value 10x. But other places it's better to do the bare minimum to avoid threatening anyone or raising the expectation bar. Sad working conditions best avoided by those with desire to create or improve. A good place for those who claim 10x developers don't exist to seek employment.
Seriously?
It's become politically fashionable to discount the contributions of individuals, because if we think about differences in talent and follow the implications, we're led to crimethink. There was even an article on HN a little while ago suggesting Einstein didn't really do anything important and that his discoveries were just a product of his time.
It's a very easy statement to make but really hard to prove. I will probably never write a solid OS kernel, but I'm also not going to spend 5 years trying to learn all of the concepts and hard-won knowledge just to prove that I can when I really don't want to be doing it in the first place. Especially when you can back out of that original argument by saying "Oh, well you were 10x, you just didn't know it".
I also haven't read too much about career progression for engineers which plays into all of this, i.e., what percentage of 10x should I be after 6 months? 1 year? 5? 10? What skills should I possess on that career timeline? The answer right now is pretty much open-ended.
Having said that, I have seen projects and management lean on one or two guys out of a whole group to deliver the quick and mostly working plumbing + base work. And then pass off the polish work to the 1x or 0.5x employees.
Also, I saw no link between output and 'being a jerk', and that is highly anecdotal.
This is a similar way that sports teams work, or certain skills propel you to a different rank in army. Office work seems mundane, but management is well aware of the ghost benefits for hiring multiple-x engineers at 1.15x the salary.
If it's your company then by all means you should listen to everyone's advice. But if it's not your company then you should give your advice, but if your employer doesn't want it then that's their issue. At that point there's no ethical imperative on your part to try to prevent your business from going bankrupt, so as long as the checks keep clearing I don't see the issue.
1. It doesn't look good on your CV if you only worked on projects that don't have any business value.
2. If what you do does not have any value chances are someone will figure out at some point.
3. It's not fun to work on a project that has no value for anyone. This is the kind of thing that will create burnout.
If what you are doing is very intellectually challenging for you, or it has value other than business value then it might be different.
I completely disagree. If you work on a really cool project that's very technically interesting, that looks great on a resume.
Do you really think your interviewer (at the company you're applying for a new job at) is going to call the old employer and ask them "Hey, did this project on this guy's resume delivery any real business value?" Of course not. They only go by what you write on your resume, so you can spin it however you like. If it was an interesting project but was shit-canned because of bad management or bad timing or whatever, you don't put that part. You talk it up in the interview when asked about it, talk about how technically interesting it was, what you learned there, etc., you don't volunteer that it ended up being a bust. Even if you have to spill that (because you're specifically asked), you concentrate on the good points, how it was a great learning experience, how what you developed should be useful on future projects, etc.
Prospective employers are looking for skills and experience you have which will help them in the future. How financially successful some project you worked on was is really irrelevant, since there's far more to the success of a project than just the technical aspects. Lots of companies have built technically superb products only to have them fail in the marketplace because of bad marketing, other bad management decisions, too much competition, etc. OS/2 was completely superior to Windows 3.1 and 95 yet it failed in the marketplace; that doesn't mean that you wouldn't hire a guy who worked on it.
And there are definitely people that can produce 10x the output and make far more meaningful progress for a company than others.
I will do what ghostbusters recommend :
- when someone asks
- are you a 10x engineer?
I will reply
- yes
And not try to disabuse non technical folks from their nice comforting ideas about how development really happens
But I think focusing on this work is wrong-headed. As noted in the article, making 5 other developers twice as efficient is roughly equivalent. The difference is that I can't sustain a 10x rate (I do a lot of "research programming" where I'm probing a domain rather than producing production code), while there's a good chance that training other developers will translate into a 2x (or better) increase in the team's productivity.
http://webcache.googleusercontent.com/search?q=cache:ikC6A7V...
Usually a mix of not knowing how to use docs, google things or just stick to their old ways (the 1/20 miraculously find bugs on well tested software used by lots of people - at least that's what they think)
If you bike-shed programming languages then I'm throwing you out the nearest window.
"There’s no such thing as a 10x engineer spending time on something that never ends up delivering business value. If something doesn’t deliver business value, it’s 0x."
I have found myself to work really well as a "value enabler" of 10x engineers. It's a symbiosis thing - my best work has been done working with a 10x engineer with our skills complementing each other (I'm strong on the business value/UX side, defining overall architecture/network protocols/optimizations etc, but weak in e.g. hardcore C low-level implementation.)
A challenge: Whenever I've stopped spending 20 hours a week working closely with these guys (in order to focus on building other essential parts of the business where there are no 10x engineers), their output value has severely decreased. They often fall back to like 2-3x. (Really nothing to be ashamed of, but...)
Things like this can make company switching challenging :).
He's the 10x of basketball.
The team gets built around him.
Same goes for 10x anything. Steve Jobs was the 10x of CEO, company built around him, etc etc.
To say the causes are environmental is just to live in denial. There are people out there waaaaay smarter than you. Or way more athletic, way more X.
This doesn't negate the importance of getting along and being able to build teams around 10x people but make no mistake - id Software was John Carmack and everyone else. Same goes for anything else wildly successful.