Systems, Stables and Stars

You know how large organizations with very mature systems and talent distribution still end up pulling in the same top 5 or 10 people to work on their most pressing problems?

I’ve watched this at Google, at Atlassian, at pretty much every well-run company I’ve observed closely. These places have incredibly sophisticated performance frameworks, coaching programs, design systems, review processes. They’ve invested years into building cultures where the average quality bar is high and talent is supposedly evenly distributed across their teams.

And yet. When something orbit-shifting comes up, a decision that could reshape their trajectory, a gnarly opportunity they need to nail, leadership doesn’t just route it through the normal channels. They call the same handful of people. Every single time.

Wouldn’t a mature team with mature processes and mature systems let leadership pick anyone for the job and it should just work? Isn’t that the whole point of building scalable systems, that you abstract out individuals and get consistent, high-quality outputs regardless of who’s working on what?

But it doesn’t work that way. Even with all those systems in place.

For the longest time, I assumed this pattern in my own team meant I was failing as a leader.

Whenever something critical came up, a tough technical decision, a strategic bet that could reshape where we were headed, I’d find myself reaching for the same people. It didn’t matter what their official assignments were. When it really mattered, I went to my rockstars.

I’d bought into the promise that with the right frameworks, coaching, and processes, you’d get a flat, talented team where anyone could step up to any challenge. But no matter how much I invested in building those systems, when the big stuff came up, I couldn’t just hand it off and trust the outcome. I had to keep pulling in the same handful of people.

I thought this was on me. I wasn’t coaching effectively enough. I was taking shortcuts instead of properly developing the broader team. Then I started paying closer attention to how things actually worked at the companies I respected, and I realized: oh, everyone does this.

Two different jobs

Raising the floor and raising the ceiling are completely different problems that need completely different solutions.

Systems raise the floor. They ensure consistent quality on routine work. They make you resilient to turnover. They let you handle the predictable stuff at scale. This matters a lot, most work falls into this bucket, and doing it reliably is enormously valuable.

But star performers raise the ceiling. They handle the novel stuff, the ambiguous stuff, the stuff you genuinely haven’t seen before. When you’re facing a problem your systems haven’t encountered, when the stakes are asymmetrically high, when you need both speed and quality, you’re not looking for someone who can follow the playbook. You’re looking for someone with exceptional judgment, pattern recognition across domains, ability to synthesize under uncertainty.

The highest-leverage work almost always resists systematization. If you could solve a problem with a framework or process, it wouldn’t be high-leverage anymore. It’d be operational.

The free agent model

What makes rockstars different isn’t just that they’re good. It’s that they are capable of operating somewhat outside the normal structure when stakes are really high.

Think about how sports teams use free agents. They’re not bound to a single position or department. They move where the game needs them. That’s how star performers actually work in organizations, whether anyone admits it or not.

Their involvement is demand-driven, not org-chart-driven. When a critical problem emerges, you don’t check who officially owns that area. You ask: who can actually solve this? The answer is usually the same person, regardless of whether it’s technically their domain.

They work across boundaries by default. A star technical leader might suddenly be pulled into a customer escalation because they can synthesize the technical constraints with business reality faster than anyone else. A product leader might get looped into an operational crisis because they understand the second-order effects better. The org chart says they shouldn’t be there. The problem says they should.

They’re not permanently assigned, they’re temporarily deployed. Most people on your team have stable assignments. They own specific areas, specific projects, specific responsibilities. Star performers have that too, but when something high-stakes emerges, they get temporarily reassigned to it. Then they go back. Then they get pulled again for something completely different.

You’re making a deliberate choice: this problem is important enough and novel enough that I need someone who can operate outside the playbook. Formal process would slow this down or dilute the quality. So you route around the system, but only for problems that actually warrant it.

The key is knowing which problems those are. Not every urgent thing deserves a free agent. Most things should go through your systems. But when you’re facing something genuinely unprecedented, something where the cost of getting it wrong is asymmetric, something where you need both speed and exceptional judgment, you don’t force it through standard channels. You call your rockstar, wherever they are, whatever they’re officially working on.

This is honest resource allocation. Your star performers are limited and non-fungible. Using them on problems that systems could handle is waste. Not using them on problems that could change everything is also waste.

Systems and stars

The best organizations don’t choose between systems and stars. They use both, but for different things.

They build robust systems for everything they’ve seen before. These handle quality at scale and create capacity for harder problems. But they also maintain a parallel structure for the unprecedented. When something genuinely novel or critical emerges, they don’t force it through standard pipes. They task their best people with it, often cutting across boundaries, moving them fluidly between high-leverage problems as those problems emerge.

The systems aren’t failing when this happens. They’re doing what they’re designed to do, handling everything they’re supposed to handle, which creates space for exceptional talent to focus on exceptional problems.

I stopped feeling bad about relying on my star performers for critical work. The mistake I was making wasn’t depending on rockstars for the hardest problems. It was either wasting them on things my systems should handle, or thinking I could build systems good enough that I wouldn’t need them for unprecedented stuff.

You can’t make everyone exceptional

You can’t make everyone a star performer. I really wanted to believe I could.

The instinct is to think “I’ll just coach everyone up to that level.” But the people who can operate in high ambiguity, synthesize across domains, make sound judgment calls under pressure, they’re fundamentally sparse. That’s what makes them exceptional.

The goal isn’t to make your entire team interchangeable at the highest level. It’s to accept that star talent will always be non-fungible, and build accordingly.

That means two things: First, you need these people on your team. Not later, not “once we can afford it.” If you’re facing problems that could reshape your trajectory and you don’t have anyone who can operate at that level, you’re hoping for luck. Second, you need to use them deliberately. They’re scarce. Burning them out on routine problems is waste. Failing to deploy them on the unprecedented stuff is also waste.

I’m still building systems for everything I can systematize. I’m still developing my broader team. But I’ve stopped feeling guilty about calling the same few people when something truly matters.