Making Skip-Level 1-on-1s Useful

Skip-level 1-on-1s are one of those practices that sound obviously good and usually deliver almost nothing. You block thirty minutes with someone two layers below you, you both show up, you exchange pleasantries, the engineer tells you everything is fine, and you walk away feeling like a connected leader. Meanwhile the thing you actually wanted to learn, the friction that never reaches you through the management chain, stays exactly where it was. I have run hundreds of these meetings over the years, and for a long time I ran them badly.

The reason they fail is structural, not personal. The person sitting across from you reports to someone who reports to you, and they know it. They are doing fast arithmetic about what is safe to say and what is not. If you want a skip-level to be useful, you have to design against that arithmetic rather than pretend it does not exist. What follows is how I think about these conversations now, in a regulated fintech environment where the stakes of not knowing what is happening on the ground are unusually high.

What They Are Actually For

The first mistake I made was treating skip-levels as a generic relationship-building exercise. They are not. A skip-level has a specific job: to give you signal that your direct reports cannot or will not give you, and to give the engineer a sense that the organization above their manager is real, accountable, and reachable. Everything else is secondary.

That framing matters because it tells you what not to do. A skip-level is not a performance review, it is not a status update on the roadmap, and it is not a forum for you to relay strategy downward. You have other venues for those. If you spend the time talking, you have wasted it. The whole value is in what you hear, and most of what you need to hear is uncomfortable, half-formed, or politically inconvenient for someone in the room who is not present.

I also stopped pretending these meetings are about the individual's career. They can touch on that, but if I make career development the headline, the engineer reasonably assumes their manager will hear about it, and the conversation snaps back to safe topics. The honest purpose is closer to organizational instrumentation. I am trying to read the parts of the system that do not show up on a dashboard.

The Trust Deficit You Start With

You begin every skip-level in debt. The engineer does not know how you handle bad news, whether you will quietly mention something to their manager, or whether candor will be remembered at promotion time. Until you prove otherwise, the rational move for them is to stay vague. I have watched genuinely talented engineers give me a polished, frictionless account of a project I knew was on fire, simply because they had no reason to trust that telling me the truth would help them.

The implication is that the first few skip-levels with any given person are mostly about establishing terms, not extracting insight. I say explicitly, in the first meeting, what I will and will not repeat. I tell them that anything they raise about their manager stays with me unless they ask me to act, and that if I ever do need to act, I will tell them first and we will agree on how. Then I have to actually honor that, because the organization talks and a single broken confidence ends the program.

The fastest way to make every future skip-level useless is to repeat something in a way that gets traced back to the source. People will know within a week, and they will adjust accordingly for years.

Trust here is not a feeling, it is a track record. The engineers who eventually tell me the genuinely useful things are the ones who watched me sit on a sensitive comment for months, or saw me push back on their behalf without ever naming them. That reputation is the real asset, and it is slow to build and instant to destroy.

How I Pick Who To Meet

I cannot meet everyone two levels down on a useful cadence, so selection matters. Early on I rotated through alphabetically, which felt fair and produced almost no signal. Now I am deliberate. I bias toward people whose perspective I am structurally likely to be missing: engineers on teams that have been quiet for a while, people who recently joined and still see our dysfunction clearly, and people on teams where a manager change or reorg has just landed.

I also make a point of meeting people who are not the obvious stars. The high performers usually have channels to me already, and they tend to be coached on how to present. The engineer who is competent but frustrated, or quietly disengaging, is the one whose departure will surprise me three months later if I never talk to them. Some of the most valuable things I have learned came from people who were one bad sprint away from leaving and had decided no one above their manager cared.

Practically, I keep a simple list and try to ensure that over a quarter I have heard from a representative spread of the organization, not just the loudest or most senior. In a regulated environment this breadth matters for a concrete reason: control gaps and risky shortcuts are most often visible to the people doing the hands-on work, and those people are rarely the ones presenting in leadership reviews.

Questions That Actually Open People Up

The quality of a skip-level lives or dies on the questions, and the worst questions are the ones that invite a reflexive yes. "Is everything going well?" gets you a yes. "Do you have what you need?" gets you a yes. These are not questions, they are permission slips to say nothing. I had to retrain myself out of them entirely.

What works better are questions that assume friction exists and ask the engineer to locate it. A few that have reliably earned real answers for me:

• What is something we do here that you found surprising or hard to make sense of when you joined?
• If you had my job for a day, what is the first thing you would change?
• Where are you spending time on work that you suspect does not matter?
• What is a decision recently that you disagreed with but went along with anyway?
• Who on another team do you depend on, and where does that hand-off break down?

Notice that none of these ask the engineer to criticize their manager directly. That is intentional. People will tell you about a broken hand-off, a confusing decision, or wasted effort far more readily than they will indict the person who writes their review. The management problems usually reveal themselves indirectly, through the pattern of friction, and you have to be willing to infer rather than interrogate.

Listening For The Second Thing

Most useful information in a skip-level arrives after the first answer, not in it. The engineer says the deployment process is a little slow. That is the surface complaint. If I nod and move on, I learn nothing. If I ask what slow actually costs them this week, I might learn that a single person owns the release pipeline, that this person is overloaded, that releases now cluster on Fridays because that is the only time that person is free, and that the team has quietly stopped shipping small changes because the overhead is not worth it. The throwaway comment was the door; the real building was behind it.

This means my main discipline in the meeting is restraint. I ask a short follow-up and then I shut up. Silence is uncomfortable, and engineers, like everyone, tend to fill it, often with the thing they were not sure they should say. The temptation to jump in with my own analysis or a reassurance is strong, and almost every time I give in to it I cut off the more valuable second statement that was about to come.

I also try to listen for what is conspicuously absent. If someone describes their work for twenty minutes and never once mentions their manager, that absence is data. If every example of a hard decision involves the same other team, that pattern is data. The explicit content of a skip-level is useful, but the shape of it, what gets emphasized and what gets skipped, is often more telling than any single sentence.

Not Undermining The Manager In Between

The single fastest way to wreck your management layer is to let skip-levels turn into a back channel that routes around managers. If engineers learn that the way to get something done is to wait for their skip-level and tell me, they stop respecting their actual manager, and the manager stops being able to lead. I have seen organizations where the skip-level became the real chain of command and the nominal managers became administrators. That is a self-inflicted wound.

So I am careful about what I do with what I hear. The default is that I do not act directly. If an engineer raises a problem that their manager should be solving, my job is usually to make sure the manager hears about the category of problem without it being attributed, and then to let the manager solve it. If I keep solving things that are a manager's responsibility, I am training the manager to be passive and the team to bypass them.

There is a harder case, which is when the manager is the problem. That happens, and skip-levels are sometimes how you find out. But even then, the answer is rarely to act on a single data point from a single skip-level. I treat it as a hypothesis to verify through other channels, and I am honest with myself about the fact that a frustrated engineer is not a neutral narrator. The skip-level tells me where to look, not what to conclude.

Closing The Loop Without Exposing Anyone

An engineer who raises something real and then sees nothing happen will conclude, correctly, that the conversation was theater. But acting visibly on what they said can expose them as the source. This is the central tension of the whole practice, and getting it right is most of the skill.

My approach is to aggregate before I act. If three different skip-levels surface the same complaint about, say, the on-call rotation, I now have a problem I can address openly without pointing at anyone, because the obvious explanation is that lots of people feel it. Aggregation is both better signal, since one person's gripe might be idiosyncratic, and better cover for the people who spoke. When I can only act on something a single person raised, I go back to them first and ask how they want me to handle it. Sometimes they would rather I do nothing than risk exposure, and I have to respect that even when I disagree.

I also try to close the loop with the individual even when I cannot solve their problem. A short follow-up that says I heard them, here is what I am able to do and here is what I am not, costs me almost nothing and is the difference between an engineer who keeps being candid and one who decides the channel is dead. Doing nothing and saying nothing is the worst outcome, because it confirms their original suspicion that the meeting was performance.

Measuring Whether This Works

It is fair to ask whether any of this is worth the calendar time, and I am skeptical of practices that resist measurement. I do not have a clean metric, but I have proxies. The clearest one is whether skip-levels are still teaching me things I did not already know from my direct reports. When a quarter goes by and every skip-level merely confirms what my staff meetings already told me, either the organization is unusually healthy or, more likely, the meetings have decayed into theater and I need to fix my questions or my candor record.

Another proxy is whether problems are reaching me earlier. The whole point is to shorten the distance between a problem appearing on the ground and me becoming aware of it. If I am consistently learning about attrition risk, control gaps, or cross-team breakdowns after they have become crises, the early-warning system is not working regardless of how pleasant the meetings feel. In a regulated business, that lead time is not a nicety; the difference between catching a risky workaround in a skip-level and catching it in an audit finding is enormous.

Finally, I watch whether the same issues keep coming back. If they do, it usually means I am collecting signal and not acting on it, which over time is worse than not holding the meetings at all, because it teaches people that being honest with leadership changes nothing.

Conclusion

Skip-level 1-on-1s are not inherently valuable; they are inherently awkward, and the value has to be engineered into them against a strong default toward saying nothing useful. The work is in the design: being explicit about confidentiality and then honoring it, selecting the people whose perspective you are structurally missing, asking questions that assume friction exists, staying quiet long enough to hear the second statement, and acting in ways that protect your sources and respect your managers. Do those things consistently and the meetings become one of the few reliable ways to know what is actually happening in an organization too large for you to see directly. Do them lazily and you have built a very expensive way to feel connected while learning nothing.