Some Things Have to Slip

A leader I respected early in my career told me something that stuck: some things just have to slip through the cracks. You cannot solve every problem. You are one person.

I believed that for a long time. And honestly, it wasn’t wrong advice for the time it was given. When your only tools are your calendar, your memory, and whatever you can hold in your head between back-to-back meetings, triage is survival. You make peace with the gaps.

What nobody told me was that the gaps have a pattern. And the pattern, if you looked at it clearly, would tell you something uncomfortable about what you were actually absorbing as a leader.

I’ve received the same feedback consistently over the years: delegate more. It’s not a new note. I’ve heard it in performance conversations, in coaching sessions, from leaders I trust. And I worked on it. But I’ll be honest – I was hesitant. Not because I didn’t believe in my team. Because delegation felt like introducing a variable I couldn’t control when I was already the one responsible for the outcome. Letting go meant trusting that what I promised would still get delivered. That’s a harder thing to sit with than it sounds.

So I kept absorbing. Quietly. The way most engineering managers do.

Then I did something that started as an experiment and turned into something I didn’t expect. I spent a few days logging everything I was actually doing – every task, every context switch, every thing I was tracking in my head that wasn’t written down anywhere. Then I asked an agent a simple question: what here can be automated?

The answer was more than I thought.

I started building a workflow. I’ll be upfront – it’s mine, it works for me today, and I don’t know yet if it scales beyond my own brain. What it does is pull together the signals I was manually chasing across multiple tools and surface them in a way I can actually use. It’s not just a snapshot of what’s in flight – it’s a two-way picture. Inbound: ticket load, active projects, pull request movement, incidents with direct team impact, Slack threads that need my attention, and the cross-functional projects I’m responsible for driving to the finish line as a tech lead. These aren’t things I’m loosely aware of – they’re mine to move. Outbound: health check messages, status updates, and the stakeholder communications that keep everyone aligned and unblocked. That last one is more than it sounds. Answering stakeholder questions often means chasing answers I don’t have readily available, which is its own trail of context switching before I can even respond. The things I was doing reactively, scattered across the day, now have a rhythm. And because the digest finds me instead of me hunting for it, I’m spending less time painting the picture and more time acting on it.

The first thing I noticed wasn’t that I was getting faster. It was that I was getting honest.

Honest about what I was taking on. Honest about what I was handing off. And for the first time, honest about what I was about to put on an engineer who was already underwater – before I put it there.

The delegation feedback finally started sticking not because I got better at delegation as a skill. It stuck because I finally had the information that made delegation the obvious move instead of the effortful one. When you can see who’s carrying what before you hand something off, letting go stops being a discipline problem. It becomes a data problem. And I finally had the data.

Here’s what I didn’t expect. Once I had the data, the conversations changed. The questions I’m asking my engineers shifted from what to why and how. Problems feel clearer. The ability to weigh scope against risk has gotten easier to chase down because I’m not starting from scratch every time I need context. And it’s not just me – I can feel it in the team too. Less time orienting, more time solving.

But I’ll say this carefully: maybe this is something that works today and looks completely different tomorrow. The tools are moving, the expectations are moving, and what counts as a good system right now might need to be rebuilt in six months. I’m not sure. I’m building in public, in real time, with no guarantee the answer I found today is the answer that lasts.

Here’s what I’m still sitting with: if this workflow is filling gaps, what does that say about the gaps? Am I getting better at my job, or am I getting better at catching what I was already dropping? And if leaders have been silent absorbers for years – making peace with what slips, hesitant to let go – what do we do with that information now that we have tools that can surface it?

I don’t have a clean answer. But I think the question is worth asking out loud.