The Skip-Level Is Not a Feedback Tool

Years ago, early in my management career, I was having a conversation with Bob, a developer who reported to John, one of my managers. Something was off in the way Bob was talking. I could not name it immediately. What I eventually identified was this: he could not explain the business value of his work. He knew his tasks. He could not tell me why they mattered, what problem they solved, or how they connected to anything the organization was trying to accomplish.

I started asking questions about how his work came to him. The scope, the priorities, the rationale: all of it arrived fully formed. Bob’s role in shaping any of it was next to none.

John was holding everything. The context, the priorities, the reasoning, the mission. Bob was executing. The management layer was not connecting Bob to the work. It was standing between Bob and the work, managing the handoff. Bob’s morale was low in the way that morale gets low when you stop being a participant in something and become an order taker. He was not disengaged. He had simply never been given anything to engage with.

What I also understood, sitting with that conversation, was that I had contributed to it. My standing guidance to my managers was to communicate through the management chain: questions and concerns went to John first, not directly to me. The policy was well-intentioned. It had built exactly this.

I felt embarrassed and frustrated. I was blind to what was going on. I did not have the information I needed until that conversation exposed it. And I did not yet have a framework for what to do about it. Quiet Confidence and LeadershipOS™ did not spring out of nowhere. They iterated over years, over many positions, through many direct reports. This was one of the moments that built them.

What changed immediately was my understanding of what my policy had actually created. As for what to do about it: the answer came from something I had already experienced but not yet named. A manager several levels above me had once put a meeting on my calendar without explanation, simply to find out what I actually understood about the direction of the organization. Being on the receiving end of that conversation had given me something I did not know I was missing. It was that experience that prompted me to start running skip-levels myself. The conversation with Bob was where I understood why they work.

The conventional wisdom on skip-level conversations sounds like this: run them occasionally, frame them around how the manager is doing, ask whether expectations are clear and whether the team member feels supported. The specific questions tend to follow a pattern: how is your manager doing, what could they do better, what would help you perform at your best? The output feeds your assessment of the person above the team. You run the skip-level when you already suspect something is wrong, and the session orients entirely around the suspected problem.

This framing produces a limited conversation. It misses the more valuable question entirely: whether the system above the team is working.

A manager doing their job well produces a team whose members can explain why their work matters, what problem it solves, how it connects to the organization’s direction. You do not need to ask about the manager. You can read the system by asking the team.

A manager who has become the information system for the team produces something different: people who can describe tasks but not mission, who escalate questions the system should have already answered, who depend on their manager’s continued presence to make decisions the system should have made automatic. The manager is not necessarily failing in any conventional sense. They may be highly responsive, deeply engaged, constantly available. They are simply carrying everything; the team has adapted to not needing to carry any of it.

That adaptation is the structural problem. It does not show up in a feedback session. It shows up in what a developer can and cannot tell you about his own work.

The managers who build systems that hold are not different in talent or intention from the ones carrying everything themselves. They have made a different decision about what the management layer is for: not the transmission of tasks, but the distribution of context. Those are different operating models. They produce different teams.

Run the skip-level with that question driving it. Not how is your manager, but what do you understand about why you are doing what you are doing. Ask one person two levels below you to explain the business value of what they are working on this week. Do not tell them what you are looking for. Just listen. If they can explain the problem it solves, who benefits, and why it matters now, the context is structural. If they describe their tasks, the context lives with their manager.

That answer tells you more about the health of your management layer than any performance review will. And it gives you something a performance review cannot: a specific place to start.

I write about structural leadership for technical leaders in high-stakes operating environments. The full operating model is in LeadershipOS™: http://TheLeadershipOSBook.com

---

I write about structural leadership for technical leaders in high-stakes operating environments. If you want to see where your system is load-bearing on you personally, the LeadershipOS™ Scorecard maps it: https://theleadershiposbook.com/scorecard