How We Built Tinder for Mentors - Inside a Fortune 1 Retailer

We had petabytes of data, a swipe-right matching system, and results that kept coming back mostly men. Here’s what happened when I wouldn’t let that go.

“What If It Was Like Tinder?”

The room got quiet in the way rooms get quiet when someone says something that’s either brilliant or career-ending and nobody’s sure which yet.

I was a brand new design leader — still carrying an IC design workload, still figuring out what “leading” actually meant in a company this size — when the data science team walked in with an unusual problem. They had petabytes of employee data. Work history. Tenure. Location. Performance signals. More data than most organizations will ever touch. And they had no idea what to build with it.

They looked at me and asked the best and worst question a designer can receive:

“What should this be?”

I did not have a visionary answer ready. I did not have a framework on a whiteboard or a three-year roadmap in my back pocket. What I had was a team of two, a conference room, and a half-formed thought that kept coming back to me: the hardest part of finding a mentor at a massive company isn’t the mentorship. It’s the finding.

So I did what any reasonable designer does when they don’t know the answer yet.

We Started With Tinder

Before running a single focus group or writing a single user story, I sat down with my team of two and did something that raised a few eyebrows: we ran a competitive SWOT analysis on two products that had nothing to do with enterprise HR software.

Tinder. And Good & Co.

Tinder is a masterclass in impulse matching — low friction, fast signal, swipe-based decisioning that removes the cognitive overhead from connection. Good & Co. was a workplace culture platform built around compatibility between people and organizations.

Neither was a mentorship product. Both were secretly solving the same problem we’d been handed: how do you connect the right people with the minimum amount of friction?

The SWOT forced us to ask: what works about each of these? What fails? What would an enterprise version of their best qualities look like — and what would we need to leave behind?

That exercise gave us a hypothesis before we’d talked to a single user: the connection mechanism is the product. Not the mentorship itself. Just the match.

Then We Talked to People

Hypothesis in hand, we ran focus groups — separately, with mentors and mentees across the organization. The questions were simple on purpose:

• What do you look for in a mentor?

• Is it hard to find one today?

• Why?

We paired qualitative questions with Likert scale items. Something to measure, not just something to feel.

What came back was consistent. Clarifying. And a little humbling.

The problem wasn’t mentorship. People understood mentorship. They wanted it. They knew exactly what a good one looked like. The problem was finding someone outside their immediate corner of the building.

In a company of hundreds of thousands of people spread across every geography, function, and level — most employees were invisible to each other. Mentor programs had been attempted before. They kept failing for the same reason: you can only find who you can already see.

We didn’t need to make mentorship better. We needed to make discovery easier.

We Had Everything We Needed. Except Clean Data.

Here’s where most product stories skip the hard part.

We had petabytes of employee data. On paper, everything a matching algorithm could want. In practice, ingesting and reconciling dirty, incomplete, and inconsistent entries eliminated more than half of our potential user base before we matched a single person.

Duplicate records. Missing fields. Job titles formatted seventeen different ways across different business units. Data entered by humans, maintained inconsistently, and never audited for the purpose of powering a product.

Data abundance is not data quality. More data doesn’t mean better outcomes — it means more confident outcomes. Which is far more dangerous when the underlying data is wrong.

We learned that the hard way.

“Wait. Is That Fair?”

We were deep into testing when I noticed something.

The results kept coming back mostly men. Senior men. Decorated men. Men whose career trajectories were long and well-documented in the system. By every available signal, the algorithm was working exactly as designed.

I looked at the results and asked a question that made the room uncomfortable:

“Is that fair?”

Not “is it accurate?” Not “is it statistically defensible?” Not “does it meet the success metric?”

Is it fair?

The data science team had an answer for the first three questions. Nobody had a clean answer for the fourth.

Here’s what the data was actually telling us: this organization, like most large American companies built between the 1960s and 1990s, had hired predominantly men. That history hadn’t disappeared when we started building. It had calcified — into job descriptions written in male-dominant language, into performance qualifiers that tracked traditionally male career patterns, into data structures that reflected who had historically been considered worth measuring and promoting. The algorithm wasn’t broken. It was telling the truth about the company’s history.

And in doing so, it was about to reproduce it.

I wouldn’t let it go. I kept asking the question in rooms where it was inconvenient to ask it. I pushed it into design reviews. I pushed it into data conversations. At one point, I pushed it hard enough that legal got involved — not because anyone had done anything wrong, but because the annoying designer in the room kept insisting that “the system works” was not the same as “the system is fair,” and eventually that distinction needed an actual answer.

We addressed the surface layer first. First name and last initial only — no full names that signal gender or ethnicity. Randomized abstract icons instead of photos — no appearance, no presentation, no visual gender cues. Location deprioritized as a primary match signal.

These were UI decisions.

The bias wasn’t living in the UI.

So I pushed further. I worked with the data team to enforce gender-equal candidate surfacing directly in the algorithm — not as a filter, not as a toggle, not as anything a user could see or adjust. A hidden correction built into the system logic, actively working against the imbalance the organization’s own history had created.

There’s a word for what I was doing in those rooms, asking the same question nobody wanted to answer.

Annoying.

There’s a better word too.

Anti-bias.

Not unbiased — that’s passive, a shrug, a “we didn’t mean to.” Anti-bias is a verb. It means you went looking for the problem before it found you. It means you asked “is that fair?” in the meeting where everyone else had already moved on. It means you made legal nervous and the data team frustrated and the timeline longer.

It means you didn’t stop until the answer was actually yes.

What We Built

The product that came out of this process was simple by design. Employees could be matched with potential mentors anywhere in the organization — across geography, hierarchy, and function — based on work history, learning goals, and communication preferences rather than proximity and org chart position.

Swipe right. Swipe left. Tinder for Mentors.

Match volume increased. Prediction accuracy improved over time as the feedback loop fed back into the algorithm. People were connecting with mentors they never would have found through any formal program — across the country, across functions, across every level of the organization.

The product was later highlighted by the company’s Chief Inclusion Officer and publicly announced at SXSW as a first-of-its-kind mentorship system — and a foundational example of what human-centered algorithmic design can look like at enterprise scale.

What This Story Is Actually About

It’s not about the company. It’s not really even about the algorithm.

It’s about what happens when design is in the room at the beginning — when a data science team asks “what should this be?” and a designer actually answers with research, not assumptions.

It’s about the value of running a SWOT on Tinder when you’re building enterprise HR software. It’s about focus groups that replace gut instinct with evidence. It’s about the unglamorous work of data quality that determines whether a product reaches half its intended users or all of them.

And it’s about the design decisions that never appear in the interface — the hidden corrections, the enforced equalities, the values encoded in system logic — that determine whether a product reproduces the world as it has been, or quietly helps build the world as it should be.

Those decisions don’t make the changelog. They don’t show up in the UI. Most design reviews never touch them.

But they are the most consequential design work happening in AI right now.

And almost nobody is asking “is that fair?”

The Book That Said It First — About Something Else

In How to Be an Antiracist, Ibram X. Kendi makes an argument that reframed an entire cultural conversation: it is not enough to simply not be racist. There is no neutral position. The systems already have racism built into them — in policy, in hiring, in data, in who gets resourced and who gets overlooked. Passivity doesn’t opt you out of that system. It just means you stop noticing it while it keeps running.

His argument: if you are not actively antiracist, you are — by default — participating in the reproduction of racist outcomes, regardless of your intentions.

I am not here to make a statement about race. Kendi already made it, better than I could.

What I am here to say is that the same logic applies — with identical precision — to bias in AI systems.

It is not enough to take the unconscious bias training. It is not enough to remove the protected attributes from your model inputs. It is not enough to say “we didn’t intend to discriminate.” The systems already have bias built into them — in the data they were trained on, in the signals they were designed to optimize, in the decades of hiring decisions and organizational choices that shaped the information your algorithm now treats as ground truth.

Passivity doesn’t opt your AI system out of that history. It just means you stop looking for where the bias lives while the system keeps running.

To build AI systems that are genuinely fair, you cannot simply be unbiased. You have to be actively anti-bias.

That means going looking for the problem before anyone reports it. It means asking not just “did we discriminate?” but “who is this system quietly failing while the metrics look fine?” It means making deliberate, sometimes hidden interventions — not as a feature, but as a correction for what the data got wrong.

It means being the annoying designer in the room who keeps asking “but is that fair?” long after everyone else has moved on.

It is not comfortable work. It won’t show up in your sprint velocity. It will occasionally make legal nervous. It may get you fired.

It is also the only way to build AI systems that deserve the trust of the people they affect.