I manage three engineering teams. My stated goal this quarter, the one I actually care about, is helping each of them stand on their own feet. Engineering capability, management maturity, the confidence to make decisions without looking upstairs first.

I’ve been saying this for months. And then one week in early April, it happened. Not with a celebration or a milestone review. I nearly missed it entirely.

The evidence arrived in a pile

It started on a Friday. I was working from home, not particularly paying attention to what my teams were doing. When I finally checked in on Monday morning, I found a trail of things that had happened without me.

One team had handled a leadership transition cold. Their squad lead had gone on paternity leave, and within days the new person was assigning reviewers, sharing reference implementations, and running the show. No escalation. No velocity drop. Nobody asked me what to do.

The same team’s frontend chapter had volunteered, unprompted, for a Node version migration. Someone offered their personal dev day time for pair work on it. They’d self-organised a knowledge-sharing session for AI coding tools. Bottom-up, no mandate. Separately, they’d run a full quality sprint: accessibility hardening across 49 files, 35 new tests, CI restructuring, and a compromised dependency patched. Nobody told them to.

I scrolled through Slack channels for twenty minutes trying to find a single place where someone had asked for my input. Nothing.

And it kept going

A second team, smaller and younger, had started adopting conventional commits. Their own initiative. In the same week, one of the engineers had taken a brainstorming idea from a sprint retro, where they’d discussed using AI to learn from past PR review comments, and turned it into a working prototype. A PR review tool that learns from how the team actually reviews code. Built outside the sprint. Nobody asked permission.

The same team’s lead, someone I’d been coaching for months on everything from sprint planning to managing up, conducted his first technical interview. He spotted an angle from the candidate’s CV and probed it in real time. Prepared beforehand without me telling him to. I sat there thinking: I’d be comfortable handing him the next one.

And then the sharpest signal of all. My third team, the one with no team lead (we haven’t hired one yet, and I manage them directly), received 20-plus edge-case review comments from a senior stakeholder on a complex integration PRD. Batch processing limits, cursor behaviour on failure, deduplication logic, rehire scenarios. The kind of detailed scrutiny that typically sends people running for cover.

Their principal developer answered every single question. Clear technical depth. No escalation to me. The team with the least structural support produced the most independent response under the most pressure.

The shift I almost couldn’t see

Here’s what I wrote in my notes that week: “The constraint has shifted from what they can do to the room they’re given to do it.”

I’d been so focused on building capability (teaching, coaching, pair-programming, reviewing) that I’d missed the inflection point. My teams weren’t struggling to make good decisions. They were struggling to find the space to make them, because the organisation around them kept pulling them into meetings, ad-hoc requests, governance theatre, and, let’s be honest, my own involvement.

This is the kind of realisation that sounds obvious when you write it down. It was not obvious while I was living it. For months, my internal narrative was: “my teams need me to grow.” The evidence was saying something different: “your teams are growing. You are the constraint.”

What the silence wasn’t telling me

The first version of this post stopped there. Clean arc, satisfying landing. Then I went back and looked at what else happened that week, and the story stopped being clean.

The Node migration that first team had volunteered for? It was real work, started enthusiastically, then quietly slipped two sprints. The accessibility work got prioritised because it was visible and clean. The API contract debt they’d been deferring since January wasn’t getting raised, because nobody celebrates cleaning up someone else’s mess.

The third team, the one whose principal developer answered the twenty review comments? Same sprint, their integration roadmap went yellow. Two commitments they’d made to other teams slipped quietly. The visible win got raised. The invisible miss didn’t.

Capability showed up in places we were watching. Accountability went quiet in places we weren’t. And because nobody was watching, including me, the pattern had nowhere to land.

The teams hadn’t stopped needing me. They’d stopped needing me on the bright side of the road. The dark side was where I should have been looking, and I’d been so busy applauding the autonomy I hadn’t noticed I’d traded one bottleneck for a quieter one.

The competence trap

Around the same time, I was having coaching conversations with two of my leads about something I’ve started calling the competence trap.

One of them, covering for a colleague on leave, was answering support DMs within minutes, jumping on customer issues after hours, catching QA gaps her team missed. She was excellent at it. And that was exactly the problem.

Every fire she put out was a fire her team never learned to handle. Every DM she answered was a DM that trained the sender to keep bypassing the process. Every time she caught a gap, she removed the feedback loop that would have taught someone else to catch it first.

I told her: “The more you firefight, the less anyone learns to prevent fires.”

She knew this. She’d heard me say it before. She still couldn’t stop. Because when you’re competent and you see something going wrong, every instinct in your body says fix it. The gap between knowing you should step back and actually doing it is wider than anyone admits.

I had the same conversation, different flavour, with another lead who was absorbing chaotic product requests rather than pushing back. He had the skills to handle them. That was the trap.

And then I gave myself away. Earlier that week, I’d quietly rewritten part of a release plan one of my teams had drafted, because I “just wanted to clean it up.” Nobody asked me to. Nobody saw the original. I was giving this advice while caught in the same trap, on the same week, in the same building.

The fires I was putting out were lessons everyone else skipped learning.

What nobody tells you about building autonomous teams

The standard advice goes: delegate more, give context not instructions, set constraints not methods, define the end state and let them find their own path. All of which is correct. None of which prepares you for how it feels when it works.

It feels like loss. Not the dramatic kind. The quiet kind. The kind where your calendar gets a little emptier and you’re not sure what to fill it with. Where you read a Slack thread and realise your input would have been fine but unnecessary. Where the team makes a decision you would have made differently, and it turns out their way was better.

A colleague told me once that the goal of a manager is to make yourself redundant. I always thought that was a nice metaphor. I didn’t expect it to feel so literal. And I didn’t expect to need entirely new ways of watching for the things that go quiet when no one’s looking.

What I’m still learning

I’m writing this about two weeks after that week. The coaching conversations continue. The teams continue to grow. I continue to fight the urge to be useful in ways that are no longer useful.

What I do know: the first time one of my engineers independently answered twenty questions from a senior reviewer without looking my way, I felt something I didn’t expect. Not pride, exactly. Something closer to relief. Like I’d been holding my breath for months and someone finally told me I could exhale.

The teams are standing on their own feet. My new job, the one I’m still learning, is watching for the places they stand without looking down.