The first structural decision in any mentoring program design is also the most consequential: do you run cohorts (defined groups that start and end together) or an always-on program (where employees can access mentoring at any time)?
The answer is not obvious. Both models have genuine advantages, and both produce failure modes that organizations discover expensively. The decision should be driven by your specific goals, organizational culture, and administrative capacity — not by which model is more common in your industry.
The Cohort Model
What it is
A cohort program launches groups of matched pairs at the same time, runs for a defined period (typically 3–6 months), and closes with a formal conclusion. All pairs in a cohort have the same start date, the same milestones, and the same end date. The next cohort begins a new enrollment cycle.
What it does well
Cohort programs create community. When 40 people start a mentoring program together, there is a shared experience — shared anxieties, shared milestones, shared stories — that individual mentoring relationships do not produce on their own. The cohort becomes a peer network on top of the mentor-mentee pair.
They also create program momentum. Having a defined start date forces a decision point: you are either in this cohort or you wait for the next one. That urgency drives enrollment and reduces the indefinite deferral that plagues always-on programs.
Finally, cohort programs are dramatically easier to manage at scale. You have one onboarding event, one matching process, one set of milestone check-ins, one program completion survey. The administrative concentration reduces coordination costs significantly.
What it struggles with
The cohort model's biggest limitation is timing. A new hire who joins the company in month four of a cohort cycle waits up to five months for mentoring access. A high-potential employee identified after the cohort launched cannot get in. The program serves the calendar, not the employee's need.
Cohort programs also have a concentration problem at the end: completion rates tend to drop in the final weeks as the "program end" creates a permission structure to disengage. Pairs who would have met for another two months stop, because the program is officially over.
The Always-On Model
What it is
An always-on program maintains a live mentor pool that employees can request to join at any time. When a mentee applies, they are matched with an available mentor and the relationship begins — regardless of what month it is or where other program participants are in their journeys.
What it does well
Always-on programs serve need, not calendar. A new hire who needs mentoring on day 30 gets it on day 30. An employee going through a career transition can access mentoring at the moment the transition is happening, not six months later when it is already resolved.
They also signal organizational culture more powerfully. "We have a mentoring program that runs twice a year" is a program. "Mentoring is available to anyone in this organization, at any time, as part of how we develop people" is a culture statement. The always-on model, when properly resourced, communicates something different about how the organization values development.
What it struggles with
Without the urgency of a cohort launch, always-on programs often suffer from perpetual low enrollment. "I will apply when things settle down" is the default response to any optional program without a deadline, and things never settle down.
Mentor pipeline management is also significantly more complex. In a cohort model, you recruit mentors in advance and know exactly how many you need. In an always-on model, you maintain a standing pool with variable availability, and managing that pool requires ongoing effort that many program managers underestimate.
Finally, always-on programs have a community problem. Without shared milestones, participants in different stages of their mentoring journey have limited shared experience. The peer network benefit of cohorts disappears.
How to Choose
Choose the cohort model if:
- You are launching a mentoring program for the first time and need to build momentum and organizational proof-of-concept
- Your primary goal is community-building, D&I programming, or leadership development for a defined group
- You have limited program management capacity and need to concentrate administrative effort
- Your organization has a strong cohort culture (e.g., academic institutions, training programs, consulting firm models)
Choose the always-on model if:
- You have a strong, well-understood program that has proven its value and needs to scale equitably
- Your primary use case is new hire onboarding — where timing-to-access is critical
- You have sufficient mentor pool depth to maintain always-on availability without burnout
- Your organizational culture places strong emphasis on individual development ownership
Why Most Mature Organizations Run Both
The false assumption in the cohort vs. always-on debate is that these models are mutually exclusive. They are not, and the organizations with the most sophisticated mentoring programs typically run them in combination.
A common pattern:
- Always-on foundation: new hire mentoring available from day one, continuously
- Cohort programs for specific populations: a leadership development cohort twice a year, a women-in-leadership cohort annually, a high-potential program by nomination
- Peer circle groups: always-on small group mentoring for broader access at lower resource cost
The always-on program handles the continuous organizational need — onboarding, ongoing development — while cohorts generate the community, momentum, and focused investment for specific strategic programs.
Starting with cohorts is almost always the right call for an organization building its first program: the concentrated experience, shared milestones, and administrative tractability make early programs more likely to succeed. But planning for eventual hybrid delivery from the beginning — choosing infrastructure that supports both models — saves significant rework when the always-on layer needs to be added.