What Moved Without Me?

It’s embarrassing to admit how long I measured my job by tasks crushed and fires put out. How many tickets closed, how many PRs merged by lunch. Six months ago, I was still thinking, “If it looks like a lot got done, then I’m leading well.” But every time I got pulled away—customer meeting, surprise fire drill—progress froze. Teams waited for my input before moving forward. I was running the treadmill, not building the track.

Here’s the reframe that changed everything. Instead of tracking what I shipped, I started looking for signs the team shipped without me. The new question: What kept moving when I didn’t? It felt uncomfortable at first, almost disloyal to productivity itself. But the second I started asking it, I could see work flowing—or not—in ways that never hit my personal to-do list.

What actually signals leverage? Shipping without my check-in. Ownership of a process that doesn’t ping me at every corner case. The week I didn’t review the deployment plan but the launch still rolled out, quietly, and someone else ran the postmortem? That’s progress. Suddenly, I was coaching people to make calls I used to insist on making. Our standup updates changed: less “waiting on review,” more “pushed the fix and closed the loop.” When an engineer takes end-to-end responsibility for a workflow and I don’t have to circle back, that’s when I know the system’s working. My output might be invisible, but throughput compounds.

Freelancers execute. Entrepreneurs invent. The question isn’t just what I did today, but what kept moving when I stepped away. That’s the leadership posture I’m learning to practice now.

Measuring Impact by Movement—Not Output

It took me years, even while aiming to grow self-managing engineering teams, to understand the difference between output—the visible things you do—and throughput, which is what the system delivers no matter who’s pulling the levers. Think of output like hauling buckets of water yourself, while throughput is installing pipes so water keeps flowing whether you’re there or not. Output looks good in a daily report, but it’s brittle. Throughput is what actually scales. This is why tools like the DORA metrics give engineering leads a yardstick for measuring throughput and reliability at scale—speed and quality, tracked side by side. Once I grasped that, my whole approach shifted.

What anchors this scorecard is systems-driven leadership. The real job is to reduce your own necessity. That means deliberately transferring context, belief, and responsibility until someone else owns the decision. What stuck with me most from Godin—is that entrepreneurs don’t scale by doing; they scale by transferring belief and responsibility. That’s your new north star.

You can start simple. Each week, jot down a “Moved Without Me” note in your personal log. List every item that shipped, decision made, or incident resolved that you didn’t directly nudge. Did a feature go live without your review? Did someone else handle a customer escalation? Which tasks got closed while you were heads-down on something else? These are the signals: launches without your step-in, bugs closed without your triage, meetings run with decisions captured and followed up by someone else. I started instrumenting this with a shared doc—week by week, you watch your direct footprint shrink, and the team’s throughput increase.

Name the mindset shift so you remember it. Old mindset: “Where should I step in?” New mindset: “Where should I get out of the way?” Next time you’re tempted to swoop in, pause. See what happens when you don’t. Try it on the next workflow or standup and let yourself become less critical to the machine.

No need to complicate this. Start your scorecard with one line in your notes today. “What moved without me?” That’s the real lever.

Designing Systems to Build Self-Managing Teams That Move Without You

Start by spotting one workflow where you’re still too central if you want to build autonomous teams. Pull up your calendar and look for the repeat “needs lead review” or “waiting for approval” status. Ask yourself: what’s missing that no one’s solving for besides me? For me, it was our build/release pipeline. Every deployment required my signoff, and nobody really knew the whole end-to-end shape but me. Reframing that: if someone else owned the entire process, what would they actually need? Not just tasks, but real responsibility from code merge to rollout, including the “we broke production, now what?” part. Imagine showing up and seeing the system humming without waiting on your intervention.

Now, here’s how you delegate ownership effectively and make sure it sticks. First, name a clear owner—a DRI who fully owns the workflow, not just pieces. Spell out the expected outcomes (“live by noon, rollback in under five minutes if needed”) and set SLAs that measure real business impact, not just completion. Then, document the hand-offs. Who gets what, when, and how much context they need to act. The key is to put a cadence in place. Weekly reviews, postmortems. But not you as the recurring bottleneck. Framing cuts down the back-and-forth cycle, which stabilizes iteration.

Here’s how it played out for our model deployment flow last quarter. I picked the one release workflow that always pinged me for approval. Instead, I handed full ownership—start to finish—to one senior engineer. We built a playbook together: step-by-step guide, guardrails on versioning, checks before push, rollback protocol.

They ran the first couple launches; I listened in but kept my mouth shut unless asked. The second week, something went sideways with a model artifact—but instead of calling me, they followed the checklist we’d published and did the full debug and recovery themselves. No gap. That week, I realized I’d stopped being the safety net by default and became the designer of nets. Looking back, throughput didn’t just continue. It actually sped up. “Moved without me” stopped being an aspiration and started showing up in the team’s progress notes.

To really cement the shift and build self-managing teams, set up clear escalation lanes: who gets called for exceptions, when something breaks, and what the fallback is. Publish the checklists (not just in your private notes) so anyone can run the process. As an experiment, skip the routine review you always “need” to do—see what happens. Direct attention to the system, not your own involvement. The more I removed myself with intention, the more systems and people stepped forward. That’s how compounding impact actually happens.

Try It as a Small Bet (Not a Mandate)

Let me give you three prototypes we’ve tried—each designed to move something end-to-end without my fingerprints all over it. First, a no-check-in release: outline the release steps up front, hand ownership to a clear DRI, and set a simple go/no-go that doesn’t stall waiting for your Slack approval or calendar slot. With this, you should measure if the release shipped on time and how many manual interventions you avoided.

Second, the owner-led standup: pick a day to only observe while someone else runs things—notes, decisions, and blockers—and track how often you need to step in or clarify. Third is a rotating bug triage: set up an on-call playbook (quick checklist, escalation ladder) and let a different engineer pilot it for the week, measuring how many bugs get resolved within your defined SLA, and whether escalations follow the path as planned. A good incident management prototype builds around the core lifecycle—preparedness, response, recovery, and mitigation—to make steps and results tangible, not hand-wavy. Each prototype is meant to stress-test the system, not the people, so everyone gets to see the edges in real time.

How do you know if this landed? By next week, can you answer: did the process finish on schedule, did people make and stick to their own calls without circling back, and did we resolve issues within our SLA instead of waiting for a leader’s nudge? Take a few short notes. If it didn’t go smoothly, what did you learn—and how does the next iteration get easier?

You don’t need permission from above or a big reorg. Just pick one prototype, schedule it for this week, and then—hard, I know—step back for seven days. See what hums along without you.

Addressing the Doubts (and Making It Stick)

Let’s be honest. The setup costs feel real. It does take effort to put guardrails in place, document the critical steps, and make sure someone else can actually drive the workflow. But here’s why that investment pays back, sometimes immediately. When you build a system that runs without your constant touch, you’re effectively giving yourself time back every single day—and, more importantly, every time you get pulled away for a demo, a customer fire, or just an actual day off. Overhead transforms into leverage. It’s a one-time pain for repeat returns. If you’ve felt the grind of having to unblock something every evening, this is how you get out of that trap.

Worried about quality or losing control? I get it. I’ve been the person who retraced every release checklist “just in case.” Guardrails help. Preflight checklists, automated checks, and clear triggers for escalation handle 90% of risk. My job now is designing spot-check reviews, not approving every change. Once you shift to sampling the exceptions instead of gatekeeping the door, you can breathe easier without things slipping.

I also used to think, “What about the subtle stuff? The things the numbers miss?” That’s why I couple the independence scorecard with the storylines: retrospective notes, live customer feedback, and incident write-ups. The real picture is what you see when you hold both—the raw stats and the context—and you can course-correct before blind spots become system failures.

Maybe you’re still skeptical because you’ve seen stakeholders cheer for visible hustle instead of the work required to stop being the team bottleneck. The trick is to reframe the outcome. Show how system independence means fewer costly bottlenecks, radically faster cycle time, and a team that builds resilience into delivery. Try something as simple as, “Here’s what moved forward last week with zero top-level interruptions—so we shipped in half the time, and everyone got to focus on real problems, not repeat approvals.” Translate the value in terms execs actually care about: risk reduction, speed, and compounding wins that keep the roadmap moving.

So here’s what I’m asking you to do. Go back to the start. This week, just track one thing that moved without you. Then keep going—one system, then another, and watch the compounding impact start to kick in. That’s the shift from pushing work to building teams that pull together, with or without you in the room.

And honestly, I still catch myself reaching for the “step in” button when things get weird or ambiguous. I know “getting out of the way” is the right move, but it’s a muscle I haven’t fully built. Maybe that tension never goes away. Maybe it shouldn’t.