I sat in a hiring debrief once where a panel of four engineers spent eleven minutes agreeing with each other. The candidate had shipped real systems. She asked sharp questions about our deployment story. She pushed back on one of my answers, politely, and she was right.
Then someone said it. "Strong engineer... I'm not sure she's a culture fit."
Nobody asked what a culture fit was. Everyone nodded. We passed on her. Six weeks later we hired a bloke who reminded all four of them of themselves, and eighteen months later our team still had the same blind spot she had spotted in the interview.
"Culture fit" is usually a mirror, not a filter
Here is the thing about the phrase. It sounds like a standard. It behaves like a reflex.
Lauren Rivera at Kellogg spent a decade watching how elite firms recruit. Her finding is blunt. Interviewers ask themselves "is this person a fit socially for me? How do I feel when interacting with this person?" rather than "is this person well suited for our organisational mission and strategy?" Kellogg Insight summarises her work here, and her warning is sharper still. Hire for fit and you end up with a copy of your existing employees. In many instances, she says, it is a form of discrimination.
Read your last three rejection notes. Not the ones about missing skills, the other ones. "Bit abrasive." "Not sure about the energy." "Wouldn't gel with the team." Those are feelings dressed up as criteria, and feelings favour people whose accent, humour, hobbies and career path look like yours.
I have written those notes. I am not standing on a hill here. I am standing in a hole I dug.
Identical engineers make identical mistakes
The comfortable defence of fit hiring goes like this. We move fast because we think alike. Less friction, less debate, more shipping.
The first half is true. The second half is where teams die.
Lu Hong and Scott Page published a paper in PNAS in 2004 with a title as direct as it gets: Groups of diverse problem solvers can outperform groups of high-ability problem solvers. Their result stings if you run an engineering org. Pull the highest performing individuals out of a large pool and put them on one team, and a randomly selected team often beats them. Why? Top performers in a big population tend to share the same approaches. Their strength collapses into sameness. Random selection keeps the range of methods wide, and range wins on hard problems.
Think about what your architecture reviews sound like when everyone learned the same stack at the same three companies. Every design goes the same direction. Every risk gets weighed the same way. The team is not smarter, it is louder about one idea.
Every outage postmortem I have read where the root cause was "nobody thought about X" was written by a team where nobody was ever going to think about X. Not because they lacked talent. Because they lacked a person whose whole career had trained them to look at X first.
The support engineer who joined from a call centre spots the failure mode your ex-FAANG hire has never lived through. The self-taught developer who maintained a chaotic PHP monolith for a charity knows what "we'll clean it up later" looks like in year four. The person who worked in a regulated industry asks about audit trails before your first enterprise deal, not after.
Sameness is not speed. Sameness is a shared blind spot with good velocity metrics.
Roland Butcher and the eleven captains
I interviewed Roland Butcher on the Corey-osity podcast. In 1980 he became the first Black cricketer to play for England, a Barbadian who came up through Middlesex and refused to make his difference the headline. He wanted to play well.
His coaching philosophy is the one I keep stealing for engineering teams. He wants eleven captains on the field. Not one decision maker and ten pairs of hands. Eleven people able to read the situation and act.
You do not get eleven captains by hiring eleven of the same person. You get them by hiring people whose instincts differ from yours and then, and this is the hard bit, by letting those instincts change what you do.
Hiring the odd one out and then overruling them every sprint is worse than not hiring them. You have bought the perspective and thrown away the receipt.
Culture add is a real practice, not a slogan
Google's approach is to hire for culture "add", not culture "fit". Roman Matla, their director of APAC diversity and employee engagement, put it exactly like this. The question changes from "is this person like us?" to "what is missing from this team, and what does this person bring?"
Google reports over 2,500 employees across 150 offices completed Culture Add training, with nearly 90% saying the workshop changed how they thought about candidates strengthening the culture.
Whether a workshop moves the needle long term, I am not sure about this part: self-reported training satisfaction is a weak measure. The reframing is what matters, and it costs nothing to steal.
Here is how I run it now.
Write down what is missing before you write the job ad
List the last five decisions your team got wrong. Look for a pattern in the type of thinking absent from the room. Frontend instincts? Operational paranoia? Commercial sense? Someone who has supported customers at 2am? Put the gap at the top of the scorecard, above the framework list.
Ban the word "fit" from debriefs
Make people finish the sentence. "I have a concern about..." followed by a behaviour, an example and a consequence. "She interrupted me twice while I was explaining the caching layer" is a data point worth discussing. "Weird vibe" is not.
Separate values from style
Values are non-negotiable. Honesty, respect, taking responsibility when something breaks. Style is negotiable and mostly cosmetic. Dress, humour, whether someone chats about football, whether they are quiet in group settings, whether they went to university.
Confusing the two is how teams reject good people while congratulating themselves on standards.
Give the interview panel someone unlike the panel
If everyone assessing the candidate came from the same background, your signal is one opinion repeated four times. Rotate in an interviewer from another function. They will ask the question your engineers forgot to ask.
The obvious objection
"So I should hire people who make the team miserable?"
No. There is a line, and it is bright.
A box breaker challenges your ideas. A bad hire challenges your right to have ideas. One argues in the design review and commits to the decision. The other argues in the design review, loses, and relitigates it in Slack for a fortnight.
Difference in perspective is the asset. Contempt for colleagues is not a perspective, it is a defect. Screen hard for how someone treats people whose skills differ from theirs. Screen hard for whether they change their mind when shown evidence. Then stop screening for whether they feel familiar.
The signal you want is friction with ideas and grace with people. Most fit-based rejections get this backwards, filtering out the first while waving through anyone charming enough to hide the second.
What it costs you to keep hiring your own reflection
Every homogeneous team I have led shipped fine for about a year. Then the market shifted, or the scale changed, or a customer type arrived nobody understood, and the team had no internal disagreement to draw on. We had to buy the missing perspective at consultant rates, under deadline, with a system already built the wrong way.
The engineer we passed on for "culture fit" was not a risk. She was insurance against being wrong, and we declined the policy because the premium felt awkward.
Look at your team. Who in the room reliably says the thing everyone else missed? If your answer is nobody, then you have not built a hiring standard. It is a mirror.
So what is the gap on your team right now... and would your own interview process reject the person able to fill it?