How We Built a Coaching Match Algorithm That Actually Works

Most team coaching tools do one of two things: pair people randomly or let managers guess who should talk to whom. Both approaches have the same problem. They treat pairing as an administrative task instead of what it actually is — a design problem with real constraints, real tradeoffs, and a surprisingly deep evidence base to draw from.

We took a different approach when building peer coaching matches in ExecReps. The system scores every possible pairing across your team, ranks them by expected value, and generates structured coaching sessions grounded in learning science. Not because we wanted to over-engineer it, but because the difference between a good match and a random one is the difference between someone actually changing how they communicate and someone sitting through an awkward 30 minutes they'll never repeat.

The Matching Algorithm

Every team member who completes enough workouts gets classified into one of eight communication archetypes — Storyteller, Analyst, Commander, Diplomat, Visionary, Mentor, Connector, or Maverick. Each archetype pair has a documented dynamic: synergy, complementary, creative tension, or neutral. That dynamic rating is the foundation of every match we suggest.

But knowing that Storyteller + Analyst is 'complementary' isn't enough to decide that Sarah should coach with Marcus. You need to factor in who's actually active, who has enough data, and which specific pairing has the highest growth potential.

The scoring formula:

Score = DynamicWeight × EPS Variance

Where DynamicWeight maps from the rating — synergy gets 4, complementary gets 3, creative tension gets 2, neutral gets 1. EPS variance is the difference in each person's Expression Performance Score. Wider variance means more room for cross-pollination.

Tiebreaker goes to the pair with the higher combined EPS. Two people who are both actively practicing and improving are more likely to show up, stay engaged, and actually follow through on commitments from the session.

What We Filter Before Scoring

The algorithm runs client-side — no API call, no server round-trip, no latency. But before scoring happens, we apply three hard filters:

• insufficient data — if someone hasn't completed enough workouts to get a reliable archetype classification, they're excluded. Matching someone based on incomplete signal creates bad first experiences.
• no profile — members without a completed profile are excluded. Coaching works because both people can see each other's strengths and development areas. Without a profile, the coaching agenda can't be personalized.
• same-archetype pairs — two Analysts coaching each other won't produce the cross-pollination effect that makes peer coaching valuable. We only match across archetype boundaries.

The system surfaces three matches, not thirty. That's a deliberate application of Hick's Law — decision time increases logarithmically with the number of choices. Three is enough to offer variety without creating paralysis.

Why Admins Can Swap (and Why That Matters More Than You Think)

Each suggested match has swap controls. Click the swap button next to Sarah's name, and you see other Storytellers on the team. Pick a different one, and the match updates with the same dynamic type but different people.

This seems like a minor UX detail. It's not.

There's a well-documented effect in behavioral science called the IKEA Effect — people value things more when they've had a hand in creating them. By letting an admin adjust even one person in a suggested match, they shift from 'the system told me to do this' to 'I chose this pairing.' that small sense of ownership measurably increases follow-through on scheduling the session.

But we anchor to the algorithm's best guess first. The admin sees three strong defaults before they see any swap controls. This is important — starting with a blank 'pick two people' interface would produce worse matches (because managers optimize for political safety, not growth potential) and slower decisions. The algorithm proposes, the admin disposes.

The Calendar Engineering (or: How We Shipped a Feature Without Building an Integration)

The thing I keep coming back to in product engineering is how much complexity you can avoid if you look at what already exists before building something new.

When we scoped the meeting creation flow, the instinct was to build Google Calendar and Outlook API integrations. OAuth flows, token management, calendar permission scopes, error handling for expired tokens. Weeks of work for a feature that needs to work on day one.

Instead, we reused a calendar utility we'd already built for a completely different feature. lib/calendar.ts already had RFC 5545-compliant ICS generation, Google Calendar deep links, Outlook deep links, and download triggers. All we added was ATTENDEE field support for multi-person events.

The result: click 'Create Meeting' and you get a modal with pre-filled participants, a date/time picker, a duration selector, and a fully personalized coaching agenda. Copy to clipboard or download an .ics file. Works with every calendar app that's existed since 1998. No OAuth, no token refresh, no integration maintenance.