Kanban, feedback loops, and waiting on
The useful thing here is not "do more Kanban". It is understanding that weak feedback loops make waiting time look harmless until it is too late.
The distinction that matters
There is a real difference between:
- work that has not started
- work that has started but is waiting on someone or something else
Those are not the same management problem and should not look the same in a weekly review.
If they do look the same, blocked dependency work gets mistaken for inactivity.
Why "waiting on" matters
"Waiting on" is useful because it creates a visible middle state between doing and done.
That gives me a way to ask better questions:
- waiting on whom?
- since when?
- what is the next chase point?
- when does it become a risk?
- what gets affected if it slips?
Without that, delayed work is only discovered at the point it starts causing embarrassment.
Practical application
1. Separate owned work from dependent work
That makes it easier to see what can move immediately and what needs active follow-through.
2. Review waiting items midweek
Not a full ceremony. Just a short check on the things that are at risk of silently drifting.
3. Escalate earlier
A blocker on Tuesday is manageable. The same blocker discovered on Thursday looks like failure.
What I want to test
A simple rhythm:
- Tuesday: confirm what I am waiting on
- Wednesday: chase or reset expectations
- Thursday: avoid pretending there is still time if there clearly is not
That is not bureaucracy. It is basic self-defence.
Related
- Delegated does not mean done
- Team Topologies and the cost of distance
- Further reading on delegation, visibility, and scale