How Mentorship Became My Management Blind Spot: A Lesson in Perceived Favoritism

When Favoritism Almost Cost Me My Team One project assignment, one overlooked team member, and suddenly I was the villain. It was early 2018 at the fintech startup where I’d just stepped into the Head of Product role. We were building a real-time fraud detection engine — the kind of high-stakes project that can make or break a company’s credibility with its banking partners. I needed a lead engineer who could handle the complexity, and I immediately thought of Daniel. Two years earlier, I’d mentored him through his first role; now he was one of our sharpest technical minds. I tapped him for the job without a second thought. The decision felt like meritocracy in action. Within a week, my team let me know it felt like something else entirely. Elena, a senior engineer who had quietly expected to run that project, went silent in standups. Two other engineers stopped volunteering for Daniel’s workstreams. Then, on a Tuesday afternoon, my office door closed behind three of them — not to complain, but to tell me they were updating their résumés. One said, “We don’t mind that Daniel is good. We mind that it seems like that’s all that matters.” I defended myself. I laid out the reasons: Daniel’s deep knowledge of the pipeline, his demonstrated speed, the fit with the timeline. I thought I was explaining a personnel decision; they heard a rationalization for favoritism. I was confusing the internal merit-case with the external signal I had broadcast to the rest of the team. And I hadn’t broadcast anything except the outcome. They saw only that the boss’s old protégé got handed the prize. That week, I learned what a Gartner survey would later confirm: perceived favoritism is among the most corrosive forces in a team, eroding trust faster than almost any other single behaviour. Leader-member exchange theory, which I’d studied in graduate school and then promptly ignored when it got personal, describes how managers naturally form closer relationships with some reports — an in-group that gets more access, more challenging work, and more benefit of the doubt. The research doesn’t say that in-groups are inherently harmful; it says that when those relationships aren’t paired with transparent criteria, the rest of the team fills the ambiguity with the worst possible explanation. And my ambiguity was total. The surprising part was what repaired things — and what didn’t. My first impulse was to create distance from Daniel. Pull him off the project, assign it to Elena instead, maybe rotate future lead roles more visibly. On paper, that would look like a fairness reset. But it would have punished a capable engineer for a process failure that was mine, not his. And it would have taught the team that the way to get a desired assignment is to threaten to leave — a disastrous incentive to bake into the organization. Instead, I turned toward transparency, not away from my mentee. I called a team meeting and walked through my actual decision criteria for the fraud-detection assignment: the technical requirements, the timeline risk, the specific past experience that made Daniel the strongest fit. I admitted what I’d failed to do — namely, share any of this upfront or create a path for others to compete for the role. Then I asked Elena to critique the project architecture in the next design review, giving her a public platform to shape the work. I also carved out a separate high-visibility stream — a new compliance reporting module — and handed it to her with explicit ownership, announced at the all-hands. Not as a consolation prize, but as a strategic need. Meanwhile, I kept Daniel on the fraud engine, and I didn’t apologize for it. I did, however, make his work process more legible: I scheduled weekly cross-team code reviews where anyone could question technical choices, not just me. That shared the intellectual spotlight and made it harder for the team to suspect that Daniel was operating under a protective shield. Slowly, the signal changed. It wasn’t “Daniel gets the best work because the boss likes him” — it became “Daniel gets hard assignments, but so do others, and we can all see why.” The sequence that rebuilt trust wasn’t a single courageous conversation; it was a series of structural moves: published criteria for project assignments, open design reviews, and a deliberate effort to distribute visible responsibility. Perceptions shifted because the information environment shifted, not because I delivered a better speech. There were still costs. Elena later told me she nearly left anyway, and only stayed because the compliance module became the most interesting work she’d done in two years. Another engineer admitted that the revolt was as much about their own career anxiety as about me. I came away with a scar and a clearer understanding of what “fairness” actually requires. It doesn’t require treating everyone identically — an impossibility in knowledge work where skills are lumpy and context-specific. It requires that the process for allocating opportunities be visible, discussable, and revisable. Harvard Business Review case studies on transitioning from peer to boss repeatedly underscore the same point: the reset isn’t about equal distribution; it’s about consistent, explicit criteria that apply to everyone — even, and especially, to the person you once mentored. Daniel still leads the core fraud detection platform. He has since trained two other engineers into equal ownership. That outcome is, in a real sense, the mentorship legacy I’d hoped for all along — only it had to happen in full view of the team, not in the shadow of my earlier shortcut. If there’s a durable rule here, it’s this: when you inherit a prior relationship in a new reporting line, don’t let the strength of that relationship substitute for clarity. The team will notice the gap, and they’ll fill it with a story you didn’t intend. But the fix isn’t to throw distance at the problem; it’s to throw light.