Why Lean Teams Can’t Afford to Operate Without Structure, or More Accurately: Guardrails

There’s a conversation that happens in almost every small, growing company at some point. 

Someone suggests introducing a bit more structure — a consistent way of handing off work, a checklist before a customer goes live, a rhythm for how decisions get made. And inevitably, someone else pushes back. 

“We can’t have too much process. It will slow us down. We need to stay agile.” 

It’s an understandable reaction. And it’s worth taking seriously — because they’re not entirely wrong. 

When Process Really Is the Problem 

Early in my career I worked on the ESA Rosetta mission. For those unfamiliar, Rosetta was a spacecraft that travelled for ten years through the solar system to rendezvous with a comet, deploy a lander, and study the comet on its journey through the solar system. A genuinely once-in-a-lifetime mission. 

The operational frameworks supporting it were appropriately ambitious. Volumes of procedures. Rigid, layered processes. Extensive documentation for every conceivable scenario. 

And even then — with all of that structure — we still had to think on our feet. The unexpected still happened. No amount of documentation eliminated uncertainty. 

For a mission of that complexity, scale, and consequence, that level of procedural rigor made sense. It was a capstone achievement involving international teams, decade-long timelines, and zero opportunity for a do-over. 

But that model doesn’t carry over to a scale-up running on a shoestring budget, moving fast, and needing to stay flexible. Importing institutional-grade process into a lean environment doesn’t make you more reliable. It makes you slower — and it creates the very overhead people feared in the first place. 

So the resistance isn’t irrational. It’s a reasonable response to having seen — or imagined — the wrong kind of structure. 

The question is whether that’s the only kind. 

What Happens Without Any Operating Rhythm 

Here’s what I’ve observed when growing teams avoid structure entirely in the name of staying lean. 

A team completes a piece of work and considers it done. On the receiving end, another team isn’t aware that something is required of them before the new capability can be used. The gap between those two assumptions goes unnoticed until it surfaces in front of a customer — at which point what should have been a routine transition becomes a costly and disruptive correction in live operations. 

Or this: a team is confident a capability covers what a customer actually needs. They’ve tested it. It works. But the testing followed the happy path — how the system is supposed to work, in the most basic case. The subtleties of how the customer actually operates weren’t explored. The gaps only surface after go-live, during real usage, under real conditions. At that point, the customer experience suffers and trust takes a hit. 

In both cases, the problem wasn’t capability. The teams were competent and well-intentioned. The problem was the absence of a shared operating rhythm — a lightweight, agreed way of moving work from one team to the next, of checking that what was built actually meets what was needed, of ensuring nothing important falls through the gap between departments. 

That’s not bureaucracy. That’s just coordination. And without it, the cost shows up in the places that hurt the most: customer experience, team morale, and time lost fixing things that should have worked the first time. 

The Distinction Worth Making 

Heavy procedural volumes and lightweight execution structure are not the same thing — and conflating them is where a lot of growing teams go wrong. 

One is designed for institutional-scale missions with decade-long timelines and international oversight. The other is a set of guardrails — just enough structure to keep work moving in the right direction, without telling people how to think or removing the flexibility to adapt. 

Guardrails don’t slow you down. They give you a safe track to move fast on. 

An operating rhythm doesn’t mean rigid process. It means the team has a shared understanding of how work flows, who owns what, and what “done” actually looks like before it reaches the customer. 

The goal isn’t to document everything. It’s to align on the things that matter — and make them repeatable. 

Starting Light 

The good news is that useful execution structure doesn’t have to be complex to be effective. 

A simple handoff checklist between teams. A lightweight review before a customer goes live. A shared definition of what readiness actually means. 

These aren’t bureaucratic impositions. They’re the difference between a team that moves fast and occasionally breaks things badly, and a team that moves fast and catches the important things before they become customer problems. 

Start with what causes the most friction. Build just enough structure to address it. Go only as far as is useful, and no further. 

That’s the version of structure worth having. 

Interested in applying this framework to your next go-live? I'm developing a practical preparation toolkit based on mission operations methodology — built for teams that need operational rigor without the overhead. Get in touch if you want to be notified when it launches!