In software, engineers are sometimes referred to as "10xers" - implying that they're capable of producing 10x the productivity of a comparable person. When I was getting started in the industry, this was a bit of a goal for me. I'd like to be perceived as superhuman, and this is a pretty explicit endorsement of that. I'd sometimes work a little (or a lot) extra just to prove that I could do more than my peers. One guaranteed way to 10x is to work 10x the hours.
Over time, I did end up being what I call a "feature 10xer". I could often produce, measurably, 10x the amount of code or features than other people on my team. I wouldn't often produce 10x the reliability, but I'd certainly make the CEO and PMs happy, which was my goal. This also meant sometimes hacking through systemic problems (getting to the root of issues isn't fast). At early stage startups, this seemed desirable, but came with many drawbacks.
At startups with older codebases, this attitude still prevailed, although it usually takes a different form: the "intuition 10xer" is the person who knows the codebase and hacks well enough to deftly navigate through it far faster than (otherwise extremely competent) peers. This means they're the "debugger of last resort", and that they can design features in their head and then implement them without needing to change the design, since they knew all the caveats and patterns before reading code. These people also often have been entrenched in their own decisions for so long that they bear little empathy for new team members. Their intuition is so dialed into the history of this specific codebase that they can't even imagine what it would feel like not to know where everything is - everything is where it belongs, after all!
Both of these roles break down at critical times in the business: when you need to react to growth -- either engineering headcount, or scaling pressure from customer growth. I've observed the following common patterns:
- The "feature 10xer" creates debt faster than everyone, creating a positive feedback loop of debt. To sustain their relationships and pace, they don't have bandwidth to refine shipped work. As a result, a minimum of 10 people are needed to focus on the reactive work they leave behind. If you're lucky, those 10 people won't need to consult the 10xer to fix things, but eventually this will slow the 10xer down, which is extremely frustrating. I've observed that this is when the feature 10xer transitions into an intuition 10xer, or they leave out of frustration.
- The "intuition 10xer" becomes a blocker for design and review, bottlenecking all work. You grow the team, the performance issues start coming up, and the system's complexity belongs to an individual. They get frustrated when it takes others 10x the time to fix things, but their desire to "just do it themselves" and fix things faster also slows the team down because they're responsible for reviewing nearly everything, and they're busy fixing things. Everyone sits around waiting for this person, contribuiting to a feedback loop of slowness.
At the end of the day, if one team member is dramatically outperforming the others, you have a huge scaling issue, visible or not. If you manage to survive this phase of your company, pain is on the horizon. All a 10xer does is create 10x the work for others, either now or later. That doesn't mean that having senior people on your team is bad. But it does mean that continuing to have them "go back to the dopamine dispenser" for years after they've become a load-bearing decision maker results in the code becoming less and less understandable to new people as more and more decisions are made in a vacuum by someone with less and less exposure to the outside world. Inevitably, these codebases are extremely expensive to onboard and frustrating to work on, making it difficult to hire and retain new employees, contributing to the bottleneck of these individuals.
Instead, teams should aspire to see (roughly) equal distribution of work, with the senior people spending the "other 9x" on technical debt, documentation, mentorship, developer productivity, and proactive issue/complexity resolution. Arguably the most beneficial side-effect of this arrangement is that the example set by your 10x citizens are that new hires are empowered to begin their journey emulating these activities. You'll occasionally need to encourage newer people to ship imperfect things, but you won't have your 10xers shipping imperfection and your new hires cleaning up their mess - an arrangement that feels good today, but hurts your hiring and SLOs in the long run.