Skip-level meetings: agenda, questions and follow-up
A skip-level meeting is when a manager's manager meets team members directly, without their manager there. It works when it builds trust and surfaces what the leader can't see from the top. It fails when it becomes a way to check up on the manager behind their back.
What a skip-level meeting is for
In a one-on-one, a person talks with their own manager. In a skip-level, the leader one level up meets those people directly. GitLab's handbook defines it this way and requires it for any leader whose reports have reports of their own.
The meeting gives team members a direct line to a senior leader. It gives the leader an unfiltered view of how the team is doing.
- Recognize contributions in front of a senior leader.
- Clarify company or department goals and how the team's work fits.
- Hear what is going well, what isn't and what the leader could do differently.
What a skip-level is not
Say this out loud at the start, because people will wonder. A skip-level isn't a performance check on their manager, done by going around them.
It also isn't the place for the work a direct manager owns: setting priorities, career planning or day-to-day decisions. If those topics come up, the leader listens and routes them back to the manager.
How often, and one-on-one or in groups
GitLab's handbook asks for skip-levels at least quarterly. They can be one-on-one or in groups of no more than 10 to 15, so everyone still gets to speak.
A large organization isn't a reason to skip them. Rotate through a new group of team members each quarter instead of meeting everyone every time.
| Format | Works when | Watch for |
|---|---|---|
| One-on-one | The leader has a handful of skips and time for a coffee-chat first meeting | Not feasible once a leader has too many skips to see one by one |
| Small group (up to 10–15) | A team shares a project or a common set of concerns | Quieter people may hold back; ask for written questions beforehand |
| Rotating groups | The organization is too large to meet everyone each quarter | Track who you have met, so nobody is skipped for a year |
A sample skip-level agenda
Make the first one-on-one skip-level a free-form conversation. After that, use a clear agenda: the leader's update first, then ample time for the team. Here is an example for a 55-minute group session.
- Recognition (5 minutes): name specific work each attendee did, prepared beforehand.
- Leader update (10 minutes): strategy, focus areas and any change people will hear about soon.
- Open questions (25 minutes): what the team wants to ask or raise.
- Feedback (10 minutes): what's working, what's in the way, what the leader should change.
- Close (5 minutes): repeat back what you heard and what you'll do about it.
Questions to ask
- What is one thing that would make your work easier next month?
- Which goal of ours is least clear to you?
- Where do you see work being duplicated or dropped between teams?
- What should I stop doing, or do more of?
- What would you want me to know that I'm unlikely to hear otherwise?
Don't record it, but do follow up
GitLab never records skip-level meetings, because the point is trust. People speak more openly when they know there's no recording or transcript. The leader can still keep private notes on themes, not on who said what.
Follow-up is what makes the next one useful. Within a week, tell the group what you heard, what you'll act on and what you won't, and why. Share themes with the direct manager without attributing comments to people.
Using Bridge to prepare, not to capture
Leave Bridge out of the skip-level itself. It is useful in the half hour before it, when you prepare the recognition part of the agenda.
- Ask the workspace Assistant what each attendee presented or delivered last quarter, filtered by participant and date range. Every answer links back to the meetings it came from.
- Open those meetings to check the details before you name anyone's work.
- Keep your own notes in a private document, and share only themes afterward.




