Skip-level meetings for engineering leaders: how to run them with managers, tech leads and contractors

A skip-level meeting is a one-on-one between you and an engineer who reports to someone who reports to you, held without that middle manager in the room. In an engineering org it works when you ask about delivery, on-call, tooling and AI use instead of "how's it going," tell the manager before you start, and bring back themes rather than names. For the wider set of leadership topics, see Engineering management guides for CTOs and VPs of Engineering.

What is a skip-level meeting in an engineering org?

MeetGeek's skip-level guide calls it a conversation between an employee and their manager's manager, without the direct manager. It also lists what the meeting isn't: a backdoor performance review, a surprise audit of the manager, and a place to make major decisions on the spot. Nothing gets approved, reassigned or promised in the room.

The skipped layer in engineering is probably wider than the org chart suggests. It's the engineering manager, but also the tech lead or team lead who runs a squad without formal reports and shapes how work actually flows. If your engineers take direction from a lead who isn't their line manager, that lead is in the skipped layer too, and you should treat them that way when you brief them.

The research is thin on how this lands with managers. A 2025 ECMLG conference paper, Blacher's "Being Bypassed" study, studied 25 first-level engineering managers at US technology organisations. It's a work-in-progress paper, and its abstract reports "surprisingly broad support and implementation" of skip-levels, with perceptions varying by culture, generation and meeting format. That's one exploratory qualitative study, so read it as a reason to ask your own managers how they feel about it, not as a verdict.

Who should you skip-level, and what about contractors and nearshore engineers?

Skip-level the people whose work feeds your delivery risk. That includes employees and, in our judgment, long-term augmented or nearshore engineers who work daily inside your team, attend your standups and ship to your repositories. Payroll status is a poor filter. If a contractor owns the payments service, you need to hear what slows them down as much as you'd want to hear it from an employee.

We found no published skip-level guidance on contractors or agency engineers, so what follows is judgment, not best practice.

The reporting line stays where it is. A contractor's manager is the vendor's team lead or delivery manager, and that person gets the same heads-up an internal manager would. If the contract names a vendor account manager, ask their permission before you start. Keep the conversation to the work: delivery friction, tooling, access, how the in-house team treats requests for help. Don't discuss pay, contract terms or the performance of any individual, including the engineer in front of you.

If something in the conversation points at one contractor underperforming, that goes through the vendor, not through the skip-level. When a contractor is the one underperforming covers that route, and managing a blended distributed engineering team covers the communication setup that makes contractors easier to reach in the first place.

How often and how long?

The published guidance differs, and none of it cites evidence for its figures. These are vendors and bloggers stating their own preferences:

Diaz acknowledges that many engineers see skip-levels as a waste of time, blames how they're run, and argues that box-ticking is "even worse than not having them at all". Our view is that a quarterly meeting you run well beats a monthly one you rush.

How to run a skip-level meeting

1. Tell the manager first

Before the first meeting, tell each affected manager and tech lead what you're doing and why. MeetGeek's guide says to brief direct managers first, and we'd go further: say it in a one-on-one, not in a Slack post.

Cover three things. You're doing this to hear about delivery and tooling problems that rarely reach you. You'll share themes with them afterwards, never attributed quotes. And you won't decide anything in these meetings or overrule them because of what you hear. A manager who hears that up front is less likely to treat it as surveillance.

2. Pick the cohort and send a short agenda

Start with one group, not the whole org. MeetGeek suggests piloting 6-10 meetings in a single group before extending, which is enough to see whether the format produces anything.

Send the agenda ahead of time. Read AI says at least a week, and recommends 3-5 topics. Name the topics (release friction, on-call, tooling, what's working) and invite the engineer to add theirs. If the only agenda item is yours, you'll get a polite half hour.

3. Open with the engineering questions

Spend the first few minutes on the engineer's work, not on your agenda. Ask what they shipped recently and what nearly didn't ship. Then move to the question set below. Specific, event-based questions tend to get answers. "What slowed your last release?" tends to get a story. "Any blockers?" tends to get "no."

4. Listen, don't fix

Take notes and ask follow-ups. Don't solve problems in the room, don't say "I'll talk to your manager about that," and don't rate the manager, even when invited to. If an engineer asks what you think of their lead's decision, say you'd rather hear how it affected their work.

The one exception is a fix that's yours to make and doesn't touch the manager's territory: a missing access grant, a tool licence. You can say "I'll sort that today."

5. Write down themes within 24 hours

Read AI recommends sending a summary within 24 hours, and the habit is worth copying for your own notes. Within a day, write each point as a theme with a count: for example, "four of six engineers lose time to a 40-minute CI queue" (an illustrative figure, not data). Strip names, and strip anything that identifies someone by role if the group is small. Keep a separate, private line for items that fall outside themes.

6. Take themes to the manager as a pattern

Bring the themes to the manager within a week. MeetGeek advises sharing themes, not quotes, and Read AI advises team-level patterns rather than individual complaints. That keeps the manager out of a hunt for who said what.

A script that works: "I held skip-levels with the platform group. Three themes came up. One, CI queue time. Two, the runbook for the payments pager is out of date. Three, nobody's sure which AI tools are approved. I'd like you to own the first two, and I'll take the third. What would you change about how I framed these?"

Note the last question. It treats the manager as the owner of their team's follow-up, which is the point.

7. Close the loop with the engineer

Within a few weeks, tell each engineer what changed or why nothing did. "We cut the CI queue by moving to larger runners" is a good message. "We looked at it and can't prioritise it this quarter" is also fine. Silence isn't. It's how skip-levels turn into the box-ticking Diaz warns about.

Skip-level questions for engineers

Pick four or five. These are template content, so adapt the wording.

Delivery friction

• What slowed your last release?
• Which review, CI or approval wait costs you the most time in a week?
• What did you rework that you shouldn't have had to?

On-call

• How often were you paged out of hours last month?
• Is the runbook for the service you cover current? When did you last use it?
• What would make the next page easier to handle?

Tooling

• What would you remove from your stack? What would you buy?
• Which internal tool do you avoid, and why?

AI tool use

• Which AI tools do you use daily?
• What are you not allowed to use that you'd like to?
• Where has an AI tool cost you time or produced something you had to throw away?

Team and manager support

• Tell me about the last time you got stuck. Who helped, and how long did it take?
• What decision from the last quarter would you want explained better?

Contractors and nearshore engineers

• What stops you from asking the in-house team for help?
• Which meetings or channels do you wish you were in?

We left out "How is your manager?" on purpose. Evaluating the manager is the non-purpose we mentioned earlier, and events give you the same information without putting the engineer on the spot.

How to act on what you hear without undermining the manager

Sort every item into one of three piles before you do anything.

The first pile is yours to fix: tooling licences, access, a vendor you control, an approval you're sitting on. Do those fast and say so. Fast visible fixes are what make engineers believe the next meeting is worth their time.

The second pile is the manager's: process, prioritisation, on-call rotations, team norms. Hand these over as themes, with the manager owning the response. In our judgment, this is the step that decides whether skip-levels strengthen your managers or hollow them out. If you start dispatching fixes into a manager's team, they'll stop surfacing problems to you.

The third pile is escalation, and it's small: safety concerns, harassment, legal exposure. Stop the conversation, follow your HR or legal process, and don't promise confidentiality you can't keep.

Never reverse a manager's decision because of something you heard in a skip-level. If you think a decision was wrong, take it to the manager directly, with your reasoning, as a conversation between the two of you.

Where themes land: on-call complaints belong in setting up an on-call rotation for a nearshore team, and the AI tool questions feed a plan for measuring AI coding tools, which tells you whether the tools people say they use are paying off.

What this means for your team practice

The decision is whether you run skip-levels at all, with whom, and who owns the follow-up. Our judgment is to start small: pilot 6-10 meetings in one group, as MeetGeek suggests, with that group's manager briefed, and put a review on the calendar for 90 days out. At the review, count themes raised, fixes shipped and managers who say it helped or hurt. If managers report it as surveillance, fix the briefing before you extend it.

Decide up front that you own the loop with engineers and the managers own the loop with their teams. Without that split, skip-levels produce notes and no change.

Decide the contractor question explicitly as well. Either embedded long-term contractors are in the pilot, with the vendor lead informed, or they're out. Drifting into it leaves the vendor guessing.

Recurring friction themes, such as slow builds or flaky tests, belong in a register with an owner and a cost. Turning delivery friction into a debt register shows how to do that and how to get it funded.

FAQ

Should the manager attend a skip-level meeting?

No. The definition of a skip-level is that the direct manager isn't there. What the manager should have is advance notice of what you're doing, what you'll do with what you hear, and a debrief afterwards covering themes.

How often should a VP of Engineering hold skip-levels?

Published guides disagree. MeetGeek says quarterly, tightening to every 6-8 weeks during rapid change, and Read AI says most run quarterly, some monthly. Diaz treats monthly as the ceiling. None of them cites evidence. Our judgment is to pick quarterly per engineer, tighten during reorganisations or incident-heavy stretches, and stop if you find yourself rushing.

Can contractors join skip-levels?

In our judgment, yes for embedded, long-term contractors who work daily inside your team, provided you inform the vendor lead first and ask permission if the contract names an account manager. Keep the topics to the work. We know of no published norm either way.

What should you never ask in a skip-level?

Don't ask engineers to rate their manager, don't discuss individual pay, and don't ask for opinions on the performance of a named colleague. Questions about events ("what slowed your last release?") get you the same information without turning the meeting into a review.

What if the engineer reports a serious problem?

Stop and listen, then follow your HR or legal process. Don't promise confidentiality, because you may not be able to keep it. Our view is that safety, harassment and legal issues are the one category where you act on a single report instead of waiting for a theme.