It Always Wears the Same Faces

Standups happen. Everyone’s busy. You’re not sure it’s on what matters.

You’ve watched the sprint board for three cycles now. The tickets move. The velocity chart looks fine. And still, when someone in leadership asks what’s landing this quarter, you feel your stomach tighten before you answer.

Something is wrong in the room. You can’t name it. And you’ve started to wonder if it’s you.

I’ve been in that room. I’ve led that room. Once, I was the reason for that room.

I was fired from a senior engineering leadership role. Weeks before it happened, I could feel something was off, so I asked my manager. “Ask your peers,” he said. Three peers. Three answers. “You’re doing fine.” “I don’t know, your job is different than mine.” “I don’t trust you. I think you’re failing.”

Conversations were happening about me. At multiple levels. Not with me.

Since then I’ve sat inside a lot of engineering organizations. Church tech. Nonprofits. Defense. Healthcare. SaaS. And here’s what I want you to know.

It always wears the same handful of faces.

The problem with “we’re not moving”

Every stuck team presents the same way. Slow delivery. Missed dates. Product and engineering pointing at each other. So leaders reach for the same fixes. New tooling. A reorg. A return to office. Hire a senior engineer. Fire a senior engineer.

You can’t fix a broken team by changing the scenery.

Those are treatments for a symptom. The symptom is almost never the disease. Underneath the slowness there are eight patterns I’ve seen over and over. Most rooms have two or three. None of them mean anyone is bad at their job.

So here they are. For each one: what it looks like from the outside, what’s actually happening underneath, and the one question that tells you whether it’s in your room.

I’ve grouped them by where the damage lives. Where the truth goes. What fear does to the work. Who is actually leading.

Where the truth goes

The first three patterns are about information. Where it flows, where it stops, and who gets to see it.

1. No Surprises

What it looks like: Someone leaves, or is let go, and half the team says “I saw that coming” while the person in question is blindsided. Performance reviews contain news. Exit interviews contain the real feedback.

What’s underneath: Conversations are happening about people instead of with them. Leaders think they’re being kind by waiting. They’re being cowardly, and the person paying for it is the one who never got the chance to improve.

Ask: If someone on this team is struggling, do they already know? Or would they have to ask around to find out?

2. The Blast Radius

What it looks like: A well-known problem, usually a person, that everyone talks about and nobody addresses. Eventually a new manager inherits it. When the conversation finally happens, it’s a PIP that’s really a fast track to the exit, and it feels arbitrary because it is.

What’s underneath: Unaddressed problems don’t stay contained. The team has watched leadership avoid the conversation. They’ve learned that accountability is inconsistent. Your best people are quietly asking, “If they won’t deal with that, what else are they ignoring? Am I next?”

Ask: What conversation is this leadership team avoiding right now? And who else is paying for the silence?

3. Context in Accountability

What it looks like: An engineer is on the hook for something that broke. The fix turned out to be simple. Leadership is furious it wasn’t tried.

What’s underneath: Nobody asked what the engineer had been told to prioritize. Or what access they didn’t have. I once watched a strong, trusted engineer nearly get fired over a server issue when his direct lead had told him not to work on it and the CTO had a sandbox nobody else could touch. Blame without context teaches a team to hide problems instead of surfacing them. You end up with an organization that spends more energy on cover-up than on the actual bug.

Ask: Before the last person here was held accountable, did anyone ask what they’d been told to do and what was in their way?

What fear does to the work

The next three are about safety. Not the soft kind. The kind that determines whether your engineers do their best work or their safest work.

4. The Cost of Anxiety

What it looks like: Talented people doing conservative work. No risks. No pushback. Estimates padded. Nobody volunteers for the hard thing.

What’s underneath: Someone doesn’t know where they stand. I watched a good engineering manager live in a constant state of anxiety for eighteen months. One month he was told he was going on a PIP. The next month, he was fine. Then concern. Then reassurance. He resigned. When your dominant emotion is fear about whether you’ll have a job next month, you aren’t thinking about how to get better. You’re surviving.

Ask: Is anyone on this team operating from fear right now? What would it take to replace that with clarity?

5. Psychological Safety Inequality

What it looks like: Some people speak up in meetings and get called bold. Others say the same kind of thing and get called difficult. The quiet ones stay quiet. Ideas come from the same three mouths.

What’s underneath: Safety exists in the room, but it isn’t distributed evenly. And everyone can see it. You don’t just lose the ideas from the people who can’t speak up. You lose trust from everyone who watches it happen. The unsafe ones leave or stop trying. Either way you get a fraction of your team’s thinking.

Ask: Who on this team doesn’t feel safe to say “I think we’re wrong about this”? And what are you actively doing to change that?

6. Developing vs. Discarding

What it looks like: People are hired, evaluated, and replaced. Nobody’s trajectory changes. When someone slips, the conversation is about exit timing, not recovery.

What’s underneath: Leadership is seeing current output and not capacity. I once promoted an engineer whose performance had dipped during a hard season at home, over the protest of people who were stuck on who he used to be. When I was eventually fired, he took my role. He deserved it. Without someone willing to invest, we’d have lost a leader because we were too quick to judge and too slow to develop.

Ask: Who on this team are you about to give up on? Who might surprise you if you invested instead of managing them toward the door?

Who is actually leading

The last three are about the shape of leadership itself. Who holds the authority, what they’re being rewarded for, and whether the organization believes people leadership is real work.

7. Delegation Asymmetry

What it looks like: A manager who has handed off “the people stuff.” A tech lead who is somehow running one-on-ones, giving feedback, and doing performance reviews with no authority to back any of it. Or the reverse: responsibility for outcomes with none of the power to change them.

What’s underneath: You can delegate technical leadership. You cannot delegate people leadership. The team knows who can fire them, promote them, and discipline them. They need to trust that the person holding that power is using it fairly and consistently. When that person outsources the hard part, trust erodes, and the person they outsourced it to gets ground up in the middle.

Ask: Who on this team holds responsibility they don’t have the authority to meet? And who holds authority they’ve stopped exercising?

8. The Dichotomy Trick

What it looks like: Conversations that end early. “We need managers who still write code.” “We need people-first leadership, not architects.” “It’s a process problem, not a people problem.” Pick one.

What’s underneath: A false choice that lets the organization avoid the harder truth: it’s contextual. A greenfield project with decade-long architecture consequences needs deep technical chops in the seat. A mature product with strong technical leads might need people leadership more. The danger isn’t being stronger in one. The danger is an organization biased toward one that de-prioritizes the other. When technical contribution is prized above all, people problems simmer. When technical credibility is dismissed, teams make expensive mistakes.

Ask: What does this team need more of right now? And is leadership honest about where it needs to grow, or defending the skills it already has?

The Thesis

This one isn’t a pattern so much as the thing underneath all eight.

What it looks like: An organization that treats people leadership as overhead. Something you do after the real work. Something the strong engineers shouldn’t be bothered with.

What’s underneath: Here’s what I believe. A product engineering team cannot do its best work without a good people leader. Not because technical skill doesn’t matter. It does. But the best technical work requires something only people leadership provides. Clarity. Trust. Safety. Development. Fairness. When engineers are anxious, they play it safe. When feedback is inconsistent, they can’t improve. When only some people feel safe, you get a fraction of the ideas. You can have the most talented engineers in the world and still not get their best work.

That’s not soft skills. That’s foundational.

Ask: Does this organization believe that? Not on the values page. In the budget, in the promotions, in what gets talked about at the leadership table.

How to use this

Don’t score yourself. Score the room.

Go through the eight and, for each one, ask the question. Not to yourself. To three people at different levels of the org chart. An IC. A lead. Someone above you. Write down what they say.

If you’re honest, you’ll find two or three. That’s normal. That’s every room I’ve ever been in, including the ones I ran.

Then resist the urge to fix all of them. Most teams can’t run cultural repair and a roadmap at the same time. Pick the one that’s costing you the most trust, because trust is the resource everything else spends. Usually that’s the avoided conversation. Usually it’s been avoided for months.

And if the answers point back at you? Good. That’s the fastest version of this. The leaders I respect most are the ones who found themselves in a pattern and said so out loud. That sentence, said in front of the team, does more to restore safety than any process change you could ship.

You can’t set the whole organization right. You can set your corner of it. Your team. Your one-on-ones. The conversation you’ve been carrying around for three weeks.

So here’s my question.

Which of the eight is in your room right now? And who are you going to ask first?

If you’d rather have someone who’s been there ask the questions for you, that’s what a Team Diagnosis is. Two to four weeks. We talk to people up and down the org chart, score what we find against these eight, and hand you a written assessment and a fix list you can act on with or without us.