In praise of operators: the teams nobody celebrates keep your business running

I recently sat down with a longtime client — the technology SVP at a national marketing-technology company — for our podcast. We covered a lot of ground, but the part I keep coming back to is a conversation about the teams nobody writes LinkedIn posts about — the ones maintaining the platforms that aren’t new, aren’t exciting, and absolutely cannot go down.

We call these folks operators. Every org chart has them, and every business depends on them. You and I are old enough to remember the Dunkin’ Donuts “time to make the donuts” commercial… you need that guy. The one who shows up every day and makes the donuts. That is a terribly important role, and it’s chronically undervalued.

Your A-players are going to leave. Plan for it.

He said the quiet part out loud, and I think every leader running a legacy platform needs to hear it:

“You have to recognize that a lot of people who think ‘okay, this is getting sunset, this is less interesting’ — they will eventually move on. Some of the people who stay behind are not necessarily your A-plus players… and as leaders, we have to recognize that.”

That’s not cynicism. It’s planning reality. The hotshots chase the new thing; that’s what makes them hotshots. The people who stay on the stable platform are steady, reliable, nine-to-five professionals. And here’s the part most executives miss — he didn’t:

“They know what they’re doing. They probably cause you the least amount of headaches. It takes the least amount of your problem-solving skills. There is something to be valued on these teams, and you need to show that.”

Think about your own week. How much of your leadership attention goes to the team that never pages you at 2am? Probably none. That’s exactly backwards from how those teams experience it — invisible until something breaks, then suddenly very visible.

The counterintuitive part: legacy teams have more tacit knowledge, not less

Here’s the trap. Because these platforms are stable and these teams are quiet, everyone assumes the knowledge is written down. It isn’t.

“You end up finding out the documentation’s out of date or missing, because the teams have been working on something for a decade and they didn’t even realize. There’s more tacit knowledge on these teams, not less. And I think that’s counterintuitive.”

I’ll add my own version of this: drift on a high-velocity team is easy to spot — that’s scope change, that’s “not what we agreed to last sprint.” Drift over a ten-year window is invisible. It’s the small thing changed on a Friday afternoon that was going to get documented Monday and never was. Or as he put it, it was documented Monday — Monday, October 3rd, 2014. Good luck finding it.

Compounded over a decade, that’s how a company ends up with core systems that live in two or three heads. If you’ve read our piece on what technical diligence examines, you know exactly how that shows up when a buyer looks at your business: key-person risk, priced in dollars.

What good leadership looks like here

Three things, all from the conversation, all cheap to do and rarely done.

Be the cheerleader on purpose. The team that keeps the lights on needs to hear that “the lights are on” is valued — in words, in incentives, and in your visible attitude toward their work. Connect them to the business value they protect.

Staff one ahead. When someone retires off a legacy team, replacing that tacit knowledge is brutal. His rule: carry at least one more person than you think you need, so knowledge transfers before it walks out the door, not after.

Make documentation the project. These teams have capacity precisely because the platform is stable. Pointing that capacity at writing down what only they know is the cheapest insurance your technology function will ever buy.

The test

Pick the oldest revenue-critical system in your company and ask two questions. Who actually understands it? And if that person resigned tomorrow, what happens?

If the answers are “one person” and “we’re not sure,” you don’t have a documentation problem. You have a single point of failure wearing a badge. We’ve stepped into exactly that moment more than once — a migration where discovery itself was the project — and it’s fixable, a lot more cheaply before the resignation letter than after.