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.