The Five Lenses I Run Before I Diagnose a Team

A team I worked with had an engineer they were ready to write off. His tickets were taking 90 days to close, and anyone could pull up the board and see it. Ninety days. You don't need a framework to know that's bad, and they'd already reached the obvious conclusion about who was responsible.

I went looking at where that time actually went. His time in queue – the stretch where the work was in his hands and he could do something about it – was five days. The other 85 the ticket spent waiting on other parts of the system.

That's the ordinary shape of cycle time and almost nobody looks at it that way. A ticket accumulates wait: for the thing it depends on, for the person who has to look at it, for the decision that hasn't been made. None of that waiting is visible on a board, and all of it lands in the same field. He was the last name attached to the work, so the number attached to him.

The number wasn't wrong. It was answering a different question than the one the team thought they were asking.

Why the obvious diagnosis is usually the wrong one

When a team is busy, shipping, and somehow not getting better, the explanations that arrive first are almost always about people. Not enough headcount. The wrong headcount. A motivation problem. A seniority problem. Someone specific who isn't pulling their weight.

Those explanations arrive first for a reason that has nothing to do with whether they're true. Effort is visible and immediate – it happens right before the output, in the same place, correlated with it. System problems show up late, somewhere else, with a delay long enough that nobody connects the two. Repenning and Sterman put it plainly: the available cue wins, and managers attribute throughput problems to the attitudes of the people in front of them even when the real cause is structural.

The part of their work that should worry you more is what happens next. Those attributions are self-confirming. A manager who believes people are the problem takes actions that make people behave like the problem, and then reads that behavior as confirmation. The diagnosis builds its own evidence. Run that loop for a year and you have a team that looks exactly like the one you thought you had.

One chain of causation isn't enough

The usual tool here is the Five Whys, and I want to be fair to it, because it's genuinely useful for a certain kind of problem. If a metric is moving wrong, or a feature is behaving badly, a causal chain will often walk you right to the thing. I use it. It works.

People aren't that. A team is not a system with one fault, and when you ask why five times you are choosing one pathway out of many and then treating the end of it as the answer. The patient-safety literature has actually measured this: in a worked analysis published in BMJ Quality & Safety, a full causal tree for a single incident surfaced more than 75 contributing causes, of which a Five Whys pass identifies one. Two different teams running it on the same incident routinely land on two different root causes, both defensible.

So I don't run a chain. I run a differential – several independent reads of the same team, taken separately, then compared. Doctors have done it this way for a long time and not because they enjoy the paperwork. You generate the candidates, then you rule them in or out.

Here are the five I use.

Lens 1: how the team actually spends time together

Look at what happens when these people are in a room, and whether there's any real trust in it. Not whether they're friendly. Whether someone can say "I think this is a bad idea" in front of the group and have the next ten minutes be about the idea.

The tell I look for is where the real conversation happens. If every meeting is polite and every decision gets relitigated in DMs afterward, the meeting isn't where the work is. That's a diagnostic signal, and it's usually a signal about safety rather than about calendars.

Lens 2: how information actually flows

Trace how a piece of context gets from where it's known to where it's needed. What you're looking for is whether information moves peer-to-peer or whether it all routes through one broker.

When every update and decision has to pass through a single person, you've built a fragility point into the structure. People wait. Context degrades on the way through. Eventually the team stops trying to get information directly, because they've learned it doesn't work, and the broker reads the resulting silence as everything being fine.

The uncomfortable version of this lens: the broker is frequently the person asking me to run the diagnosis. That isn't an accusation. Concentration like that is usually something the system forced rather than something anyone chose, and the person in the middle is typically working harder than everybody else. But you can't see it from the middle.

Lens 3: how work moves through the system

Follow a single piece of work from request to shipped and mark every place it stops. Where does it stall, where does a handoff create confusion, where does a clear decision turn into an unclear task.

This is the lens that found the 85 days. Nothing about that engineer's situation was visible as a flow problem until somebody drew the flow – on the board it read as one slow person. Stalls and handoffs look identical to people problems from the outside, which is why they get misdiagnosed so reliably.

Lens 4: what the numbers actually say

Lies, damn lies, and statistics, and your Jira numbers fit right in. Velocity, ticket counts, burndowns – all of it is shapeable, which makes it fine for reporting and close to useless for diagnosis.

This isn't a claim that engineering teams are lying. It's that those measures were built to describe output, and output can be inflated without anyone deciding to inflate it. So I go looking for the numbers underneath the headline: time in queue versus time in hand, how long work waits before anyone touches it, how often something gets reopened. The signals worth reading are the ones that are hard to game, and they're rarely the ones on the dashboard.

Lens 5: what people believe versus what they say out loud

Ask the same question in a group and then one-on-one, and pay attention to the gap.

There's good evidence that the gap is the norm rather than the exception. A five-year survey of project teams found that in high-risk situations, upward risk communication failed about 79% of the time – people saw the problem and the warning didn't make it up. The mechanism is unremarkable and very human: once someone believes leadership doesn't share their read of the situation, they stop escalating. Not out of cowardice. Out of an accurate assessment that it won't change anything.

Why you can't run this on your own team

Every one of these lenses measures something you're standing inside.

You're in the meetings, so you can't see what the meetings feel like. You're frequently the information broker. You designed the flow, or inherited it and stopped noticing it. You chose the metrics, which means you picked the ones that made sense to you. And you are the person the fifth lens is asking people to be honest in front of.

This isn't a pitch for hiring someone – plenty of teams get an honest read from a peer leader, a new hire in their first six weeks before they've acclimated, or a direct report who's been given actual cover to say hard things. What matters is that the reader has no stake in the current answer. You already know how to do this, by the way. Running these lenses is the same skill you use in a good 1:1, where you listen for the thing under the thing rather than taking the first answer. It's that, pointed at the system instead of at a person.

What you do with what you find

A read like this usually turns up three or four real things, and the temptation is to fix all of them at once, in a reorg. Don't. Pick the one that's upstream of the others.

That's most of the value of running the lenses separately – they show you the order. Several of the things you find will be symptoms of one of the others, and fixing a symptom is usually the more satisfying option because it's visible and it's yours to control. It also buys you nothing, because the thing producing it keeps producing it.

The ordering question is worth asking out loud with the team: if we fixed only one of these, which of the others would get better on its own? People who work inside the system every day are generally very good at answering that, and they're rarely asked.

The other thing worth saying: some of what surfaces will be about you. That's not a failure of the exercise, it's usually the most actionable finding in it, because you're the one variable you can change on Monday without anyone's permission.

Run all five. One lens on its own will send you confidently after the wrong fix, which is worse than not looking, because now you've spent the political capital.

The 90 days and the five days were the same ticket, measured two ways. One of those measurements had a person's name attached and the other had the system's, and only one of them was on the dashboard. Finding the second number wasn't the hard part. Being willing to go looking for it, when the first one already had a satisfying answer attached, was.