Most of what a manager knows about the work arrives through two filters.
The dashboard drops everything that never became a number. It records events, and most of a workday happens between them. For example, a ticket moves to “In Progress” at 9 and to “Done” at 16. In those seven hours, the tester spent twenty minutes figuring out which environment was current and waiting while it rebuilt. So the tool records two events, and the day happened between them.
The retro drops everything nobody thought to mention. Naturally, people tell you what they remember, and they edit while they remember. I am not saying they hide things. Weeks are long, and our minds keep what felt like an issue and throw away what felt normal.
I believe the second filter, which most managers trust more, is worse than the first.
The diagnosis: 20 minutes looking for the right environment
I saw this in a testing team working on an insurance platform. Productivity was low, and nobody could explain why. When I sat and watched them work, much of the answer was the time spent figuring out what environment they were actually in, and the time spent waiting for one.
None of that was in any tool. Cycle time would have caught a ticket sitting in a state. Here, it was twenty minutes inside a task that was officially in progress, and it happened several times a day to several people.
The last time I went and looked at a delivery flow, the wait was sitting in one approval step nobody in the room had mentioned. It was not hidden. Nobody owned that step, so it never appeared in a report.
Ask that team in a retro whether anything blocked them, and they say no, honestly. It had been that way for months. That is how it stopped being an event and became the conditions.
The countermeasure: one hour watching one activity, unprepared
Pick the one team whose number looks strange.
Watch one activity for an hour. Focus on the work itself, as it happens. This is not a status conversation, nor a demo. Be clear about that. You might ask questions occasionally, but it’s better to wait until the end for a conversation based on what you are seeing.
Tell them you are coming and ask them to prepare nothing. The latter matters because if they prepare, you create overhead for them, and you will see the prepared version. So if nothing is prepared, the overhead lands on you, which is where it belongs.
Bring the reporting chain with you. When the manager is in the room, the layer above the team wants to be there too. You have to brief them; they are there to listen and learn from the way you act.
Now here are the rules, which are the whole difference between this working and this being an audit:
Announce it. A surprise visit gets you one hour of the real thing; then the team knows you turn up unannounced, and you never see the real thing again.
Ask to see the actual thing. Then ask again. The second showing is usually where the workaround appears.
Do not solve anything in the room. The moment you fix something, you become the person who fixes things, and they stop showing you problems.
Do not look for someone to blame. Keep a straight face when it gets uncomfortable.
Say thank you before you leave. Give one thing you saw that was good, and one question you left with.
Debrief with the chain at the end. Don’t do it in front of the team.
You are there to understand, not to confirm. What you will realize: an hour of watching gives you more than an hour of people remembering.
The case: a monthly hour on the floor for productivity
Let’s go back to the testing team. The client was unhappy: they missed deadlines, and test execution couldn’t keep up.
The manager started because a number would not explain itself. It became monthly because it worked. He sat next to a tester and watched them run test cases for an hour. His point was to see and understand what the productivity numbers he knew were made of. That is where he saw for himself the twenty minutes I had found in the diagnostic. Reading it in my report had not moved him. Watching it did. After an hour of watching, he started asking.
He asked what she was doing and what she needed to finish it. She was waiting on an environment. He asked how she knew which one was current, and she said she asks a colleague, or she tries it and finds out. He asked what had just happened when she went looking. Then how many times that had happened today. Four, she said, and it was not a bad day.
Then the two that hand it back: what would have to be true for that not to happen at all, and what would you try next time?
The last question is the turn. Up to that point, he is understanding but, most of all, leading the tester to acknowledge the real problem. At that point, he hands it back.
He did not solve anything. The team worked out what to try and what they thought it was worth, and one of them said a waiting reduction number out loud. He asked them to show him next time.
The month after, they showed him during another visit. Then they picked the next thing.
The first visits didn’t go smoothly. Half the team was skeptical about such a visit from management. The team leader was openly doubtful. Being watched reads like an audit until the manager proves otherwise, and the only proof is what he does. He does not solve their problem for them. He doesn’t even look for someone to blame; that wasn’t the point. He comes back the following month, which is what convinces them.
A manager who watches and leaves is a tourist. Here, he watches, asks until they see it, then steps back and lets them prove it to him next time he comes in.
That manager did his hour every month, and the team saved him the thing they want him to see. If you try it, the first visit will feel awkward for everyone. Move on to the second one. You will start to find out whether they believed you.