A few weeks ago, I was talking with Paweł, someone I’ve been mentoring as he works toward a director role. He’s doing a lot of things right: growing his scope, delegating more, building roadmaps. But in the middle of the conversation, he surfaced a dynamic I recognized immediately.
An issue surfaces. He sees it, doesn’t have an answer yet, and sets it aside. By the time he comes back to it, his boss has already stepped in.
This isn’t just a timing issue; it’s an ownership issue, which directly impacts your credibility as a leader.
Leaders often lose credibility not by inaction, but by failing to clearly signal that they are taking ownership of a problem. It doesn’t feel like a failure at the time because you intend to handle it, but intention isn’t enough.
I’ve been on both sides of this. I’ve been the person who waited too long, and I’ve been the boss watching a thread, wondering why nobody was picking it up. What I’ve learned is that ownership isn’t really about caring or competence. Most leaders care a lot. The gap is between doing and signaling.
When you’re overwhelmed, the instinct is to triage. “I can’t solve this right now, so I’ll come back to it.” That feels reasonable. But what the organization sees is silence, and silence reads as nobody’s on top of it.
There are a few competing forces at play here. Your workload is expanding. You’re being pulled in many directions, and you can’t personally solve everything. So when something comes in, and your plate is already full, it’s just another thing, and you’re already behind.
There’s also a real difference between solving a problem and ensuring the organization knows someone is solving it. Those are two separate acts, and the second one is often more urgent than the first.
And then there’s the coaching instinct. If your team is on the same thread and you keep jumping in, you’re not giving them space to step up. Stepping back can be the right move, but it’s often used as an excuse for not stepping in when you should. Sometimes “I’m letting them learn” really means “I didn’t want to deal with it.”
What’s at stake when you get this wrong is real. If your boss has to step in, you’ve demonstrated a gap. Not necessarily a gap in skill, but a gap in awareness and responsiveness. When your boss picks up something that’s yours, they’re not helping you. They’re doing your job for you, and everyone around you sees it.
The place where I learned this most concretely was in my first CTO job.
The CPO and I had a good working relationship, but a conflict was building between our teams in one specific area. We were both aware of it. We were both coaching on our respective sides and trying to let the teams work it out themselves. That’s usually the right call. But the conflict kept going. Eventually, it reached my CEO. Someone mentioned it to him in passing and said they didn’t understand why this was still happening.
In our next one-on-one, he told me, “If it’s getting to me, that means it’s not being handled. And if it’s not being handled, I’m going to feel obligated to step in. And I will do a worse job at this than either you or the CPO, because I’m furthest from the work and the teams.”
He wasn’t threatening me. He was explaining the mechanics. When something escalates past you, your boss doesn’t just get updated. They feel responsible. They feel like they have to act. And now they’re doing your job, and everyone can see it.
The CPO and I could have stepped in much earlier. We chose not to, and we let it go on too long. That was the lesson. It wasn’t about having the answer. It was about not letting the ball hit the floor.
Since then, I’ve thought about ownership as three specific behaviors: signal, route, and verify.
Signal means acknowledging the issue fast. Not solving it, just communicating that you see it and you’re on it. This is the step most people skip, because they think they need to come back with an answer. They’d rather look smart when they respond than look fast. In leadership, fast and incomplete beats slow and thorough almost every time. The moment you say, “I see it, I’m on it,” the pressure releases. Everyone exhales. Then you can focus on actually solving it correctly.
If you’re not sure how to signal ownership, here are a few phrases I use:
“I see this and will follow up.”
“Thanks for flagging. I’m looking into it and will update soon.”
“I’ve got this on my radar and will make sure it’s handled.”
“Acknowledged. I’ll respond as soon as I have more information.”
Simple, clear language can make all the difference in letting people know that something is being addressed.
Route means deciding who should actually handle it. Does someone on your team own this area? If not, you’re the owner until you find one. Ownership doesn’t mean doing. It means making sure it gets done. If you’re delegating, be explicit about it. Someone needs to know they have the ball.
Verify means following up to confirm that the issue has been resolved or progressed. This is where delegation becomes real. You hand it off, and then you close the loop. You gave it to someone, now make sure they delivered.
This loop—signal, route, and verify—works at every level. For engineering managers, it’s run in sprints; for directors, across quarters; for CTOs, across the organization. The scale changes, but the structure remains the same. The key takeaway: this is a repeatable process, not a personality trait. You can build the habit. I did.
Now, there’s a practical dimension here that’s worth being specific about: how fast you need to signal depends on the severity of the issue.
If the site is down, you acknowledge it immediately. That’s not a judgment call. A minor bug affecting almost no users? You’ve got a few hours. But you don’t let it go much past that, because at a certain point, silence just reads as ignoring it.
Who’s on the thread also matters. If your boss is CC’d, that’s a signal in itself. Someone decided this needed to be seen by them, which usually means it’s important. You want your boss to see that it’s being treated with the seriousness it deserves.
If you’re a director or senior manager, you’re probably watching threads where your directs should be responding. When you see silence on something urgent, my preference is to reach out to the person who should be handling it before jumping in myself. “Hey, you should respond to this. Better to come from you than me.” Most of the time, they’re already dealing with it and just haven’t communicated yet. Give them a moment. If they don’t respond, then you step in. If there is still no response after your nudge and you have to step in, it is important to address the pattern directly with your report. Have a conversation to determine whether there are obstacles preventing them from responding, clarify your expectations for communication, and agree on a plan to handle similar situations moving forward. Consistency here helps prevent the same issue from recurring and reinforces the importance of visible ownership in leadership.
But every time you do step in for someone who should have handled it, that’s a follow-up conversation. Not punitive, but clarifying. “This is why signaling matters. This is why speed matters.” I have this conversation regularly with people who are still learning the habit. They want to wait until they have the complete picture before saying anything, but that’s the wrong instinct. The goal isn’t to look thorough. It’s to make sure the organization knows nothing is falling through the cracks.
There’s another trap worth naming: confusing “letting the team learn” with not doing your job.
There is absolutely a time to let your team struggle and grow. Stepping back is sometimes exactly right. But there’s also a time to step in, because you’re running an organization, not a school. The distinction matters.
To help make this decision in real situations, I look for a few signals:
The issue is having a significant impact on the organization or the team’s objectives.
The situation is persisting longer than expected, despite reminders, and there’s no visible progress.
The problem is escalating, either because others outside your team are raising concerns or because it’s risking broader consequences.
The person or team appears stuck or overwhelmed, and additional coaching from the sidelines is unlikely to help.
Reputational risk is growing, especially as business-critical stakeholders notice the lack of progress.
When you see one or more of these, it’s usually time to step in. If an issue sits unresolved long enough that it escalates past you, the coaching rationale stops being a justification and starts being an excuse.
The ownership threshold also shifts as you move up. When I’m thinking about whether someone is ready for a director role, one of the things I’m watching for is whether they’re owning their area strategically, not just tactically. A senior engineering manager who is ready to move up isn’t waiting for their boss to hand them a plan. They present their leader with their team’s strategy, aligned with the organization’s goals. That’s ownership at a different level. You tell me where you’re going, not the other way around.
I’ve worked with directors who are trying to move to VP, and when I talk to them, what I sometimes hear is that their boss is still setting the strategy for their area. That’s a signal. If I’m articulating a strategy for your domain because you haven’t, that’s not a problem with your execution. It’s a problem with your ownership. Somebody has to do it, and if you’re not, I will, because ultimately I’m responsible for it at the level above yours. But that tells us both something important.
So how do you move from tactical to strategic ownership? Here are a couple of actionable steps. First, regularly step back from the details to evaluate your area as a whole: where are the biggest risks and opportunities, not just in delivery but in how your team shapes business outcomes? Second, proactively communicate a clear vision for your area; don’t wait for your manager to define it for you. Draft your own strategy and share it with your boss for feedback and alignment. Third, connect your area’s objectives to the broader organizational strategy; show how your team’s work advances the company’s goals, and identify gaps where you can drive more impact. Finally, invite feedback from peers outside your direct area to pressure-test your plan and surface blind spots early. These steps shift your focus from just keeping the lights on to ensuring you and your team are out ahead, shaping the direction rather than reacting to it.
The boundaries of ownership matter, too, and it’s easy to get this wrong in either direction.
At Microsoft in the nineties, one of the real organizational problems was teams fighting over ownership, grabbing things that weren’t theirs because they wanted more scope. You’d see conflict over who owned a piece of work that both teams wanted, not because it needed to be done, but because ownership meant influence. That’s not ownership. That’s empire building.
You need to take responsibility for what you own. You shouldn’t be taking ownership of things that belong to someone else. If you see something that needs to be handled but it’s outside your remit, the right move is to flag it to the peer who should own it. “I don’t know if you saw this, but it’s starting to be a problem, and you should probably get in front of it.” That’s the collegial thing to do.
The tricky situations are the ones that fall between teams. It’s not clearly yours. It’s not clearly someone else’s. In those cases, I think the right answer is to own the problem of finding the owner. “I’m not sure if this is my team’s or yours, but we’ll figure it out.” That’s not overreaching. That’s being responsible. You’re taking ownership of the routing, not absorbing someone else’s work.
If someone tries to take a genuinely ambiguous piece of work that should have been yours, the right move is usually a direct conversation. “I saw you wanted to take this on, but I think it belongs with our team. I just didn’t move as fast as you did. Let’s figure out together how to handle it correctly.” That keeps it collaborative rather than political. If the dynamic in your organization makes that kind of conversation impossible, that’s a different problem, and it might be telling you something about where you work.
Ownership also has to scale with delegation as you get more senior, because you can’t just hold more. You have to hold differently.
At the CTO level, almost everything is delegated. The ownership at that point is making sure the delegated work actually happens. My plate is always full, and some of what’s on it is genuinely non-delegable, things that are sensitive or require my specific relationships or judgment. When those things pile up, there’s a real risk that other things I’ve taken on start slipping. The answer is more aggressive delegation, not tighter personal control.
But delegation without follow-through isn’t ownership, it’s just passing the problem to someone else. The people who work for me are also busy. Something I delegated that isn’t their highest priority can slide quietly down their stack. I need to check in. “Hey, this still needs to happen. Let’s make sure it gets done, or if you can’t get to it, tell me, and I’ll find someone else.” That’s not micromanaging. That’s closing the loop.
The hardest part of this transition is letting go of the satisfaction of solving things yourself. There’s a real pleasure in personally figuring out a hard problem. Handing it off to someone else feels less complete, at least the first several times. I used to conflate staying close to the work with being a good leader. They’re not the same thing. Staying close to the work can be a way to avoid the harder, less immediately satisfying work of managing through others.
There’s a book that captures this well. Team of Teams by General McChrystal is one I’d recommend to anyone in engineering leadership, partly because it comes from a completely different world, and that distance is useful. One of the things it describes is how stepping back from personal decision-making feels like shirking responsibility. That feeling is real, and it doesn’t go away. But it’s not a reliable signal.
If you’re looking to explore this topic further, I’d also recommend, once again, Turn the Ship Around! by L. David Marquet; its “leader-leader” model is another approach to the Signal/Route/Verify loop. Another resource worth your time is the article “Who’s Got the Monkey?” by William Oncken, Jr. and Donald L. Wass, published in Harvard Business Review. It’s a classic piece on the traps leaders fall into when they take ownership of their team’s problems instead of empowering others to solve them. Both go deeper on the nuances of ownership and delegation and are especially valuable for those looking to grow into more senior roles.
One more distinction that’s worth being precise about: ownership and accountability are not the same thing, even though we use the words almost interchangeably.
Ownership is proactive. It’s about claiming responsibility before there’s a solution. “I see this. It’s mine. I’m on it.” That’s forward-looking.
Accountability is retrospective. It’s standing behind what happened after the fact. “This was my area. I’ll answer for the outcome.”
You can be accountable for something you never truly owned. If you delegated a decision and it went badly, you’re still accountable for the result, even though you weren’t the one who made the call. That’s the deal. You can also own something in the moment and still dodge accountability later, but that’s a different kind of failure, and people notice.
Most organizations talk constantly about accountability but rarely about ownership as a behavior. That’s a problem, because accountability only kicks in after something goes wrong. Ownership is how you keep it from going wrong in the first place. Accountability asks, “Whose fault was this?” Ownership asks, “Who’s on it right now?”
When something comes in on a thread about an issue in your area and your direct report isn’t responding, they’re usually not ignoring it. They’re overwhelmed. They’re triaging. They see the problem, they don’t have an answer yet, and they plan to come back to it. Sound familiar?
The mental shift that helps is this: this is not a thing I need to solve. This is a thing I need to manage. Those are different jobs. Once your team internalizes that distinction, the signaling behavior follows naturally, because the barrier to responding drops. You don’t need the answer. You just need to say you’re on it.
If you’re on the receiving end, and your boss keeps jumping in on threads that belong to you, they’re probably not trying to micromanage you. They’re trying to assess whether anyone has the problem. They don’t want to step in. But the longer the silence, the stronger the signal that nobody is in control, and they feel like they have to.
There’s also an organizational visibility dimension here that’s easy to miss. When a message goes out to a team channel, nobody on the team responds, and then a senior leader jumps in to say, “Yes, we’re on it.” That whole team has just received a signal about their manager. It’s quiet. Nobody says anything. But it erodes trust and authority over time. Your behavior teaches the organization whether you’re paying attention. It also teaches them how safe it is to make decisions without you.
Early in my career, I thought ownership meant being the smartest person in the room and having the answer. That approach works fine when you have a small team and direct responsibility for the work. It completely breaks at scale.
The shift for me was realizing that ownership at any significant level of seniority is mostly about responsiveness and routing, not expertise. I don’t need to know everything about every issue in my organization. I need to know who does, how to get the answer quickly, and how to make sure the organization knows it’s being handled. Those are learnable skills that compound over time.
Ownership is not a feeling. It’s a behavior. Specifically, it’s three behaviors: signal, route, and verify. The test for any leader is not how fast a problem gets solved. It’s how fast the organization knows that someone is on it.
If you’re constantly the person your boss has to follow up with, you’re not demonstrating ownership, no matter how good your eventual work is.
The organization doesn’t need you to solve every problem. It needs to know that nothing in your area gets dropped. Nothing hits the floor.
To hear an extended discussion of this topic, please listen to my most recent podcast episode: Don’t Let Your Boss Do Your Job
Thanks again for reading! If you find it helpful, please share it with your friends.
Buy on Amazon | Buy on Bookshop.org | Buy on Audible | Other stores