TL;DR
- A buddy exists to make asking cheap. That is the whole job, and schemes fail when it gets expanded.
- A buddy is not a mentor, not a trainer and not the manager. Conflating these produces a role nobody can fulfil.
- Match on proximity and availability, not on seniority or similarity of job title.
- Six to eight weeks with a defined end works better than an open ended arrangement that quietly lapses.
- The most common failure is an enthusiastic volunteer with no time, which looks like a good match and is not.
- A buddy covers perhaps a fifth of the week. Something has to answer the documented questions in the other four fifths.
A company runs a buddy scheme. Every new starter is assigned somebody, the assignment is made the week before, and an email introduces them with a short note about what the role involves.
Six weeks later, asked how it went, most starters say it was fine. Pressed, a consistent picture emerges: they met once in the first week, the buddy was helpful, and then neither of them initiated anything further because it was not clear whether they were supposed to, and both were busy.
Nothing failed. Nobody behaved badly. The scheme produced one useful conversation per starter and consumed a reasonable amount of organisational goodwill to do it. The real issue is that a buddy scheme is usually designed as a pairing and experienced as a permission, and nobody specifies what the permission covers.
Best tools for HR Operations
What a buddy is actually for
The job is to lower the cost of asking. That is it.
A new starter runs a calculation before every question: is this a reasonable thing not to know, will asking make me look slow, is this person busy, could I work it out myself. That calculation suppresses most questions, and the consequences compound, because the questions that go unasked are replaced by guesses that have to be corrected later.
A buddy resolves the calculation by pre-authorising it. There is one named person for whom answering obvious questions is explicitly the job, which means asking them costs nothing socially. The value is not the answers, which are frequently available elsewhere. It is that the asking becomes free.
Once you hold that definition, most design questions answer themselves. The buddy needs to be available rather than expert, approachable rather than senior, and nearby in the practical sense of being someone the starter will encounter anyway.
And the definition tells you what the role is not. A buddy is not responsible for the person's development, their training, their first project, or any assessment of how they are doing. Each of those belongs to somebody else, and attaching them to the buddy is how a simple arrangement becomes a job nobody wants.
| Role | Responsible for | Timeframe | Chosen for |
|---|---|---|---|
| Buddy | Making asking cheap | 6 to 8 weeks | Availability and proximity |
| Manager | Expectations, work, feedback | Ongoing | The role |
| Mentor | Development and career | Months to years | Experience and fit |
| Trainer | Specific skills | As needed | Expertise |
| Onboarding owner | The process itself | Per cohort | Accountability |
When a buddy scheme is not the answer
If the underlying problem is that nobody has capacity, a buddy scheme adds load. Assigning a busy person to support a new starter does not create time, and the predictable outcome is a pairing that exists on paper and not in practice, plus a volunteer who feels guilty.
If the questions are documented, a buddy is an expensive retrieval mechanism. Using a colleague to answer where the expense form lives works and costs two people's attention. If most of what gets asked is already written down somewhere findable, fix the findability first and let the buddy handle what genuinely needs a person.
If your team is very small, it already exists informally. In a team of eight the new person has a buddy whether or not you name one, and formalising it adds ceremony. The exception is when the team is small and distributed, where the informal version does not happen on its own.
And the case that argues the other way. In a fully remote team, a buddy is substantially more valuable than in an office, because the incidental contact that normally produces this relationship does not occur. Remote teams that skip it on the grounds that it feels artificial are removing the one mechanism that replaces something they have already lost.
There is a fifth situation that is easy to miss and worth checking for. If your last few starters were all confident, sociable people who settled quickly, you may conclude that no scheme is needed, and the evidence genuinely supports that conclusion for those people. The question is whether the next starter will be like them. A process that relies on the new person being comfortable initiating contact works perfectly until it meets somebody who is not, at which point it fails silently and the explanation reached for is about the individual rather than about the absence of a mechanism. Small samples of confident hires are the most common reason good teams decide they do not need this, and the cost shows up one or two hires later.
Matching, and why the obvious criteria are wrong
Most schemes match on job similarity or on seniority, and both are worse than the alternatives.
Matching on job similarity sounds right and produces a buddy who is the person most likely to be busy with the same deadlines. It also narrows the starter's network to the team they already sit in, which is the part of the company they will learn about anyway.
Matching on seniority is worse. A senior buddy makes asking expensive, which defeats the purpose entirely. A starter will not use a senior person as their source of obvious questions, because the social cost that the scheme exists to remove is highest with exactly that person.
Match on availability first. The best buddy is somebody with genuine slack in their week who is willing. This is a scheduling question rather than a judgement about people, and asking managers who on their team actually has capacity this month produces better matches than any profile based pairing.
Then on proximity. Someone the starter will encounter naturally, in the same channels, the same meetings, the same working hours. A buddy in a different timezone is a correspondent rather than a buddy.
Then on recency. Somebody who joined six to twelve months ago is often the ideal choice. They remember what was confusing, they have not yet forgotten the vocabulary problem, and the status gap is small enough that asking them costs nothing. They are also usually pleased to be asked, having recently been on the other side of it.
The one criterion worth ignoring entirely is how knowledgeable somebody is, which is the thing most schemes optimise for. A buddy who knows everything will answer every question correctly and the starter will still not ask, because expertise and approachability are largely unrelated and the obstacle was never the availability of answers. Somebody who knows eighty per cent and will cheerfully say they are not sure about the rest produces far more questions, which is the actual objective. If the choice is between the person who knows most and the person who is easiest to interrupt, take the second one every time, and let the documented answers come from somewhere that does not have feelings about being asked twice.
Giving the buddy something to do
The single most common failure is a pairing with no defined activity, which decays into one meeting and a standing offer nobody takes up.
The fix is three scheduled touchpoints rather than an open invitation, because an open invitation requires the starter to initiate, and initiating is exactly the behaviour they find expensive. Specify them: a conversation in the first two days, one at the end of week two, and one at week six to close the arrangement.
Give each one a purpose that is not just checking in. The first is practical orientation: who is who, which channels matter, what the rhythm of the week is. The second is the one that produces the most value and is most often skipped, and the question is what have you been unsure about and not asked. The third is a handover, where the buddy confirms the person knows where to go now that the arrangement is ending.
Beyond those three, the buddy's role is passive availability, and that is correct. The scheduled contact exists to establish the relationship so the unscheduled asking becomes possible.
Tell the buddy explicitly what is not their job. Without that, conscientious people expand the role, start worrying about the starter's progress, and end up doing a version of management they were not asked for and are not equipped to do. A short written description of the role, given to both people, prevents almost all of this and takes ten minutes to write once.
One further detail about those three conversations is worth getting right, which is who books them. If the buddy is asked to arrange them, roughly half will happen, because arranging is a small task competing against real work and it has no deadline. If whoever runs onboarding puts all three in both calendars at the point of assignment, nearly all of them happen, because declining a meeting that already exists requires more effort than attending it. This is a trivial piece of administration and it is the difference between a scheme that functions and one that produces a single conversation per starter, which is the outcome described at the top of this article.
Measuring something that resists measurement
Buddy schemes are unusually hard to evaluate, because the outcome is an absence: the question that got asked instead of guessed, the misunderstanding that did not propagate. None of that leaves a trace.
The temptation is to measure activity, counting meetings held or pairings assigned, and those numbers are available and nearly worthless. A scheme with one hundred per cent assignment and no second conversations scores perfectly.
One number does most of the work and almost nobody collects it: for how many pairs did the second scheduled conversation actually happen. It is a direct measure of whether the relationship took, it is trivially countable, and it is usually far lower than anybody expects on first measurement. If that number is below about seventy per cent, the scheme is a list of assignments and no amount of further design matters until it is fixed.
Two qualitative checks are worth running alongside it. Ask starters at week six who they actually went to when they were stuck, and count how often the answer is their buddy rather than somebody else. A low figure is not necessarily a failure, since finding a better person is a reasonable outcome, but it tells you whether the matching is working.
And ask buddies what they had to explain that should have been written down. This is the single most useful output of the whole arrangement and the one almost nobody collects, because it converts a soft scheme into a concrete documentation backlog produced by people who just watched somebody fail to find something.
What to avoid is attaching the scheme to retention or satisfaction figures. The effect is real and far too small to detect at normal hiring volumes, so the attribution will be noise, and a scheme defended on a number it cannot support is a scheme that gets cut when the number moves the wrong way for unrelated reasons.
Ending it deliberately
Buddy arrangements that have no end date do not end. They lapse, which is a worse outcome than ending, because lapsing leaves both people slightly unsure and the starter without a clear replacement route.
Six to eight weeks is the right duration for most teams. It is long enough to cover the period where asking is expensive and short enough that the buddy can commit to it honestly. The specific end matters more than the specific length.
The closing conversation should do one thing: establish where the starter goes now. Not as a formality but as a genuine handover, naming who to ask for what, now that the single pre-authorised person is no longer designated. Without this, the end of the scheme reintroduces exactly the calculation it existed to remove, several weeks later and with less excuse to ask.
There is a reasonable variant worth knowing. Some teams convert the buddy into an ongoing informal relationship at the end if both parties want it, and this works, provided it is a choice rather than a default. The difference is that a chosen continuation has no obligation attached, so neither person feels they are failing when it fades.
And ask the buddy for feedback, once, at the end. The question that produces the most useful answer is what did you have to explain that should have been written down. The person explaining things to a new starter is the person best placed to notice gaps in documentation, and almost nobody asks them.
What the starter is allowed to ask
A detail that sounds too small to matter and reliably changes how these arrangements go: new starters do not know what is in scope.
Told they have a buddy for questions, most people form a conservative view of what counts. Work questions, obviously. Process questions, probably. Whether it is acceptable to decline a meeting, almost certainly not. Whether the quiet response to something they said means anything, definitely not. So the questions that actually occupy their attention stay unasked while the buddy answers things that were in the handbook.
Being explicit about scope resolves this immediately and costs a sentence. The scope worth stating is broad: anything you would ask a friend who happened to work here, including things that feel too small, too obvious or too social to raise formally. That framing gives permission for the category that matters, which is the unwritten social information nobody documents and everybody needs.
It also helps to name a few examples, because abstract permission is less usable than concrete instances. Whether people actually take the full lunch break. Whether finishing on time is normal. What the convention is for declining an optional meeting. Whether a particular person is always that brief. Listing four or five of these in the role description does more for the relationship than any amount of encouragement.
There is a related point about what the buddy should do with what they hear. A starter may disclose that they are struggling, or confused about something they feel they should understand, and the buddy needs to know whether that goes to the manager. The answer should be that it does not, by default, unless the starter wants it to, and the buddy should say so unprompted. Without that assurance the relationship becomes a reporting line in the starter's mind and the useful conversations stop.
The exception, which should also be stated, is anything about safety or wellbeing, where the buddy should pass it on and say that they are doing so. Being clear about the one exception is what makes the general assurance credible.
Preparing the buddy, which nobody does
Buddies are assigned and almost never briefed, which means the quality of the arrangement depends entirely on how naturally good at it the person happens to be.
The briefing that works is short and covers four things. What the role is for, in the terms described above, because most people assume it is about transferring knowledge and it is not. What is explicitly outside it, which prevents conscientious people expanding into territory that belongs to the manager. The three scheduled conversations and what each is for. And one piece of advice that changes behaviour more than the rest combined.
That advice is to volunteer information rather than waiting to be asked. The entire premise of the role is that the starter will not ask, so a buddy whose strategy is availability has adopted the approach least likely to work. The version that works is proactive and specific: mentioning that a particular meeting is optional despite appearances, that a given channel is where decisions actually get made, that a person who seems unresponsive is simply in a different timezone.
It also helps to tell buddies what they are allowed to say. A great deal of the useful content here is mildly unofficial, such as which processes are followed strictly and which are formalities, and a buddy who is uncertain whether candour is permitted will default to repeating the official version, which the starter could have read. Explicitly authorising honesty about how things actually work is the difference between a buddy and a second copy of the handbook.
Finally, tell them that the starter not asking anything is not a sign that things are going well. Most buddies interpret silence as success, because that is the natural reading, and it is the opposite of what is usually happening.
What the buddy is for in a remote team
Everything above applies more strongly when nobody shares a room, and three things change enough to need separate handling.
The first is that the relationship has to be manufactured rather than allowed to form. In an office a buddy and a starter will encounter each other repeatedly without planning it, and the relationship accrues from those encounters. Remotely there are no encounters, so the three scheduled conversations are not a scaffold around an organic relationship; they are the relationship. That makes their design more important and makes skipping the second one more costly.
The second is that the asking channel matters. A question sent as a direct message is more effortful than turning to somebody, because it is written, it is permanent, and the lack of an immediate response is ambiguous in a way that a physical pause is not. The repair is for the buddy to establish early that short, unpolished messages are fine and that a delayed reply means nothing. Saying this once, explicitly, removes a surprising amount of friction.
The third is timezone, which quietly destroys more remote buddy pairings than anything else. A pairing with four hours of overlap is workable and a pairing with one is not, regardless of how well matched the people are. Treat overlap as a hard constraint during matching rather than something to be worked around later, because the failure is not visible until the starter has already learned to stop asking.
One addition is worth making for distributed teams specifically: a second, lighter contact in the opposite direction. Asking the buddy at week three how they think it is going catches the pairings that have quietly stopped, which the starter will not report because they will assume it is normal.
What covers the rest of the week
A buddy is available for perhaps a fifth of the working week in practice, and the questions do not arrange themselves to fit.
This is where the honest limits of the arrangement matter. A starter with a question at eight in the evening, or during a period when the buddy is heads down, or on a day the buddy is off, is back to the original calculation. In most teams the shortfall is covered by asking whoever is nearest, which spreads the load unevenly and usually onto the same two helpful people.
The practical response is to separate the question types. Questions that are documented should be answerable without a person at all, which is a documentation and retrieval problem. Questions that need judgement, context or reassurance need a person, and that is what the buddy is for. A scheme that uses a colleague's time for the first category is burning goodwill on something a document could do.
Matram is our own product, stated here rather than buried, and it covers only the first category. It reads your documentation and answers questions in the channel people already use, which means the documented questions stop consuming a buddy's attention. Pricing is flat at $29, $69 and $199 a month with unlimited seats and a 30 day trial needing no card.
Its limits are the point in this context. It has no free tier, it is not an HRIS so it holds no records and runs no approval chains, and its actions reach HubSpot, Zendesk and webhooks only. WhatsApp is coming soon rather than available. Most relevantly here, it does nothing whatsoever for the part of the buddy relationship that actually matters, which is one human being available to another. Anybody positioning a tool in this category as a replacement for a buddy has misunderstood what the buddy was doing.
BambooHR publishes Core at $10.25 per employee per month, Pro at $17.50 and Elite at $25 above twenty five employees. It can assign and track a buddy as a task with an owner, which handles the administrative half, and its Pro tier bundles an assistant answering from your own policies. Where it struggles is that assignment is the easy part and the scheme fails in the behaviour rather than in the record.
Rippling starts from $8 per employee per month plus a monthly base fee. Its relevance here is indirect: by removing day one provisioning failures it reduces the share of buddy time spent on problems that were never about knowledge.
Workday publishes no public rate, its pricing URL returning a 404, so any figure attributed to it is an estimate. Enterprise scale, quarters to implement.
Enboarder is the closest fit among the specialists, because it is built around sequencing contact points and prompting the humans involved, which is precisely where buddy schemes fail. It publishes no price. Where it struggles is that prompts without a defined role produce reminders to do something nobody has specified.
Leena AI and Moveworks publish nothing, and the Moveworks pricing page carries a Forrester study rather than a rate card.
| Tool | Published price | Relevance to buddy schemes | Where it struggles |
|---|---|---|---|
| Matram | $29, $69 or $199 flat | Removes documented questions | Nothing human, no free tier |
| BambooHR | $17.50 per employee per month | Assignment and tracking | Assignment is the easy part |
| Rippling | From $8 plus a base fee | Removes day one failures | Indirect, platform scale |
| Workday | None published | Enterprise consistency | Quarters to implement |
| Enboarder | None published | Prompts the humans | Needs a defined role first |
| Leena AI | None published | Answers questions | Procurement cycle |
| Moveworks | None published | Answers questions | Only an ROI study is public |
The decision table
| Situation | Scale | Setup | Primary Pain | Recommended Starting Point |
|---|---|---|---|---|
| Small co-located team | Under 10 | Informal | None | It already exists, leave it |
| Remote team of any size | Any | Distributed | No incidental contact | A buddy with scheduled touchpoints |
| Buddies assigned, nothing happens | Any | Scheme exists | No defined activity | Three scheduled conversations |
| Buddies overloaded | Any | Scheme exists | Documented questions | Retrieval for the documented half |
| Same people always volunteer | Any | Scheme exists | Concentration | Match on capacity, rotate |
| Cohort hiring | Any | Any | Consistency | One buddy each, not one for four |
Recognising the load, and sharing it
Being a buddy is work, and because it is informal it is both unmeasured and unrewarded, which produces a predictable set of problems.
The load concentrates. Volunteers are self selecting, so the people who say yes are the ones who already say yes to everything, and they are usually also the people absorbing informal questions from the rest of the team. A scheme that assigns on willingness will route most of its demand to a small number of people who are already carrying the undocumented support burden, and nothing anywhere records this.
It also competes directly with delivery work. A buddy conversation displaces an hour that was committed elsewhere, and in a team under pressure the conversation is what gives way, not the deadline. Nobody decides this; it just happens, and the person it happens to feels slightly bad about it each time.
Three adjustments help. Assign on capacity rather than willingness, which means asking managers who genuinely has slack rather than asking the room. Keep a simple record of who has done it recently and rotate deliberately, because without a record the rotation will not happen. And make it visible in whatever process acknowledges contribution, so that somebody who has supported three starters this year has that recognised somewhere, however lightly.
The acknowledgement matters more than the magnitude. Most of the resentment that builds around these schemes comes from the invisibility rather than from the effort, and a manager who knows their team member is doing this and says so removes most of it at no cost.
There is one further consideration worth naming. The people most often asked to be buddies for starters from underrepresented groups are the small number of people who share that characteristic, and they are asked repeatedly. This is well intentioned and it concentrates an additional, unacknowledged burden on exactly the people with least slack to absorb it. If you are matching deliberately for that reason, ask first, and count how often you have asked the same person.
When the pairing does not work
Some buddy pairings simply do not take, and the usual organisational response is to leave them alone and hope, which is the worst available option.
The reasons are mostly mundane. The two people do not get on particularly, which is nobody's fault and is not fixable by effort. The buddy's workload changed in the second week. Their working patterns do not overlap as much as the calendar suggested. The starter finds somebody else more natural to ask and the formal pairing becomes redundant.
None of these is a performance problem and treating them as one guarantees nobody mentions them. What is needed is an explicit, low drama route to change the arrangement, stated at the outset to both people: if this is not working, say so to whoever runs onboarding and it will be swapped with no explanation required.
Saying this in advance is what makes it usable. Without the prior statement, raising it in week three means criticising a colleague to a third party, which almost nobody will do, so the pairing persists nominally and provides nothing.
The week three check mentioned earlier is the mechanism that surfaces this, and it should ask the buddy as well as the starter, separately. Asking only the starter means asking the more junior and less secure party to evaluate a colleague, which produces the polite answer every time.
And when a swap happens, handle it as administration rather than as an event. The original buddy should be told plainly that pairings get changed routinely and that it reflects nothing on them, because the alternative is somebody quietly concluding they were bad at it and declining next time.
The cost of getting this wrong
The visible cost of a weak buddy scheme is small, which is why it persists. One conversation per starter, some goodwill spent, nothing obviously broken.
The real cost is that the organisation believes the problem is solved. A scheme exists, people are assigned, and the question of whether new starters have somebody to ask is considered answered. So when a starter struggles quietly for six weeks, the explanation reached for is about them rather than about a pairing that produced one meeting in February.
The second cost falls on the volunteers. Buddy duties concentrate on the same helpful people, because they are the ones who say yes, and nothing records the load. Those people are also usually the ones absorbing informal questions from everybody else, so the burden is doubled and invisible. The eventual outcome is one of them declining, which reads as a change in attitude and is actually a correction.
The third is on the starters least likely to initiate. A scheme that depends on the new person reaching out works well for confident people and not at all for anybody else, which means it quietly delivers its benefit to those who needed it least. Scheduled contact rather than standing availability is the entire fix, and it is the thing most schemes omit.
So the question worth asking is not whether you have a buddy scheme. It is whether, for your last five starters, a second conversation happened, and who initiated it.
Buddies for a cohort, and for people who are not new to work
Two variations come up often enough to deserve their own treatment, because the default design handles neither well.
Cohorts. The tempting economy is to assign one buddy to four starters, and it fails for a specific reason. A buddy serving four people is visibly busy, which reintroduces exactly the calculation the role exists to remove. The starter can see that three other people also need this person, so asking becomes an imposition again, and the quietest of the four stops asking first.
Assign one each, even where that means stretching to find four willing people. If capacity genuinely does not allow it, a better compromise than one-to-four is pairing two starters with one buddy and being explicit that this is the arrangement, because a shared buddy that is acknowledged is less inhibiting than one that is obviously overloaded.
The cohort does supply something useful on its own, which is that its members will ask each other the questions they are most embarrassed by. That is genuinely valuable for the social uncertainty, and useless for factual questions, since none of them knows anything yet. A cohort without buddies tends to produce confidently shared misunderstandings.
Senior hires and internal moves. The default assumption is that these people do not need a buddy, and it is usually wrong in both cases for different reasons.
A senior external hire has the same vocabulary problem and the same uncertainty as anybody else, with a much higher social cost attached to displaying it. They are expected to arrive capable, they often have people reporting to them within days, and asking a basic question in front of a new team is substantially harder for them than for a junior starter. They need a buddy more than most and are least likely to be offered one. The right match here is a peer rather than somebody junior, chosen specifically for discretion.
An internal mover has the opposite problem. Everybody assumes they know how things work, and they do, for the parts that are company wide. They do not know how this particular team operates, what its conventions are, or why certain decisions get made the way they do, and nobody tells them because it is assumed to be obvious. A short buddy arrangement for internal moves, perhaps four weeks, catches a surprising amount of this and almost no organisation does it.
Running the smallest version that works
A functioning buddy scheme is smaller than most written descriptions of one and takes about an hour to set up.
Write a half page describing the role: what it is for, the three scheduled conversations, how long it lasts, and an explicit list of what is not included. Give the same page to both people. This single artefact prevents most of the failures in this article, because almost all of them come from an undefined role.
Ask managers who on their team has genuine capacity this month, and match from that answer rather than from a profile. Prefer somebody who joined in the last year.
Put the three conversations in both calendars at the point of assignment rather than leaving them to be arranged. Arranging is a small cost that reliably prevents the second and third ones happening.
At the end, close it properly with a conversation that names where the starter goes next, and ask the buddy what they had to explain that should have been documented.
Then check one thing after each cohort: for how many pairs did the second conversation actually happen. That number tells you whether you have a scheme or a list of assignments, and it is the only measurement worth taking.
Frequently asked questions
What is an onboarding buddy?
It is a named colleague assigned to a new starter for their first weeks, whose purpose is to make asking questions socially cheap. They are not responsible for training, development, assessment or the person's work. The value lies in there being one person for whom answering obvious questions is explicitly the job, which removes the calculation that otherwise suppresses most early questions.
How is a buddy different from a mentor?
A buddy covers the first six to eight weeks and exists to lower the cost of asking practical questions. A mentor is a longer relationship focused on development and career, usually with somebody more experienced. Conflating them produces a role that is simultaneously too senior to ask trivial questions of and too short to build a developmental relationship.
Who makes a good buddy?
Somebody with genuine capacity this month, who the starter will encounter naturally, and ideally who joined within the last year. Availability matters more than expertise and proximity matters more than job similarity. Seniority is actively unhelpful, because the social cost the scheme exists to remove is highest with the most senior person available.
How long should it last?
Six to eight weeks, with a defined end rather than an open arrangement. Arrangements without an end date lapse instead of closing, which leaves the starter without a clear replacement route at the moment the designated permission disappears. The closing conversation should name who to ask for what from now on.
Why do buddy schemes stop after one meeting?
Because the arrangement is usually a standing offer, and acting on a standing offer requires the new starter to initiate, which is precisely the behaviour they find expensive. Scheduling three specific conversations at the point of assignment, rather than inviting people to get in touch, is the difference between a scheme and a list of pairings.
Can a chatbot replace a buddy?
No, and treating it as a replacement misunderstands the role. A retrieval tool handles documented questions, which usefully stops a colleague's time being spent on where the expense form lives. What it cannot do is be a person who is available to be asked something slightly embarrassing, and that availability is the whole of what a buddy provides.
How do we stop the same people always volunteering?
Match on capacity rather than on willingness, which means asking managers who actually has slack rather than asking for volunteers. Keep a record of who has done it recently and rotate deliberately. Without this the load concentrates on the same two or three helpful people, invisibly, until one of them declines and it reads as a change in attitude.
