Here's what I hear from leaders a lot: "We want teams to move faster, but every time we give them more autonomy, something breaks. So we add more process, more checks — and now everyone's complaining about bureaucracy and we're even slower."
Sound familiar? The answer probably isn't more gates. It's definitely not endless approval cycles. The answer is platform engineering with the right guardrails — and that's exactly what I want to walk you through today.
Why Organizations Get Stuck: The Mummy Problem
Most organizations I visit feel like they're wrapped in mummified, ossified, calcified process control systems. When I ask why, the answer is almost always the same: something bad happened. A postmortem was run. Gates and checks were added. And then — like a bandage that never gets removed — those controls just stay.
How often do you get a cut on your hand and never remove the bandage once it heals? That's what's happening in most organizations. We keep adding protection but rarely revisit whether we still need it. We're walking around like mummies.
What's Actually Happening on the Ground
Your best teams are waiting. Waiting for infrastructure. Waiting for security reviews. Waiting for someone in another department to provision an environment — or worse, approve a deployment.
Meanwhile, leadership is nervous. They see teams shipping code but have no clear visibility into whether it's secure, stable, or following basic standards. So they do what any reasonable leader would do — they add controls, gates, and approvals.
Now you have the worst of both worlds: teams are slow, and leaders still don't trust the system.
The problem isn't that teams need less freedom or that leaders need more control. The problem is that we're trying to solve a flow problem with governance. When you constrain the wrong things, you create queues. When you create queues, cycle time blows up. And when cycle time blows up, trust erodes shortly after.
The solution isn't more meetings or checkpoints. It's better constraints in the right places.
What Is a Platform, Really?
The Cloud Native Computing Foundation defines it well in their white paper: a platform is a curated set of capabilities that reduce cognitive load and enable stream-aligned teams to deliver value with minimal friction.
In plain terms: a good platform gives your teams a paved path. They don't have to reinvent deployment pipelines. They don't have to figure out observability from scratch. They don't have to negotiate with six teams to get an environment spun up. The platform team makes the right way the easy way.
Team Topologies describes the difference between platform teams and stream-aligned teams well. Platform teams exist to accelerate stream-aligned teams — not control them. They're there to remove friction.
Most organizations miss this critical distinction. They think of platform teams as the teams that build common elements extended by other teams. That's not the same thing. Platform teams enable product teams. And the best platform teams don't just provide self-service tooling — they also embed guardrails that keep teams within safe boundaries without requiring human approval for every decision.
Think of It Like a Highway
You want cars to move fast, and you also want them to stay in their lanes and not drive off a cliff. You accomplish that with lane markers, guardrails, and banked curves — not with a toll booth every quarter mile where someone asks to inspect your vehicle. That would be very slow, and you'd never get where you need to go.
Influencing Self-Managing Teams: The CDE Framework
Agile calls for self-managing teams, which is the right call — but I've noticed that managers often get paralyzed by that idea. If you can't control teams, how do you shape outcomes?
I've found a great resource in Glenda Eoyang's CDE framework, developed through her work in complexity and adaptive systems. CDE stands for Containers, Differences, and Exchanges — and it explains how to subtly influence self-organizing systems without controlling them.
Containers
Containers hold the system together. They set the boundaries, identity, and purpose. Your platform defines the container. For example: all services must deploy through a specific pipeline. That's a container — it defines a boundary, but inside that boundary, the team has freedom.
Differences
Differences create diversity. Think cross-functional teams. In platform thinking, this means accommodating a variety of skills, team structures, and problem spaces. A data science team has radically different needs than a web front-end team. Good platforms handle that difference without forcing everyone into the same box.
Exchanges
Exchanges are how information and resources flow through the system. Platforms control these exchanges by deciding what's self-service, what's automated, and what requires coordination. Want teams to move fast? Make exchanges frictionless. Want them to stay safe? Embed policy into the exchange itself.
The key insight: you don't control teams by telling them what to do. You shape their behavior by changing their containers, differences, and exchanges. Your delivery system is a complex system — and complex systems respond best to thoughtfully placed constraints, not command and control.
Five Examples of Good Guardrails
1. Automated Policy Enforcement at Deployment Time
Instead of a security review that takes two weeks, the platform runs automated checks. If a container has critical vulnerabilities, it simply doesn't deploy. No ticket. No meeting. Just a clear signal and a link to fix it.
2. Default Observability Baked Into Every Service
Every new service gets logging, metrics, and tracing automatically. Teams don't opt in — they get it by default. They can customize it, but they can't accidentally ship something invisible in production.
3. Progressive Delivery With Automatic Rollback
Instead of requiring a change advisory board to approve every release, the platform enables canary deployments with automatic rollback on error rate spikes. Teams can ship confidently because the system itself prevents a blast radius.
4. Work-in-Progress Limits on Active Experiments
Unlimited experiments create queues everywhere. I worked with a team that capped active feature branches at three. If you want to start something new, you finish or kill something old. That forces prioritization without requiring management approval for every decision.
5. Self-Service With Embedded Compliance
Instead of a manual security review for every infrastructure change, the platform provides pre-approved Terraform modules. Teams compose what they need. Compliance is embedded. Speed goes up, risk stays low.
The pattern is consistent: good guardrails automate the enforcement of standards. Teams are still free to do what they want — the platform just makes it easy to do the right thing and hard to do the wrong thing.
Five Examples of Bad Bureaucracy
1. Manual Approval for Every Deployment
If deploying to production requires three sign-offs, you've created a queue — and you've trained people to batch up changes, which increases deployment size and risk. If you need a human to approve every deploy, your system probably isn't safe enough, and the process is making it worse.
2. Requiring Detailed Design Documents Before Any Code Is Written
Big design upfront doesn't reduce risk — it just moves ignorance around. Requiring a 20-page architecture document before a team can start an experiment optimizes for the appearance of control, not for learning. Design matters. Architecture review boards that slow teams to a halt do not.
3. Infrastructure Provisioning With a Two-Week Lead Time
I worked with a team where getting a new test environment took 14 days — a ticket, an approval, a handoff. That's not a guardrail. That's a bottleneck disguised as governance.
4. Mandating Specific Tools With No Flexibility
If your platform says you must use Tool X for everything, and Tool X doesn't solve the team's actual problems, you've just created shadow ops. Teams will work around you. Now you've lost visibility and slowed them down at the same time.
5. Requiring Executive Approval for Small Experiments
If a team wants to test a hypothesis affecting 5% of traffic for three days and needs a VP to sign off, you have a decision-making problem. Psychological safety dies when small bets require big approvals.
The core distinction: guardrails are automated and local, and they trust the team. Bureaucracy requires humans and slows the flow.
A Practical Playbook: How to Actually Build This
Step 1: Identify Your Top Three Bottlenecks
Where are teams waiting? Is it infrastructure provisioning? Security reviews? Code reviews? QA? Pick the top three based on cycle time impact.
Step 2: Replace Manual Gates With Automated Policy
For each bottleneck, ask: what standard are we trying to enforce? Can we automate that check? If yes, build it into the platform. If no — you might not actually have a standard. Evaluate carefully.
Step 3: Make the Paved Path the Default
Your platform should provide golden paths for common workflows — deployment, observability, secrets management, data access. Make these self-service with guardrails baked in.
Step 4: Think CDE
What is your container? What differences in skills do you need to accommodate? How does information exchange or flow through the system? When you design your platform, you're shaping those three conditions whether you realize it or not. Be intentional.
Step 5: Measure Lead Time and Change Failure Rate
These are straight out of the DORA metrics. If your guardrails are working, your team should be deploying faster and more reliably. If lead time is slow or change failure rate is high, your guardrails are either too loose or too tight.
Step 6: Constrain Work in Progress, Not Decisions
You don't need to approve every decision. You need to limit how much active work is in flight at a time. Cap active projects, open feature branches, and backlog size. WIP constraints help teams finish before they start, improving flow without requiring gatekeepers.
The Truth About Autonomy and Guardrails
Autonomy without guardrails is chaos. Guardrails without autonomy is bureaucracy. You need both.
Great platforms give teams the freedom to move fast by making safety automatic. They replace human gates with automated policy. They replace waiting with self-service. They replace fear with feedback. And they do this not by eliminating constraints, but by putting the right constraints in the right system.
If you want to go deeper, I'd recommend two resources: the Cloud Native Computing Foundation's white paper on platforms (including their maturity model and roadmap), and Team Topologies by Matthew Skelton and Manuel Pais. Both are worth your time.
Your Challenge for This Week
Pick one manual approval process that's slowing your team down. Ask yourself: what standard are we trying to enforce? Then figure out how to automate the check and eliminate the gate. I think you'll be surprised how much speed you unlock when you stop confusing process with protection.
Ready to Go Deeper?
If this sparked some ideas about how to redesign your delivery systems, Big Agile's courses can help you take the next step. Whether you're working toward becoming a certified Scrum Master, advancing your agile coaching practice, or developing a platform engineering mindset across your organization, there's a class designed for where you are right now.
Explore Big Agile's full course catalog and find the right path for you and your team.