Fingers twitching with a residual buzz from too much caffeine and not enough REM sleep, I watched the blue glow of my phone illuminate the bedside table at exactly 3:19 AM. The Slack notification was a short, sharp burst of artificial dopamine. Marcus, our lead backend architect, had just pushed a hotfix for the staging environment. ‘Pipe’s clear. Sprints back on track,’ he wrote. By 9:09 AM, the management team was virtually high-fiving him in the General channel. He was the hero. Again. He was the fabled 9.9x engineer who swooped in while the rest of us were dreaming of sheep and solved the problems we hadn’t even finished documenting. And in that moment, as the adrenaline faded back into a dull, thumping headache, I felt a deep, nauseating sense of dread. It wasn’t because I was jealous. It was because Marcus was becoming a single point of failure that we were actively incentivizing to stay that way.

I tried to explain this to my dentist yesterday while he was elbow-deep in my molars. It’s hard to be profound when you have a suction tube hooked into your cheek and a bib covered in fluoride splatter. I was making these frantic ‘uh-huh’ sounds while he talked about his new irrigation system, but what I really wanted to tell him was that software development is increasingly like modern dentistry: we spend 49 percent of our time fixing the ‘heroic’ patchwork of the previous guy who didn’t want to explain how the nerves were actually routed. The dentist just nodded, probably thinking I was complaining about the bill, which incidentally was $979. He didn’t grasp that I was talking about the systemic rot that happens when you let one person become the ‘keeper of the light’ because it’s faster than teaching the rest of the lighthouse crew how to strike a match.

The Myth of the 9x Engineer

This obsession with the 10x-or let’s be precise, the 9x-engineer is a myth that masks a profound lack of organizational maturity. We celebrate the person who stays up until 3:19 AM to fix the breaking build, but we rarely ask why the build was so brittle that only one person in a department of 199 developers could diagnose it. We treat knowledge as a trophy to be won rather than a fluid to be shared. When you have a Marcus, you don’t have a high-performing team; you have a hostage situation with a very high salary. The rest of the team stops trying to understand the core logic because they know Marcus will just rewrite it anyway. They become passive observers of their own codebase, waiting for the high priest to come down from the mountain with the corrected YAML files.

I think about Ella K.-H. sometimes when I see these ‘rockstars’ in action. Ella K.-H. is a vintage sign restorer I met in a dusty workshop in the industrial district. She spends her days hunched over 1959 neon tubes, breathing in the smell of ozone and old glass. She once told me that the most beautiful signs are the ones where the original craftsman left a ‘map’ inside the housing-small, handwritten notes on the transformers or clear labeling on the wiring. She said the ‘ego-driven’ restorers were the worst; they’d use proprietary gas mixes or weird, unlabelled soldering techniques that made it impossible for anyone else to fix the sign fifty years later. They wanted to be the only ones who could make it glow. Ella K.-H. hates those people. She sees them as vandals of the future. In our world, the 9x engineer who writes ‘clever’ code that no one else can touch is just a digital vandal with a high-speed internet connection.

We often mistake speed for velocity. Speed is how fast Marcus can push a fix. Velocity is how fast the entire team can move over 29 consecutive sprints. When Marcus is the only one who can push the fix, the team’s velocity is zero whenever Marcus is asleep, on vacation, or-heaven forbid-decides to take a job at a competitor for an extra $19,000 a year. We’ve built a cult of personality around a bottleneck and called it ‘leverage.’ It’s the ultimate contradiction of the tech world: we claim to love scalability, yet we build systems that are entirely dependent on the unscalable brain of one exhausted human being. I’ve made this mistake myself. I once spent 19 hours straight rewriting a database migration because I thought I was the only one who could ‘get it right.’ All I did was ensure that for the next 9 months, I was the only one getting paged at 2:39 AM when the shards acted up. It wasn’t a badge of honor; it was a self-inflicted wound.

Knowledge Hoarding is Technical Debt

True excellence in engineering isn’t about being the smartest person in the room; it’s about making the room smarter. It’s about the engineer who spends 49 minutes writing a clear README so that a junior dev doesn’t have to spend 9 hours guessing. It’s about the person who intentionally steps back during a crisis to let someone else drive the terminal, offering guidance instead of taking the keyboard. This is where the real competitive advantage lies. Organizations that thrive are the ones that distribute expertise so thoroughly that the ‘Bus Factor’-the number of people who can be hit by a bus before the project dies-is higher than 1.9. This requires a shift in how we hire and how we integrate talent. We need to look for people who see their code as a gift to their future selves and their colleagues, not as a barricade to protect their job security.

This is why I’ve started advocating for the embedded team model. Instead of having a single ‘hero’ who floats above the project like a bored deity, you need teams that are deeply integrated, where the ‘senior’ talent is measured by how quickly they make themselves redundant in a specific domain. The goal is to create a mesh of competence. I’ve seen this work effectively when companies invest in qa automation outsourcing, where the focus is on providing talent that doesn’t just fill a gap but actually integrates into the existing culture to strengthen the whole structure. It’s about adding nodes to the network, not just making one node bigger and shinier until it inevitably burns out under the 3:19 AM pressure.

I caught on to this reality when I was looking at a particularly gnarly piece of legacy code that had been touched by 29 different people over 9 years. You could see the layers of ego in the comments. You could see where the ‘geniuses’ had come through and replaced readable logic with bitwise operations that saved 9 milliseconds of execution time but cost 99 hours of developer frustration. It was a cemetery of cleverness. If those engineers had been half as smart as they thought they were, they would have written code that was so boring, so obvious, that even a sleep-deprived junior could fix it. Boring is stable. Boring is scalable. Boring means I get to stay asleep when the staging environment flakes out.

The Silence of the Sideline

There is a specific kind of silence that follows a Marcus-style save. It’s not the silence of a job well done; it’s the silence of a team that has been sidelined. When the leader swoops in, the message is clear: ‘You weren’t fast enough. You weren’t smart enough. Move aside.’ That kills morale faster than any 9 percent pay cut ever could. It creates a culture of learned helplessness. People stop investigating bugs because they know Marcus will ‘teleport’ in and do it anyway. They stop suggesting architectural changes because ‘that’s Marcus’s territory.’ We end up with a team of 19 talented people who are mentally checked out, while one person is on the verge of a nervous breakdown. It’s an absurd way to build a company, yet we see it in $900 million startups and Fortune 499 giants alike.

We have to stop rewarding the 3:19 AM heroics. We need to start asking ‘Why was Marcus the only one who could do this?’ during every post-mortem. We need to celebrate the engineers who write the documentation, who mentor the newcomers, and who build tools that make it impossible for their coworkers to make mistakes. Ella K.-H. doesn’t just restore signs; she teaches her apprentices the ‘feel’ of the glass so that the craft survives her. My dentist doesn’t just drill; he tells me (through the cotton) how to brush so I don’t have to see him again in 9 months. We should be doing the same. If your best engineer is also your biggest bottleneck, you don’t have a talent problem-you have a design flaw. And no amount of late-night Slack messages can fix a foundation that’s built on the fragile ego of a single ‘rockstar.’ The light should belong to everyone, not just the one holding the transformer.

What happens to your roadmap if your hero decides to finally go to sleep?