I don't think there's anything wrong being this 1x engineer. In fact, the 10x engineer is probably only being paid a touch more for doing a lot more work and having a lot worse work-life balance.
If these 10x engineers really exist, they're rare. Building an engineering department with this type of employee isn't sustainable. In 20+ years I've only worked with maybe 2 genuine examples of the good 10x engineer, and far more examples of the bad "10x engineer" who flies around quickly reimplementing patterns that they implemented at other companies, whether they're suitable or not. Once the low-hanging fruit is…
This is jaded and angry, but I think there is another archetype called "the politician." They play the game extremely well, providing poorly thought out solutions quickly to problems they haven't dug into the complexity of. They lay operational traps everywhere in their quest to get things done fast (like directly embedding config data in code to avoid fixing the config format). Once they've picked the low hanging fr…
I'd wager the "product manager" equivalent of this is even more widespread. They constantly disallow tech debt sprints or work to happen, in order to get that nifty new feature out the door quickly in and will tackle the cut corners and tech debt "later, after MVP" or somesuch nonsense.
Then by the time that debt must be paid, they're off to another team|org|project.
This reminds me of an old essay: https://www.joelonsoftware.com/2005/07/25/hitting-the-high-n... The thesis is that the "10x engineers" don't output a linear multiple of the same kind of work their peers do. Instead, they implement solutions that their peers wouldn't or couldn't over any length of time. This matches my experience.
The 10x engineer identifies common subproblems across different problems, and then creates a layer of reusable code which becomes a library. Then uses this library to write code 10x faster. The 10x engineer tries to standardize problems and solve them en-masse. The 1x engineer sees every problem as a different problem that requires a different solution. The 10x engineer talks about abstractions, the 1x engineer talks…
If you have never seen a 10x engineer you either have never worked with truly talented people or you haven’t worked on actual hard problems. There aren’t just 10 or 100x engineers , there are even infinityX engineers when you work on actual hard problems because some of those can only be solved by handful of people.
This reminds me of an old essay: https://www.joelonsoftware.com/2005/07/25/hitting-the-high-n... The thesis is that the "10x engineers" don't output a linear multiple of the same kind of work their peers do. Instead, they implement solutions that their peers wouldn't or couldn't over any length of time. This matches my experience.
It’s interesting how obvious this is for other domains. For example, imagine you are hiring for an orchestra, and are told just to increase the violin section by five to make up for the lack of good violinists.
I'd add "The Gardener". The gardener just wants to tend to things, taking thankless cleanup work and iterating away on it. Ops, metrics, tech debt, ACLs, pruning dead code, etc. Some people just like to organize and clean things up.
Yes and no.
I have been asked if staff engineers are around so that they can pick up projects noone wants to do. This entirely defeats the point of staff engineers.
I would want my staff engineering bunch to either pave the path or mentor the teams to do it themselves. Making it easier for the teams and future engineers could be a better strategy and effective multiplier.
If there is organisational mission critical software lacking any of this then it is a p0 and I would count it under high impact work rather than gardening.
Besides depending on company size, some of those responsibilities should belong to platform teams.
Although this is a generalisation of overall population in few buckets, it helps people understand what it is really.
You can assume different archetypes at different times. That's the best thing about being staff. The staff engineer is a clear leadership role with expectation to perform each of these archetypes at varying degrees. The person might prefer to be one of these archetypes but doesn't shy away to pick up others if the situation demands. Of course, they and people in their vicinity would want to play their strengths.
I usually think of an at-work "politician" as somehow taking advantage of relationships or social forces. What you describe sounds more to me like the ""10X engineer"" (with extra scare quotes for good measure). Many people have been skeptical of the idea of the 10X engineer. One take is that if your normal engineers are less than 1/10th as productive as another engineer and all of them are merely human beings, there…
> Many people have been skeptical of the idea of the 10X engineer. O Nah, of course 10x engineers exist. A 10X engineer saw that hundreds of engineers were writing MPI code to process data and struggled with error handling and therefore came up with a map-reduce framework and its underlying infra. The same infra also helped bootstrap a whole industry. In this case, we are talking about 10^6X engineer. Another 10X eng…
> Linus wrote git in days, and it was way better SVN. Linus designed and coded some data structures, and some basic utilities to manipulate and store them, in just a few days - based on a fundamentally better model and as a replacement for an existing product they could no longer use. Designing and developing git into a usable product and system took a whole lot longer and involved thousands of people. The examples y…
Instead of being pedantic, it would be better to describe how the examples are flawed, so we could have had a discussion. But you think "nah let's be pedantic". I urge you to reconsider not being pedantic next time And what Linus initially wrote was definitely a usable product. The product has evolved more since then, but that doesn't mean the initial version doesn't work. Actually most of the original code still exi…
I'm going to ignore the personal attack and get right to the point. If you redefine '10X' to involve impact, speed, or innovation, then you're going to invite external factors of chance (popularity, adoption, etc) and the work of others in building the tools the individual engineer uses - albeit perhaps more effectively than others. Further, they did not 'write' a 'popular software' in days - it was an early prototype that took years to gain the momentum it has now, as I was saying. Trying to credit Linus for all of git is very much like trying to say that the author of a book on which a critically acclaimed movie is based is an amazing filmmaker. You simply can't credit single people for the work done by more than one person. Nuclear though they may have been to the work being there, their impact is far less than you would suggest. There are >10X teams and times and there are engineers who fit particular >10X teams and who are more likely to fit others, but there are no lone >10X engineers.