Echoes

There's a particular feeling you get when you find out something went wrong on a team you're responsible for—but only after it's already gone wrong. It's not the same as a fire drill. Fire drills are loud. This is quieter. More like opening a door you thought was closed and realizing the room behind it has been on fire for weeks.

I was managing six teams at the time. One of my managers—call him David—owned a project with a hard external commitment. Weekly reviews, VP-level visibility, the whole thing. I'd check in every week. "How's Project Meridian?" "On track." "Any blockers?" "Nah, we're good."

Three weeks before the deadline, a stakeholder pinged me directly. Not David. Me. "Hey, just wanted to flag—we haven't gotten a working prototype that was promised two weeks ago. Is this still happening?"

I pulled up the project tracker. Ghost town. No updates. Barely any PR activity on the relevant repo. In a skip-level the next day, one of David's engineers told me, carefully, that the team had been stuck on a complex technical challenge and David hadn't escalated because he thought he could resolve it himself.

David wasn't hiding anything. He was doing what he thought a good manager does: own the problem, figure it out. But the commitment was going to slip and the stakeholder was losing confidence.

The part that stuck wasn't that David messed up—he was a newer manager still learning when to escalate. The part that stuck was that I had no independent way of knowing. My entire read on that team came through David's self-report. When his read was wrong, mine was wrong too.

Two Layers Removed

When you go from managing engineers to managing managers, you're still responsible for outcomes—shipping, quality, team health—but you're two layers removed from where the work happens. You don't see the pull requests. You're not in the standups. You don't hear the hallway grumbling about the build system.

The instinct is to pick one of two bad options. You over-monitor—sit in on standups, Slack engineers directly, manage through your managers until everyone can feel it. Or you fully defer—trust your managers completely, take their word for everything, and focus on strategy until something like the David situation happens and you realize you had no way to see it coming.

The actual job is building systems that give you an honest picture without requiring you to be in the room.

Information Should Find You

The best thing I learned from managing managers is that you shouldn't need to ask the right question at the right time to discover problems. If your information depends on you probing in exactly the right direction during a thirty-minute weekly sync, you will miss things. You're not that lucky. Nobody is.

You want bad news to reach you through at least two independent paths. If the only channel is your manager's self-report, you've built a single point of failure into your information architecture.

Skip-level one-on-ones are the most obvious mechanism and also the most misunderstood. When I first started doing them, I treated them like one-on-ones with my directs—asking about projects, offering coaching. This was wrong. Skip-levels aren't about managing those people. They're about developing an independent read on team health. You're listening for signals: Is this person growing? Do they feel supported? Are there frustrations their manager might not see? You're not going around your managers. You're building a second antenna.

The other lesson was to look at systems before people. Project trackers, PR velocity, incident data—these tell you a story before anyone else. The data on David's team had been screaming for weeks. I just hadn't looked. Now I check the systems first and use the conversation to understand what they're telling me.

None of this is revolutionary. It's plumbing. But most senior leaders I know—including me, for longer than I'd like to admit—rely on vibes and verbal check-ins instead of building the plumbing.

Hands Off the Wheel

One of my managers—call her Megan—was struggling with a cross-functional partner. The partner team's PM was consistently overcommitting Megan's team in roadmap discussions, and Megan wasn't pushing back effectively. I could see it happening. I knew exactly what to say. I'd navigated this dynamic a dozen times.

So I set up a meeting with the PM myself.

Problem solved. The PM recalibrated expectations, the roadmap got fixed, Megan's team had breathing room. Except now Megan's team saw that when things got hard, I stepped in. Megan learned that if she waited long enough, I'd handle it. The PM learned to go to me next time instead of working it out with Megan.

I'd solved a three-week problem and created a three-month one.

The alternative is coaching through the problem, not around it. Sit with Megan. Ask what she's tried. Help her think about the PM's incentives. Role-play the conversation. Let her go have it. Let it be a little worse than what you would have done. She'll learn. Next time it'll be better. The time after that, she won't need you at all.

Managers need real information and real authority, not just responsibility without context. If you're holding Megan accountable for the PM relationship but haven't shared the broader org dynamics or the things you know from director-level conversations, you've given her accountability without the tools to exercise it. That's a trap.

The David-Shaped Wound

After the David situation, I overcorrected. Biweekly skip-levels with everyone, tracker reviews. It caught problems earlier. It also drove my experienced managers nuts.

One of them—six years running teams—finally told me plainly that the constant check-ins felt like I didn't trust her. She was right. I didn't have a trust problem with her. I had a David-shaped wound I was applying universally.

The real skill is calibrating. What you're calibrating isn't effort. It's judgment. A manager can work incredibly hard and still make poor calls about when to escalate or when a project is actually at risk. Effort is easy to observe. Judgment takes time—you learn it by watching what they do with ambiguity and whether they change their approach when the evidence changes.

As trust builds, you pull back. With a manager I trust deeply, a monthly skip-level and a scan of project artifacts is enough. With someone newer, I'm in the details more—not micromanaging, but gathering the signal I need to coach effectively.

The Echo

I think about the David situation differently now. At the time, I saw it as an information failure. That's true, but incomplete.

I was still thinking like a manager of ICs who happened to have managers reporting to me. But managing managers isn't about being a better-informed escalation layer. It's about building an organization that surfaces problems on its own, develops leaders who can handle ambiguity, and doesn't depend on any single person—including you—asking the right question at the right moment.

You can't pull every lever yourself from two layers up. So you build longer ones. You construct the skip-levels and the dashboards and the post-mortems. You coach instead of fixing. You calibrate trust and revise it as people grow. And you accept that sometimes you'll still find out too late. The goal isn't to prevent every surprise—it's to make surprises rare and recoverable.

That's the echo working the way it should.