Stop asking your team for updates

On removing the interrogation loop from engineering check-ins

Most standups are a polite form of interrogation.

You ask what someone is working on. They tell you mostly things you already knew. You then ask if there are blockers. They say no, or mention one, and it gets noted somewhere and the meeting moves on. This happens every morning, or three times a week, or whatever cadence the team has settled on. Everyone is present, but almost no one is really listening.

The problem isn’t the frequency or the length. It’s the structure. It puts the team on the hook for producing information that, in many cases, everyone in the room already has, or that no one in the room actually needs at that moment.

The worst version of this is when someone has to repeatedly announce that nothing has happened on a six-month project that was never going to move this week. That’s not information. That’s management theater at best and a slow tax on morale at worst. But the ritual demands it, so someone performs it.

The setup

I’ve been running my security team’s check-ins differently for the past year or so, and I want to describe the part that I think matters most.

We meet on Mondays, Wednesdays, and Fridays. Wednesdays and Fridays are short syncs, usually under fifteen minutes. Monday is the main meeting and runs for about an hour.

The gap between meetings is intentional: enough time for things to actually move, not so long that anything slips through.

The Monday structure is straightforward: I open with announcements, urgent or unplanned work, kudos where they’re due, and what’s top of mind for me on both the security and business side. Then each person goes through what they’re working on, what they need help with, what they’re stuck on.

None of that is unusual. The part that’s different happens roughly every two weeks, at the end of one of those Monday meetings, after everyone has had their turn.

I go through every project on our pipeline and I state my understanding of its current status. Not as a question. As a statement. I say what I think is happening, what I think the blockers are, what I think the next steps are. The team corrects me where I’m wrong. Mostly, I’m right.

We also run a monthly retrospective focused on team health and process improvements, but it’s separate from this mechanism.

Shifting the burden

The reason it works, I think, comes down to who carries the tracking burden.

In a traditional standup, that burden sits with the team. They’re responsible for surfacing progress, flagging issues, and producing updates on demand. The manager is the receiver. The implicit contract is: I ask, you report, and I follow up if something seems off.

This model inverts the contract. I absorb whatever surfaces naturally in normal conversation or check-ins over the course of two weeks. I don’t prompt for project-level status. I don’t ask “where are we on X?” in sync meetings, ever. Long-running work that hasn’t moved doesn’t need to be announced as unmoved. It surfaces when there’s something worth saying about it.

Then, at the biweekly recap, I carry the synthesis myself. I’m the one who has to demonstrate that I’ve been paying attention. If my understanding is wrong or outdated, that’s on me to correct, not on someone else to have proactively flagged.

The effect on the team is real, even if it’s subtle. Nobody has to say “no progress this week” on a project they haven’t touched, because I’m the one stating the status. The pressure to produce the update disappears. What remains is just the conversation. The team can instead focus exclusively on producing high-value signals.

There’s a flattening effect too. When the manager is the one producing the update rather than extracting it, the dynamic stops feeling like a reporting line and starts feeling more like a team that shares context.

The catch

There’s a prerequisite worth being honest about: this only works if the manager is actually engaged. The biweekly recap isn’t a technique for reducing your own involvement. It’s a forcing function for maintaining it. You have to be absorbing what people say in normal conversation accurately enough to reconstruct the state of the entire project pipeline every two weeks. If you’re not doing that, the recap falls apart immediately and you’ve just created a new awkward meeting format.

I would argue that engagement is the job anyway. Knowing the current state of your team’s work, understanding why things are moving or not, and being able to communicate that clearly to stakeholders is not a bonus feature of good management. It’s the baseline. This mechanic just makes it visible and creates a regular moment where you have to prove it to yourself and your team.

The upstream benefit

One more thing worth naming: it helps me upstream as much as it helps the team. I’m regularly synthesizing project status in a form that’s ready to communicate to stakeholders. The biweekly recap isn’t just a check-in tool. It’s also how I keep my own model current and accurate enough to answer questions quickly when someone above me asks.

I’m not claiming this is novel or scientifically validated. My sample size is one and every team is different. Other people have almost certainly arrived at versions of this and built better systems around it. But it has worked well enough that the mechanism is worth describing: Don’t ask. Absorb. Carry. Read it back. Let your team correct you.

The correction is the update. The absence of interrogation is the point.