Execution & team health · Field guide
Find the bottleneck.
If work is taking too long, measure where the system makes it wait. Do not turn team-level delivery signals into a ranking of individual people.
When leadership asks, “Why is this taking so long?”, teams often answer with more status reporting, more estimates, or a dashboard that pretends a developer’s activity is the same thing as useful delivery. The bottleneck remains, but now the organization has a scorecard.
The question is about the system, not the person
Flow metrics are useful when they help a team see where work waits, churns, returns for clarification, or becomes blocked. They are harmful when used to judge an individual engineer, compare unrelated teams, or manufacture a simple explanation for a complex delivery problem.
- Where does work spend most of its time after it starts?
- Are we starting more work than we are finishing?
- What kinds of work wait on a decision, review, environment, or outside dependency?
- How much planned capacity is being consumed by interrupts, support, or production risk?
If the question cannot be answered by changing a team practice, ownership boundary, dependency, or scope decision, a dashboard will not make it useful.
Four signals are usually enough to begin
Use the team’s existing work system. You do not need a new analytics platform to begin. Read these as local trends, not universal targets.
A meaningful architectural change, urgent incident, or new team can make a number move for a sensible reason. The conversation is where the interpretation happens.
Pair the signal with the people doing the work
A useful weekly review can take 20 minutes. Look at the four signals together, ask the team what changed in the system, identify one bottleneck worth testing, choose one bounded change, and set a date to review whether it helped. Retrospectives and one-on-ones add qualitative evidence a work board cannot show: unclear ownership, repeated rework, a missing skill, pressure to hide risk, or a collaboration pattern that is wearing people down.
Illustrative fictional scenario — not a client case study.
A flow review should produce one system experiment.
Where is work waiting long enough to justify a system intervention?
Swipe or scroll to see the full figure
Read the figure as a table
| Review step | Question the team answers | Output |
|---|---|---|
| Flow signal | Where is work waiting or aging? | One named system condition. |
| Team context | What explanation fits the work we actually did? | A hypothesis, not an individual verdict. |
| System change | What small, reversible change can test that hypothesis? | One owner and experiment. |
| Review date | Did the condition change enough to keep, adapt, or retire it? | Next decision, not permanent reporting. |
A fictional example: the team is busy, but the work is waiting
Consider an illustrative team working on a customer-facing workflow. The board makes delivery look slow. A closer look shows engineers completing implementation, then items wait for business-rule clarification and a single technical-review queue. Meanwhile, new work continues to start because nobody wants a contributor blocked.
The right response is not to tell people to “move faster.” The team can make acceptance questions visible earlier, create review coverage for the recurring bottleneck, temporarily limit starts, and review the oldest items with the project tech lead.
- Mark the waiting states in the existing board; do not create a parallel tracker.
- Bring one old item and one recently completed item to the review for context.
- Choose one change, such as earlier acceptance discussion or review coverage, and protect it for one short cycle.
- At the next review, ask whether the waiting pattern changed. If not, investigate the next constraint rather than blaming the contributors.
That is what a flow review is for: a way to choose the next intervention without pretending the first explanation was certain.
Give leadership the implication, not a dashboard dump
A sponsor usually needs a short statement: “Work is waiting most often at [named point]. The team is testing [specific intervention]. This affects [forecast, risk, or customer commitment] in this way. We will review the effect on [date or decision point].” Leadership can then decide whether to remove a dependency, change scope, protect capacity, or accept a trade-off.
Do not use flow metrics to rank people, decide compensation, monitor keystrokes, or compare teams doing materially different work. Make that boundary explicit before you collect or share the data. The team should be able to say, “This signal tells us where the work is getting stuck,” without fearing that a temporary spike will become an individual performance judgment.
Retire reporting that stops changing action
If a chart has not changed a prioritization, staffing, ownership, workflow, or risk decision for several review cycles, simplify or remove it. The point is not a permanent delivery dashboard. The point is to make the next constraint visible enough to address.
Use the resource
Flow Review Worksheet
A lightweight four-week worksheet for recording team-level flow signals, the team’s explanation, one system experiment, an owner, and a review date. It works with the team’s existing board or tracker.
PDF for printing or sharing. DOCX for adapting in your own tools.
Choose the next move that matches the situation
Run a small baseline yourself
Use the worksheet for four weeks with one team and discuss the signals in a retrospective or delivery review.
Download the editable worksheetResolve one recurring bottleneck
Use a Working Session when one blocked initiative needs a shared explanation and a credible intervention.
Bring it to a Working SessionAddress a broader delivery pattern