A recent weekly status update with one of my engineering managers (let's call him Stefan).

Me: "So, after reading this cool article, we've spent the last few weeks fixing our clarity and focus - clear goals, clean pipeline, no distractions. We should be flying by now."

Stefan: "We should be, but we're not. Main project is weeks behind, and we can't even kick off the next one."

Me: "It doesn't sound good. What's the holdup?"

Stefan: "We're actually making solid progress on our end, but we're stuck waiting for the X team to finish their API."

Me: "Okay, what's blocking them?"

Stefan: "Nothing is blocking them. They promised it last week, but they're swamped with their own stuff. So we... wait."

Me: "Can't we at least release what we have?"

Stefan: "Sure, but that'll take about two weeks."

Me: "Two weeks? For a release?"

Stefan: "Well, it's production, so we need approval from the infra team. Since we don't have production access, they have to run manual operations for us. And they're..."

Me: "Let me guess - also busy?"

Stefan: "Yep. Plus, we need a new database, which means involving the data team. And don't get me started on the QA review process."

Me: "Wait, manual operations? In 2025?" sighs "What about our second project then?"

Stefan: "We're waiting for the architecture committee to meet again - that's next month. And our UI design is still sitting with the Chief Design Officer for approval."

Me: "Hold on. We fixed our focus, we know exactly what to build, our team is motivated... but we still can't actually do anything without asking for help from half the company."

That's when it hit me - we had Clarity, we had Focus, but we were still completely dependent on everyone else. We were missing the third piece of the puzzle: autonomy.

So Stefan and I started digging into this. What does it take to make a team autonomous?

What Does an Autonomous Team Actually Look Like?

What makes a team autonomous? In corporate terms, an autonomous team owns the full value stream. The value stream is all the activities related to designing, developing, delivering, and maintaining a specific business domain within a company.

In simple terms, autonomy boils down to this: can your team actually ship stuff without asking half of the company for help?

In reality, no team is ever 100% autonomous. Some dependencies are inevitable.

The trick is getting as close to that 100% mark as possible. The closer you get, the faster your team moves. Stay too far from it, and you're trapped in Stefan's grim world of endless handoffs and waiting.

Alright, How Do We Fix This?

Own Your Whole Domain

Stefan's team was building features but had zero control over the APIs they depended on. Every handoff between his team and the API team turned into a frustrating game of miscommunications, mismatched timelines, and conflicting priorities.

It's a pattern I see way too often. Teams that only own part of the system spend weeks coordinating with others. Teams that own the whole thing? They just built it. Once we had given Stefan's team full control over their stack, they went from weeks-long delivery cycles to daily deployments.

But the real game changer was not about timelines. When Stefan's team started owning their whole domain, their mindset shifted completely. Before, they optimised for their slice of the work. Now they optimise for what actually matters: shipping products that work. No more "not our problem" excuse.

Getting the Right People in the Room

For Stefan's team to own more, they needed to be able to actually work with it. His team was mostly frontend engineers - great for UI work, but they couldn't touch the backend APIs they needed.

We had a few options: reduce their scope, add backend people to the team, or train the existing engineers to be more full-stack. We ended up doing a mix of all three. Some specialised roles, like SRE support, we shared across teams, which created its own coordination challenges, but it was still an improvement.

Pro tip: if you find yourself needing the same rare technical skills across multiple teams, that's usually a sign you need a platform team to abstract away that complexity.

Give Teams a Solid Platform To Build Upon

Speaking of platform teams - this was a game-changer for us. Instead of having every team figure out database provisioning, deployments, and monitoring from scratch, we've tasked a dedicated platform team with building self-service tools and APIs.

For Stefan's team, this meant they could spin up new environments, deploy code, and monitor their services without waiting for the infrastructure team. The platform team handled the complex, low-level stuff, and Stefan's team could dedicate their full attention to building amazing product features.

A popular X-As-A-Service pattern is also something you can consider to reduce coupling between the teams.

When Dependencies Are Unavoidable, Make Them Painless

Some dependencies are just part of reality. But Stefan's team was spending more time in meetings about dependencies than actually resolving them.

For the dependencies that we could not eliminate, we had to find ways to handle them without compromising Stefan's team's efficiency and autonomy.

We started treating documentation like a first-class product. On a company level, we introduced a requirement for all the services to expose their data and functionalities via well-designed APIs. As described in the famous platform rant, a robust API layer will allow your teams to exchange data and services easily, at the same time keeping services loosely coupled.

We also implemented an RFC process where teams could share their technical decisions and ask for feedback without endless committee meetings.

Those changes allowed Stefan's team to stop scheduling meetings every time they needed something from another team. Just check their docs and use their APIs to get what you want.

Let Them Actually Do Stuff

Stefan's team could build features, but couldn't deploy them without going through the weeks-long orchestration process of various support requests and approvals. They were like race car drivers who had to ask permission to press the gas pedal.

We needed to change that.

Every team should be able to ship their work without asking anyone for permission. Need to deploy? Go, deploy. Need to provision a database? Provision it. Need to check production logs? No hay problema.

But after talking with our infrastructure and security teams, I realised that it's not that easy. We had legal and compliance obligations and security audits to consider. And people make mistakes. What if they nuke the production?

We don't want to lock everything down. But we cannot naively remove all restrictions and hope for the best.

Instead, we gave them the right tools to do things safely. Self-service deployment pipelines that allowed them to deploy without direct production access. Database provisioning APIs that let them create what they needed without touching production infrastructure. Monitoring dashboards that showed them what they needed without exposing sensitive data. Templates and runbooks to help them run things properly.

We made the secure way the easy way.

We kept the truly critical stuff - payments, core user data, critical infrastructure - locked down tight. No touching! But Stefan's team could run experiments and deploy features in their domain without asking anyone for permission.

Trust Them to Make the Right Calls

When teams know every choice will be second-guessed, they stop making choices. Stefan felt that his team worked more like a feature factory than skilled problem solvers. This approach was pushing them into a passive, disengaged mindset. "I'm just a code monkey; they give me a ticket and I code." Terrible waste of their talent.

Did you know that the effectiveness of the US Army is frequently attributed to its philosophy of empowering lower-level officers to make tactical decisions close to the action? I say, let's learn from the best!

We needed to move away from giving them tickets and start giving them problems to solve. Instead of "build this login form", we asked them to "reduce signup friction by 30%" See the difference? We empowered them to solve the problems. No more code monkeys. We wanted Product Engineers.

Real autonomy requires teams to be able to make decisions on how they work. Pick their technical solution, prioritise features or pivot their approach based on users' feedback without running it by five different committees.

The results? Stefan's team started making better decisions because they owned the consequences. And the few times they made a mistake? Usually, it turned out fine, and when it didn't, they learned fast and improved.

And I learned to trust them more. I had to accept that teams will sometimes choose differently than I would. Sometimes they'll pick tech I wouldn't have chosen, or prioritise features I think are less important. But often their decisions proved to be better than mine! And they were much more engaged and motivated to deliver the solutions they've designed. That's the power of empowerment!

What I needed to do was set clear guardrails, then get out of the way and let them grab the steering wheel.

We Still Need to Stay Aligned

Now Stefan's team was moving fast and making their own decisions. Which was great, until I started lying awake wondering: are they building what we actually need? They might deliver a beautiful Ferrari, but what if we needed a pickup truck?

Setting Clear Boundaries Without Micromanaging

I needed to get very specific about what I cared about - budget limits, security standards, our target architecture, compliance requirements - and I got all that written down as official non-functional requirements that everyone has to comply with.

Even better, we automated as many guardrails as possible. Our CI pipeline caught security issues automatically. Our deployment templates enforced standards out of the box. The goal was to make it nearly impossible to cross the boundaries while giving Stefan's team total freedom inside them.

We've also killed most of our approval committees. They were just slowing everything down and turning technical decisions into political battles. Either write the concrete rules down, or let people decide.

Make Sure They Know What Success Looks Like

Sailors famously used stars to find their way in the vast ocean.

Our teams needed a North Star as well - a shared, long-term goal that told them what success looked like.

Zuckerberg famously nailed this when he set Facebook's North Star as Monthly Active Users. Not registered users (easy to game), not page views (misleading) - active users who actually showed up every month. Suddenly, every product decision had a clear filter: Does this get more people using Facebook regularly? Teams could easily benchmark this idea against a simple question: Is this helping us reach the North Star?

That's what a good North Star does - it turns a thousand tiny decisions into obvious choices.

My job was to make our North Star impossible to ignore - putting it in teams' docs, referencing it in code reviews, bringing it up in standups, plannings and all-hands.

When Stefan's team could recite our goals if woken up in the middle of the night, I knew we were aligned.

Keep Tweaking Until It Works

I did not nail all those changes in a single take. That's impossible.

I've started with Stefan's team. They were my guinea pigs for autonomy experiments. We've experimented with what works and what doesn't.

Only once we saw the positive change, we started applying this framework to other teams.

The key was making this an ongoing conversation. In our retrospectives, I started asking, "What's still blocking you from moving fast?" Stefan's team told me exactly where our process was broken - I just had to listen and act on what they said.

Stefan's team went from two-week release cycles to same-day deployments. They went from waiting on five different teams to owning their entire feature pipeline. Most importantly, they went from feeling frustrated and blocked to feeling empowered and accountable.

They could finally move fast and make full use of their talents. And I learned to trust the people I had hired.