Engineering management in distributed teams is mostly about asking the right questions at the right cadence. Managers who don't ask anything become disconnected; managers who ask too much become surveillance instruments. The right rhythm is a small number of specific questions, asked weekly, that surface real signal without becoming oppressive.
The ten questions below are designed for that weekly rhythm. Not all of them go to engineers directly — some are questions the manager asks themselves about what they're observing. Together they produce the situational awareness that proximity used to produce in co-located teams, without requiring the manager to monitor activity in real time.
1. What's blocking each of my engineers right now?
The most important question to keep current. The manager should be able to answer this without asking — by reading shift-end records and noticing what shows up in the "blocked" section across multiple days. When the same blocker appears in three consecutive shifts, it has become managerial work to remove. The question is less about discovering blockers (engineers should be flagging them) and more about confirming the manager has accurate awareness.
2. Whose work has been quietly stalled for a week?
Engineers rarely flag stalled work — they flag blockers. Stalled work is when "still working on X" appears in three or four consecutive shift-end records without progress. The engineer often doesn't realize it's stalled; the manager reading records spots the pattern. The question to ask the engineer is gentle: "I've noticed X has been in progress for a while — what's the situation?" Often the engineer realizes only when asked that they've been stuck without naming it.
3. Where is decision latency hurting us?
Which decisions are taking longer than they should? Usually one or two specific decision types dominate the cost — architectural reviews that require multiple senior people, prioritization calls that need product input, or budget decisions that need executive approval. Each week the manager should be able to identify the top two bottleneck decision types and have a plan for reducing their latency.
4. Are we shipping at the cadence we expected?
Cycle time from ticket-opened to ticket-shipped is the most useful single team metric. Track it weekly. If it's rising, something is changing — and the manager should know what. If it's falling, something is working — and the manager should understand why so it can be reinforced. The number itself is less important than the trend and the manager's ability to explain it.
5. Who hasn't been heard from this week?
Distributed teams have an attention asymmetry: the engineers who write a lot get read; the engineers who don't can fade from the manager's awareness. Each week the manager should consciously identify the engineers they've heard least from and check in. The check-in is light — a brief 1:1 message, not a meeting — and the goal is to surface whether quiet is a sign of focus or a sign of disengagement.
Put a context layer under your distributed team.
StandIn gives engineers a 60-second wrap at the end of every shift. The next shift wakes up knowing exactly what to pick up — no standup required.
Request early access6. What did I commit to last week that I haven't followed through on?
Managerial drift is one of the most expensive failures in distributed teams. The manager promises to follow up on something — to remove a blocker, to make a decision, to advocate for a resource — and forgets. Engineers notice. Over months, the team learns the manager's commitments are unreliable. Weekly review of outstanding commitments is the corrective. Keep a list; clear it weekly.
7. What's the state of each in-flight project?
Not a status report from each engineer — the manager's own understanding, derived from records. For each major project, the manager should be able to articulate: where it is, what the next milestone is, what risks are flagged, and who has the next action. If the manager can't answer this for a project, they're not connected to it, which means they can't help when help is needed.
8. Are there any retention risks I'm not addressing?
The signals usually exist before they become resignations: engineers who've stopped speaking up, engineers whose energy in 1:1s has visibly dropped, engineers who've moved from challenging the team to disengaging from it. The question is whether the manager is reading the signals and responding. By the time an engineer announces they're leaving, the actionable window is usually closed.
9. What's one thing I learned about the team this week?
This is a meta-question for the manager themselves. Every week should produce some new understanding — about a specific engineer's strengths, about a hidden process issue, about a relationship dynamic. If the manager can't name one thing they learned, they were probably on autopilot. The weekly habit of naming a learning keeps the manager actually paying attention rather than going through motions.
10. Is the team's context infrastructure healthy?
Are shift-end records being written consistently? Are decisions being logged? Are people reading what's declared? This is the manager's responsibility to monitor because no individual engineer benefits enough from the infrastructure to maintain it alone. A team whose context infrastructure is degrading will be operationally fine for weeks and then suddenly less effective in a way that's hard to diagnose. Catching the degradation early is much cheaper than recovering from it.
The shape of weekly management
The ten questions take an hour or two of focused attention each week. The output isn't a report or a meeting — it's a small set of actions: a blocker to remove, a stalled project to check on, an engineer to check in with, a commitment to follow through on. Done consistently, this produces managers who are genuinely connected to their teams without being intrusive. Done inconsistently, it produces managers who oscillate between absence and over-involvement, which is the pattern most engineers experience.
Frequently asked questions
Should these questions be discussed with the team or kept private?
Mostly private to the manager — the questions are internal calibration, not team conversations. A few translate to public artifacts: cycle time can be a team-visible chart, blockers can be a team-visible list, decisions made can be in the team's records. The manager's reasoning about retention risk or engagement should stay private; the operational data should be transparent.
How does this scale to managers with twelve or fifteen direct reports?
Not well. The questions are designed for a manager with five to eight direct reports. Beyond ten, the manager can't maintain the depth of awareness the questions assume — the answer becomes "I don't know" for half the team. This is one of the diagnostic uses of the question list: if a manager can't answer them, they're stretched too thin, and the fix is span-of-control rather than more discipline.
What's the single highest-leverage question if you only ask one?
Question one — what's blocking each engineer right now? Most managerial value comes from removing blockers, and the manager who can answer this question accurately every week is more useful than the manager who can produce elaborate dashboards but can't.
Get async handoff insights in your inbox
One email per week. No spam. Unsubscribe anytime.
Ready to eliminate your daily standup?
Distributed teams use StandIn to start every shift with full context — no standup required. Engineers post a 60-second wrap. The next shift wakes up knowing exactly what to work on.