The Secret to Skip-level One-on-ones
How to Build a Great Engineering Culture: Article 5
So you’ve been working hard and instilled the engineering culture that you want. From your perspective, everything is going smoothly. All of a sudden, a person from one of your teams leaves. A month later, another person from the same team leaves. You start to investigate and realise, too late, that the team is in shambles and things are seriously wrong. But all the while, the signals you were getting from your direct report leading the team, and the team metrics were that everything was ok, and just needed some minor improvements. It turns out that the leader was managing up (you) well, but was a destructive leader from the perspective of his team.
How did it get this way without your knowledge, and what could you have done to prevent it? One answer is to have skip-level one-on-ones and know how to get the right information from them. Regular one-on-ones with your direct reports are a well-accepted way to coach and guide your teams, but one of the key things (that is well-known, but not actually well adopted) to building a great culture is having regular one-on-ones with the people reporting to your direct reports (your skip-levels). But skip-level one-on-ones that just go through the motions are not enough. You have to probe deeply in them, often by actually questioning potential issues without waiting for your skip-levels to proactively raise them. While the example above is an extreme case, the same structural gap exists in subtler forms, and skip-level one-on-ones are designed to catch both.
“I sometimes feel like I’m the only Engineering Manager that gives a s**t,” one of my Engineering Managers (EM) said to me.
“What do you mean?” I asked.
What followed was an in-depth discussion, which led to the point that the EM wasn’t happy with the performance of one of the other EMs (not all the other EMs, which his initial statement suggested). He thought that the other EM hadn’t taken enough ownership of the team’s delivery and that the team was struggling. This was a valuable discussion that helped me understand the EM’s concerns about the other EM, which I then needed to validate. I was fortunate that the EM was willing to open up about his concerns, but most of the time, your reports will not be so willing to raise these sorts of issues (and even less likely with your skip-level reports).
I then went to my skip-level reports (the ones that reported into the potentially problematic EM) to try to understand the situation deeper. Asking some high-level questions about how the team was going yielded a few concerns about developer experience (DevEx), but not any information about the EM themself. It wasn’t until I said something like “I’m a bit worried that your EM hasn’t supported the team enough to uplift their DevEx, which has contributed to the team’s problems”. Once I said that, the skip-levels opened up, and I understood deeply what the problems were, which allowed me to support the EM to resolve the issues.
Probing deeply in one-on-ones: How to actually get useful information.
Skip-level one-on-ones can be a valuable source of information for you, but in order to effectively get information from them, there are a couple of ingredients needed. Firstly, the person needs to trust you enough to be willing to open up and provide valuable information (otherwise, you run the risk of getting superficial information that is unlikely to help), and the other is that you need to be able to probe effectively enough to ensure you are eliciting valuable information. We won’t delve into building up trust in this article beyond that it takes time and requires you to be authentic, show vulnerability and listen deeply, but we will look a bit more at how to probe. When asking questions initially, start broad (like “what’s on your mind”), and then escalate if that doesn’t yield anything.
If you have a suspicion that an issue exists (cultural, people-related or something else), then there is a technique that can help gain information that may not be forthcoming. If, after starting broadly and then probing, they still do not give any information about your concern, it may be because they do not want to throw their colleagues or boss under the bus, or because of the power differential between you and your skip-level. As in, they may not want to be the person in the team who exposes a concern. This can be highly problematic. I’ve had times when almost everyone in a team has the same concern, but nobody is willing to raise it because of that fear. For example, everyone in the team has a concern about one particular team member, but to each individual, it doesn’t feel like a huge concern. But when everyone has the same concern, it can be problematic.
A way to help them open up is to state your concern directly to the person. As in, for you to be the one who raises the issue so that they don’t have to. After that, there is usually a sigh of relief. Having to raise the issue themselves creates a significant amount of social risk for them. They may be worried about: being seen as political, being identified as disloyal, damaging relationships, retaliation, being wrong, becoming “the difficult person”, or creating conflict they then have to live with. You raising the issue transfers that risk away from them completely. They gain confidence that you are already aware of the issue, and they no longer need to tiptoe around it and can open up.
Some examples of ways to do this.
If, after asking “how do you think the team is going with delivery?” you don’t receive much of an answer, perhaps follow up with “I’m a bit worried about the team’s delivery, particularly with release x, what are your thoughts?”
If, after asking “how is your team doing with planning and clarity of work coming up?” you don’t receive much of an answer, perhaps follow up with “some people have raised concerns with sprint planning, and feel like the work isn’t clear enough to execute on, what do you think?”
If after asking “how is person x going, what are they doing well and what are they struggling with?” you don’t receive much of an answer, perhaps follow up with “Person x is halfway through their probation and I’d like to ensure I have some constructive things for them to work on, do you have any more detailed constructive feedback for them?”, or “I think person x has done well in the past when you work working on Y, but seems to be struggling a bit with Z, what do you think?”, or even “I’m worried about how person X is going, particularly around breaking down technical tasks for the team, what do you think?”
One time, I had a new Engineering Manager (EM) join the company. After a couple of months, a Senior Engineer in that team (my skip-level) raised a concern that he felt micromanaged by the new EM. The Senior Engineer had been quite a high performer in previous teams but had an issue with taking on too much work themselves, so (after encouraging the Senior Engineer to raise the issue directly with the EM), I wanted to validate the concern with other people in that team. In my one-on-ones with the other engineers in that team, I asked about the new EM with questions like “How do you think the EM is going? What is the EM doing well, and what areas concern you?” For some of them, that was enough for them to raise concerns about micromanagement. For others, that wasn’t enough so I probed deeper with questions like “How do you think the EM is going with managing work across the team and individuals?” and if still no answer, “I ask, because I’m a bit worried that the EM may be managing a bit closely and potentially frustrating people as a result. Is that something you have noticed at all?”. From the discussions with my skip-levels, I was able to diagnose the problem, which was around the delivery of the message that came across as micro-management, but that wasn’t the intent. We worked on how to use questions to get the information she needed and determine if people were already on the right track, and only providing direction if they were off track, rather than constantly providing direction, which came across as orders.
Probing a topic like this is a great way to get detailed information, but it must be done very carefully since it can potentially exacerbate issues or undermine people. You need to be genuinely curious about what people are going to say, ask questions and don’t assume that your assumption is correct until you have validated it. More often than not, it helps uncover useful information, and will build credibility with your skip-levels because it will show them that you are already aware of an issue that they are worried about, and now things will be done about it.
This technique is not your first go-to technique but more of a last resort. It should be reserved for situations where you have strong prior evidence from outside the skip-level conversations (e.g. metrics, direct observation, exit interviews).
Not undermining your direct reports
The above example shows how things can go well when you raise the issue first, but things can also go wrong if you do this ineffectively. There is a very fine line to walk, as you run the risk of creating confirmation bias and potentially undermining people, so the way you raise the issue will be highly context sensitive and also based on the maturity of the person you are talking to. Senior leaders have disproportionate influence over how problems are framed, so the moment you name a concern, people can unconsciously anchor on it and reinterpret ambiguous experiences through that lens. That means you need to introduce concerns tentatively, stay genuinely curious, and actively look for disconfirming evidence rather than treating early signals as validation. To avoid reinforcing false assumptions, I try to validate concerns across multiple independent conversations, look for concrete examples rather than emotional agreement, and pay particular attention to evidence that contradicts my initial suspicion.
I once had concerns that a Staff Engineer (Tech Lead) in a team wasn’t providing sufficient tech direction (and what he was providing wasn’t good direction for the team). I initially probed the skip-levels to get their thoughts. “What do you think about the tech direction of the team?” That didn’t yield much. “I am a bit worried that the Staff Engineer may not be providing enough tech direction for you, and perhaps direction that isn’t appropriate right now”. (Noting that I only said that to the more senior members of the team). To that, I got responses that indicated the team was happy with the direction being provided.
A few weeks later, in subsequent skip-level one-on-ones, one of the senior engineers said, “You know how you were worried about the direction from the Staff Engineer? Well, I think it is an issue now”.
I was a bit worried now. Had I seeded this concern with the Senior Engineer with my probing a few weeks ago, thereby undermining the Staff Engineer, or was it genuinely a concern that I had just seen earlier, and now the Senior Engineer was seeing it too? Fortunately, when I initially raised it, and over the course of time, I saw enough other data points to validate that there was an issue, and I am confident that I triggered the concern myself. But really, there is no way to be sure of this. I may have undermined my Staff Engineer and created an issue that never existed. So this sort of probing does run the risk of seeding concerns that may not exist, or undermining your report in other ways.
To help manage this, the first thing that needs to happen is that your direct reports need to be aware of and understand the intent of the skip-level one-on-ones (particularly since it isn’t necessarily common practice).
Next, the key thing that needs to occur is transparency and overcommunication. Any key insights that are raised by your skip-level need to be communicated back to your direct report. Any significant misalignment or gaps (signal loss) in the broader context that the skip-levels understand need to be highlighted and corrected with your direct report (particularly if it is systemic).
When skip-level concerns point to correctable behaviour, the path is simply to raise it with the direct report as a coaching conversation. When it points to character or competence concerns, the same principle applies: raise it directly with the manager, but with the recognition that the conversation shifts from coaching toward performance management. The transparency obligation doesn’t change.
What you should provide in one-on-ones
The first bit of value from skip-level one-on-ones is the coaching you can give to them. Even though the team member should be getting coaching and guidance from their manager, I find that because the tone of skip-level one-on-ones is quite different from direct one-on-ones, which can often be more operational, it allows your skip-levels to think more expansively. The coaching can be around longer-term career thinking, as well as additional ideas for operational concerns.
The other thing that you can provide in skip-level one-on-ones is a broader context around the work the team member is doing, or around your work as a senior leader. For example, how their work aligns with broader business goals and why it is important, or broader engineering concerns.
Ideally, their manager should be providing the broader context to the team member, but there can be signal loss in the communication, meaning that the skip-level one-on-one is a great opportunity to prevent that signal loss by providing context and allowing the team member to ask questions.
The dual-purpose nature of the one-on-ones (getting honest information, but also providing information such as context, coaching, etc) can create a tension, which is most acute before trust is established. As a result, in the earlier period before trust exists, the leader should lean toward the developmental framing explicitly, letting the skip-level dictate the direction of the meeting and allowing the diagnostic value to emerge rather than pursuing it directly.
Cadence
A common concern I hear is that having skip-level one-on-ones will take up too much time. But firstly, not having them can be costly because of the information you miss, and secondly, it doesn’t need to actually take that much time.
Let’s say you have six teams of six people each. If you are having weekly one-on-ones with your direct reports, that’s six hours a week. I like to have 45-minute skip-level one-on-ones, meaning that if you have them quarterly (every 12 weeks), then you end up spending 3 (48 people * 0.75 hours / 12 weeks) hours a week. If you take good notes during the meeting, and minimise or have no prep time (since it is largely a reactive meeting), then these 3 hours become the sum total time. This is not a huge amount of time investment for the value you can gain from them.
This becomes your base-level maintenance cadence. It is quarterly, which helps preserve relationships, and interlacing across your teams so that you are catching up with a different person from the one team every week or two.
In addition to the maintenance cadence, there is also an investigative cadence which is triggered when concerns need deeper probing. That requires ad-hoc one-on-ones to be scheduled with higher frequency to get the necessary information quickly.
In Summary
This article is part 5 of the series on how to build a great Engineering culture. The focus of this article was on how to get feedback on your engineering culture via one-on-ones (specifically looking at how to probe effectively in one-on-ones and how to use skip-level one-on-ones). Article one of this series looked at what an Engineering culture is, article two looked at how to define and articulate the culture, article three looked at how to embed and codify the culture, and article four looked at how to embody and champion your values.
Skip-level one-on-ones are a high-leverage activity to embed and grow your culture, from coaching, mentoring and providing additional context for your skip-level to learning about any cultural or other blindspots you may have.
Raising your own concern first transfers the social risk of disclosure away from your skip-levels entirely, which is what unlocks honesty.
Probing can create the problem you’re investigating. To mitigate this, validate across independent conversations and look for disconfirming evidence, not just confirmation.
Skip-levels tell you things your direct reports structurally cannot. Not because direct reports are dishonest, but because they are too close to their own performance to see it clearly, and too incentivised to manage upward.