Onboarding & LMS 24 min read

Mentorship and Buddy Systems That Do Not Fizzle

Pairings fizzle for three reasons that have nothing to do with the people: no stated purpose, no end date, and nobody told the buddy manager. Six arrangements reviewed, and why the obvious person to choose is usually the wrong one.

Daniel Brooks Daniel Brooks 24 min read
Mentorship and Buddy Systems That Do Not Fizzle

TL;DR

  • The core decision: which of two different things you're building, because a buddy and a mentor solve different problems and get conflated constantly.
  • When doing nothing is right: when new people already have somebody obvious to ask and they're asking them.
  • What has to be true: the pairing has a purpose somebody can state and a date it's meant to end.
  • How the options split: by whether the relationship is about getting through this month or about the years after it.
  • Decision rule: if the time it takes hasn't been acknowledged by somebody's manager, it will stop happening by week three.
  • Outcome to expect: fewer pairings, better defined, that survive past the first two meetings.

The Pairing That Stopped Meeting

Somebody is assigned a buddy on their first day. They meet, it's friendly, they agree to catch up next week. The next week is busy for both of them. They exchange a message about rescheduling. Nothing is ever put in a calendar again.

This is the standard outcome, and everybody involved feels slightly bad about it. The new person concludes they shouldn't impose. The buddy concludes they let somebody down. Neither is wrong about what happened and both are wrong about why, because the pairing wasn't going to survive regardless of how well-intentioned either of them was.

It failed for three reasons that had nothing to do with the individuals. Nobody said what it was for, so there was no reason to protect the time against anything else. Nobody said when it ended, so every meeting was an open-ended commitment rather than one of a known number. And nobody told the buddy's manager, so the time came out of their own week, which meant it competed with work they were actually accountable for and lost.

Those three omissions explain almost every failed pairing, whether it's a buddy for a new starter or a formal mentoring programme with a launch event and a matching process. The design question is the same in both cases, and it isn't about matching or training or a platform. It's about purpose, duration and whose time this is.

Buddy and Mentor Are Not the Same Job

These get used interchangeably and they're different enough that conflating them breaks both.

A buddy is about getting through the next few weeks. Practical, peer-level, short. How things actually work here, which meetings matter, who to ask about what, whether it's acceptable to interrupt somebody. The value is that a new person will ask a peer things they won't ask a manager, and that category of question is large and consequential. It ends when the person no longer needs it, which is usually a matter of weeks.

Free Weekly Briefing Stay ahead of what's changing in HR and people ops.

Join 4,200+ leaders getting practical insights every week — no fluff, just signal.

Join Free →

A mentor is about the person rather than the period. Longer, usually someone with more experience, focused on how somebody is developing and what they're aiming at. It doesn't have a natural end point, it works badly when assigned, and it has almost nothing to do with onboarding, even though it's frequently introduced as part of it.

The conflation produces two specific failures. A senior person assigned as a mentor to a new starter ends up answering questions about expenses, which wastes their time and embarrasses both. And a peer assigned as a buddy gets asked about career direction, which they're not placed to answer and will either decline or answer badly.

There's a third arrangement worth naming separately, which is a subject-matter guide: somebody experienced in the specific work who helps a new person learn to do it. That's neither a buddy nor a mentor, it's part of how the job gets taught, and it belongs to the team rather than to a programme.

The role What it is for How long Who should do it
Buddy Getting through the first weeks here Weeks, with an end date A peer, recently arrived or nearby
Mentor The person's development over time Open-ended, ideally self-chosen Someone more experienced, not their manager
Subject guide Learning to do the actual work Until they can do it Whoever does that work well

The third row is the one organisations most often leave unnamed, and leaving it unnamed is why it lands on the buddy by default. A buddy asked to teach the work is doing a job they weren't set up for, with none of the time acknowledgement that job would need.

When You Genuinely Do Not Need to Act Yet

Your current setup is genuinely fine. New people have somebody obvious to ask, they're asking them, and nobody has spent a first week uncertain about whether interrupting is acceptable. A programme would formalise something that's working, and formalising working things usually makes them worse.

Friction is starting to show. Somebody described their first weeks as isolating, or a new person went to their manager with questions that a peer would have answered faster, or a team is distributed enough that nobody is nearby by default. A named person is the answer here, and that's a much lighter thing than a programme.

It has become a real cost. New starters are consistently slow to settle, the same basic questions reach senior people, or leavers in their first months describe not knowing who to ask. At that point it's worth designing something deliberately rather than hoping proximity handles it.

The edge case that forces it. Everyone is remote, or the new person is the only one in their location, or they're joining a team whose members are individually very busy. In those situations nothing happens by accident at all, and the informal version that works elsewhere simply doesn't exist here. Something deliberate isn't a nice addition; it's the only version available.

Five Questions This Reader Asks at 11pm

What's the difference between a buddy and a mentor? A buddy helps somebody get through their first weeks in this specific place, is a peer, and finishes in a month or two. A mentor is concerned with the person's development over a longer horizon, is usually more experienced, and works best when the pairing is chosen rather than assigned. Treating them as the same thing produces senior people answering questions about expense claims and peers being asked about career direction.

How do you match people? For a buddy, don't overthink it: proximity to the work, availability and willingness matter far more than personality fit, and matching processes add effort without much return. For a mentor, matching is genuinely hard and assignment works poorly, which is an argument for helping people find their own rather than building an allocation system.

How long should it last? A buddy arrangement should have a stated end, usually somewhere between one and three months depending on the role. Saying when it ends is what makes people willing to commit to it, because an open-ended obligation is harder to agree to than a defined one. Mentoring doesn't end on a schedule, which is one of several reasons it shouldn't be assigned.

Should we pay or recognise people for doing it? Recognise, at minimum, and more importantly make it visible to their manager as part of their work rather than in addition to it. Payment isn't usually the issue; the issue is that the time comes out of a week that was already full, and nothing but a manager's acknowledgement changes that.

Why do these programmes always fizzle? Because the first two meetings happen on enthusiasm and there's nothing underneath them. No stated purpose, no end date, no acknowledged time. When the first busy week arrives, the pairing is the only commitment in either person's calendar with no consequence attached to dropping it.

Five Diagnostic Questions You Can Self-Assess Against

Can both people say what this is for? Ask them separately. If one says it's to help settle in and the other says it's to support their development, you have two people in different relationships, and it'll end awkwardly within a month.

Does it have an end date? If not, every meeting is an open-ended commitment, and open-ended commitments lose to dated ones automatically. An end date also gives both people permission to stop without it being a failure, which is why arrangements with one tend to actually run their course.

Does the buddy's manager know? This is the question that predicts survival better than any other. Time that hasn't been acknowledged by somebody's manager is time taken from work they're accountable for, and no amount of goodwill outlasts that for long.

Who booked the meetings? If the answer is nobody, or the new person, the arrangement is already failing. The new person is the party with the least standing to insist on somebody's time, and leaving the scheduling to them guarantees it stops the first time they feel they're imposing.

What happens if it isn't working? If there's no route out other than one person quietly stopping, that's what will happen, and it'll feel like a failure to both. A stated way to end it early, used without embarrassment, is what makes people willing to try.

Six Pairing Arrangements, Reviewed

An onboarding buddy with a fixed term

A peer assigned for a defined period, meeting regularly, focused on practical navigation. It earns its place because it addresses the single most uncomfortable part of a first month, which is not knowing whether a question is too small to ask. Having one person whose explicit role is to field small questions removes that, and it removes it for the whole category rather than question by question.

Where it falls short is when the term isn't stated, at which point it becomes the fizzling arrangement described above. It also fails when the buddy is chosen for seniority rather than availability, since the value is in being reachable rather than in being knowledgeable.

This is the version worth doing. State the weeks, put the meetings in the calendar at the start, and tell the buddy's manager.

One detail improves it noticeably: make the early meetings frequent and short rather than weekly and long. Twenty minutes every couple of days in the first fortnight matches how questions actually arrive, which is in small clusters that feel too minor to raise on their own but accumulate into a week of low-level uncertainty. Once the questions thin out, the meetings can stretch, and the point at which they naturally thin is a reasonable signal that the arrangement has done its job.

An assigned mentor through a formal programme

People are paired through a process, usually with a launch, a matching stage and some guidance about how to run the relationship. It earns its place on reach: left alone, mentoring relationships form for people who are already well connected, and a programme is the main way to extend them to people who aren't. That's a genuine equity argument and it's the strongest case for the format.

Where it falls short is that assignment works against what makes mentoring work, which is that both people wanted this particular relationship. Assigned pairs meet twice, find the conversation effortful, and stop, and both conclude something slightly unfair about themselves. Programmes also tend to be measured on pairings created rather than pairings still meeting, which hides the failure.

If you run one, make it easy to end a pairing and try another, and say that plainly at the start.

The other thing worth building in is a first conversation with something specific in it. Assigned pairs stall partly because the opening meeting has no content, so both people make conversation and leave without a reason to book another. Giving the pair one concrete thing to discuss, chosen by the less senior person in advance, gets past that and tends to establish whether there's anything here quite quickly.

A mentor the person finds themselves

The organisation helps people identify somebody and approach them, rather than allocating. It earns its place because chosen relationships survive and assigned ones mostly don't, and because the act of choosing means somebody has thought about what they want from it.

Where it falls short is access. People who are new, junior, or not naturally well connected don't know who's available or whether asking is acceptable, which is exactly the group the programme was supposed to help. Left entirely to self-selection, mentoring accrues to people who already have advantages.

The middle path is usually right: make it visible who's willing, make the approach normal rather than exceptional, and let people choose from that.

Making the approach normal is the harder half and it isn't done by saying people are approachable. It's done by the willing people saying publicly that they're available and roughly what they'd be useful for, which converts an awkward request into a response to an offer. The difference in who actually asks, between those two framings, is large.

Peer or reverse pairing

Two people at similar levels supporting each other, or a less experienced person paired with a more senior one to share what the senior one doesn't see. It earns its place because the reciprocity removes the awkwardness of asking for somebody's time, and because reverse arrangements genuinely do transmit things upwards that otherwise never arrive.

Where it falls short is that reciprocal arrangements drift into being social, which is pleasant and isn't what was intended. Reverse pairings also depend on the senior person actually wanting to hear it, and where that's not genuine, the junior person works it out quickly and stops saying anything useful.

Worth trying where there's a specific thing to transmit. Vaguer versions tend to dissolve.

Reverse arrangements have one failure worth anticipating. If the senior person acts on nothing that comes up, the junior one reads that accurately and stops offering anything real, usually within a couple of meetings and without saying so. Acting visibly on one small thing early is what keeps it honest, and it matters more than anything about how the pairing was set up.

Group or cohort arrangements

Several new people meet together, sometimes with one experienced person present. It earns its place because the peer group is often the most durable thing anybody gets from onboarding, and because a group is much easier to sustain than a one-to-one: if two people can't make it, the meeting still happens.

Where it falls short is depth. Nobody raises the thing they're actually worried about in a group of six, and the questions that get asked are the safe ones. It also requires several people to have joined at roughly the same time, which most organisations can't arrange.

Good alongside a one-to-one arrangement. A poor substitute for one.

If you run a group, keep it small and keep the same people in it. Groups that change composition never get past the safe questions, because nobody raises anything uncomfortable in front of a face they haven't seen before, and the whole value of a cohort is the point at which somebody admits they don't understand something everyone else seemed to follow.

Nothing formal, just a named person

No programme, no framing, just telling the new person who to ask and telling that person to expect it. It earns its place on the fact that it's most of the benefit at almost no cost, and that it avoids the main failure of programmes, which is that the structure creates an expectation of significance that the relationship can't carry.

Where it falls short is that it's invisible, so nobody can tell whether it's happening, and it depends on both people being reasonable. It also does nothing for anybody's development beyond the first weeks, which is fine as long as nobody believes otherwise.

For most organisations under a certain size, this is the correct answer, and the honest advice is to do this properly rather than build something larger.

Doing it properly mainly means saying it out loud to both people rather than assuming it's understood. Telling the new person who to ask, and telling that person to expect the questions, takes two sentences and is the whole arrangement. What fails is the version where somebody is told to look after a new starter and the new starter is told nothing, which produces one person waiting to be asked and another waiting to be invited.

The Decision Table

Situation Scale Setup Primary Pain Recommended Starting Point
New people have somebody obvious to ask Under twenty Single site None Change nothing
First weeks described as isolating Any Any Nobody is nearby by default One named person, for stated weeks
Basic questions reaching senior people Any Any No peer-level route A buddy, chosen for availability
Everyone remote or person alone in location Any Distributed Nothing happens by proximity Scheduled contact, booked in advance
Pairings created but not meeting Any Existing programme No purpose, date or time acknowledged Fix those three before anything else
Mentoring only reaching the well connected Over two hundred Any Access, not willingness Publish who is available, normalise asking
Buddy being asked to teach the work Any Any Two jobs merged into one Name a subject guide separately
Programme measured on pairs created Any Formal programme Measuring the wrong thing Count pairs still meeting after two months
Senior mentor answering practical questions Any Any Buddy and mentor conflated Split them, say which is which

The fifth row is where most organisations with a programme actually are. The instinct is to improve the matching or add training for mentors, and neither addresses it. Pairings stop meeting because nothing protects the time, and the fix is stating a purpose, stating an end date, and telling both managers. Those three cost nothing and do more than any redesign.

Why Pairings Fizzle

The failure What the two people experience What would have to change
No stated purpose A pleasant chat with nothing to return to One sentence on what it is for
No end date An open-ended commitment, quietly dropped A stated number of weeks
Time not acknowledged Competing with work they are accountable for The buddy's manager knowing and agreeing
The new person does the scheduling Stopping the moment they feel they impose Meetings booked at the start, by the buddy
Chosen for seniority Someone knowledgeable and never available Chosen for availability and proximity
No way to end it early Drifting, with both feeling slightly guilty A stated route out, used without comment

The fourth row is the one that decides most of these. The new person is the party with the least standing to ask for somebody's time, and leaving the scheduling with them means the arrangement survives exactly as long as their confidence does. Booking every meeting at the outset, from the buddy's calendar, removes the decision entirely, and a meeting that exists gets either attended or cancelled rather than silently forgotten.

The last row matters more than it sounds. Most pairings that aren't working end by drift, because neither person wants to be the one who stopped it, and drift leaves both with a vague sense of having failed at something. Saying at the start that either party can end it, and that ending it early is a normal outcome rather than a problem, makes people considerably more willing to start.

Choosing Who, Which Is Not Who You Think

The instinct is to pick the most impressive person available. That's usually wrong, and predictably so.

Availability beats knowledge. A buddy's value is in being reachable when a small question arises, and a highly capable person with no free time provides nothing the new person can use. Somebody moderately experienced who answers within the hour is more useful than an expert who answers next week.

Proximity to the actual work beats seniority. The questions a new person needs answered are about how things really operate, which is knowledge held by people doing the work rather than by people overseeing it. A senior person's picture of the process is frequently the official one, which is the version that appears in documentation rather than the version anybody follows. A new person who acts on it spends a fortnight discovering the difference on their own.

Willingness matters, but not the way you'd expect. The people who volunteer most eagerly are sometimes already doing a great deal of this, because willingness is visible and gets asked repeatedly. Check what somebody is already carrying before adding to it, because the third informal mentoring relationship is the one that gets dropped. It's also worth asking rather than inferring, since this kind of work is mostly invisible: nobody records that they spend an hour a week helping two people from another team, and the person's own manager frequently has no idea it's happening.

Don't use the manager. The new person's own manager can't be their buddy, because the whole point is having somewhere to take questions they wouldn't take to their manager. This is obvious when stated and gets violated constantly in small teams where the manager is the only obvious candidate. In that situation, look sideways to another team rather than upwards. A buddy from a neighbouring team has a second advantage worth having anyway, which is that they explain the surrounding context the new person's own team assumes.

For mentoring, let them choose. Every piece of evidence anybody has about assigned mentoring points the same way, which is that chosen relationships persist and allocated ones don't. The organisation's job is to make it visible who's willing and to make asking normal, not to run an allocation.

One more consideration that's easy to overlook. Being new is easier when somebody in a similar position is going through it at the same time, and where two people join within a few weeks of each other, introducing them is worth doing deliberately. It costs a sentence, and it produces a relationship neither would have formed, in which the questions are genuinely mutual rather than one person always asking. That symmetry is the part that makes it durable, because neither of them has to decide whether they're imposing on the other, which is the calculation that quietly ends most of the arrangements in this article.

What to Put in Writing

Artefact Who owns it When it is written What it prevents
What this pairing is for, in one sentence Whoever sets it up Before the first meeting Two people in different relationships
When it ends Whoever sets it up At the same time An open-ended commitment, dropped
That the buddy's manager has agreed HR or the manager Before asking the buddy Time competing with accountable work
Who books the meetings, and when The buddy All at once, at the start Scheduling left to the least confident party
How to end it early, without fuss Whoever sets it up Said at the start A drift that feels like failure
Who the subject guide is, separately The team Before the first day A buddy quietly asked to teach the job

The third row is the one most often skipped and the best single predictor of whether the arrangement survives. Asking somebody to be a buddy without telling their manager makes it a personal favour, and personal favours lose to accountable work every time, without anybody deciding that they should.

Questions to Ask Before You Commit

On purpose. What is this for, in a sentence? A bad answer is to help them settle in.

On type. Is this a buddy or a mentor? A bad answer treats them as the same.

On duration. When does it end? A bad answer is when they don't need it.

On time. Does their manager know? A bad answer is that it won't take long.

On scheduling. Who books the meetings? A bad answer is whoever needs one.

On exit. How does somebody stop? A bad answer is that they'd just say.

What Getting This Wrong Costs

The first cost is that the person who most needed it concludes they shouldn't ask. A pairing that fizzles doesn't return somebody to neutral; it teaches them that their questions are an imposition, which is the specific belief the arrangement existed to prevent. They then carry small uncertainties for months rather than resolving them in a sentence, and the cost of that appears later as mistakes that look like carelessness.

The second cost falls on the people who agreed to help. Somebody who accepts a buddy role, finds it competing with work they're measured on, and ends up doing it badly has been set up to feel bad about something that wasn't their fault. Do that a few times and willing people stop volunteering, which removes the informal version that was working before anybody built a programme.

The third cost is the belief that this doesn't work here. Organisations that run a mentoring programme, watch most pairings stop meeting, and shelve the idea have drawn a conclusion from a badly designed trial. The format works when it has a purpose, a duration and acknowledged time, and it fails without them regardless of how good the people are.

So before designing anything, be clear which of the three roles you actually need. If new people don't know who to ask, you need a buddy and you need it for weeks rather than indefinitely. If they can't do the work yet, you need a subject guide and that belongs to the team. If somebody wants to talk about where they're heading, you need a mentor and you shouldn't assign one.

When You Are Ready to Go Further

None of this needs a platform. It needs a named peer, one sentence about what it's for, a date it ends, both meetings booked from the buddy's calendar, and the buddy's manager knowing about it.

The step beyond that, if you're running something larger, is to change what you measure. Most programmes count pairings created, which is the number that looks best and says least. Counting pairings still meeting after two months tells you whether the thing works, and it usually delivers an uncomfortable answer that points directly at purpose, duration and time rather than at matching.

HROpsLab publishes independent comparison work across HR tooling, applicant tracking and payroll. We sell nothing, we take no vendor money, and we publish no paid placements. If the next step is looking at what your current tooling actually supports here, our comparison work is one place to start.


Frequently Asked Questions

What is the difference between a buddy and a mentor?

A buddy helps somebody get through their first weeks in a specific place: practical, peer-level, focused on how things actually work and who to ask about what, and finishing after a stated period. A mentor is concerned with the person's development over a longer horizon, is usually more experienced, and works best when the relationship is chosen rather than allocated. Conflating them produces two familiar failures: senior people answering questions about expense claims, and peers being asked about career direction they aren't placed to advise on.

How do you set up a buddy system for new hires?

Name a peer who's available rather than the most impressive person you can find, state in one sentence what the arrangement is for, state when it ends, and have the buddy book every meeting at the start rather than leaving the scheduling to the new person. Then tell the buddy's manager, because time that hasn't been acknowledged competes with work they're accountable for and loses. Those five things take about ten minutes and account for most of the difference between arrangements that run their course and ones that stop after two meetings.

Why do mentoring programmes fail?

Almost always because nothing protects the time. The first two meetings happen on enthusiasm, and when a busy week arrives the pairing is the only commitment in either calendar with no consequence attached to dropping it, so it goes. Underneath that sit three specific omissions: no stated purpose, so there's nothing to protect the time against; no end date, so every meeting is an open-ended commitment; and no acknowledgement from either manager, which makes the whole thing a personal favour rather than part of anybody's work.

How long should an onboarding buddy arrangement last?

Somewhere between one and three months, decided in advance and stated to both people. The specific length matters less than the fact that there is one, because an open-ended commitment is harder to agree to and easier to abandon than a defined one. An end date also gives both parties permission to stop without it feeling like a failure, which is why arrangements with a stated finish tend to actually reach it. Extend it afterwards if both want to, which is a different and much easier conversation.

Should you assign mentors or let people choose?

Let people choose, with help. Assigned pairings work against the thing that makes mentoring function, which is that both people wanted this particular relationship, and allocated pairs commonly meet twice and stop with both feeling vaguely at fault. The problem with pure self-selection is access: people who are new, junior or not well connected don't know who's available or whether asking is acceptable, which is precisely the group a programme was meant to reach. Publishing who's willing and making the approach normal handles both.

Who should be a new hire's buddy?

Someone available, close to the actual work, and not their manager. Availability matters more than expertise, because the value is in answering a small question within the hour rather than in knowing the most. Proximity to the work matters more than seniority, since senior people often hold the official version of a process rather than the real one. And it can't be the manager, because the point is having somewhere to take the questions somebody wouldn't take to their manager, which in a small team means looking sideways to another team.

Should buddies or mentors be compensated?

Payment is rarely the real issue and acknowledgement usually is. What makes these arrangements survive is the person's own manager knowing about it and treating it as part of their work rather than as something extra, because otherwise the time comes out of a week that was already full. Where you want to recognise it, recognising it visibly to the people who decide about progression is worth more than a payment, and reducing something else in the weeks concerned is worth more than both.

How do you run a buddy system when everyone is remote?

More deliberately, because nothing happens by proximity and the informal version simply doesn't exist. Book the meetings in advance rather than agreeing to catch up, since an unscheduled catch-up between two remote people almost never occurs. Make the contact more frequent and shorter at the start, because the small questions that would have been asked across a desk accumulate otherwise. And say explicitly to both people that interrupting outside the scheduled times is expected, or the new person will save everything up and ask nothing.

A pairing needs a purpose, a date it ends, and somebody's manager knowing about it. Without those three, goodwill lasts about two meetings, and everybody involved blames themselves for something that was decided at the design stage.

Share on X Share on LinkedIn

What to do next?

Explore More Articles

Dig deeper into HR Ops strategy, tools, and workflows built for real teams.

Browse the blog →
Join the HROpsLab Community

Connect with People Ops practitioners sharing real workflows, tools, and challenges.

Join now →