How to Read a Delivery Board
A steering deck that showed nine of nine committed features green, a programme everyone in the room could feel was sliding, and the four readings of the same board that finally showed me where the work had actually gone.
On the Thursday of the third iteration the steering deck showed nine of nine committed features green, and everyone in the room knew that the programme was not green. You could feel it in the way the architects talked, in the questions that arrived a beat too carefully, in the fact that the same two names came up whenever anything actually had to move. The board was not lying to us. It was answering a question none of us needed answered, which is whether the items we had agreed to track were, on the surface, on track. The question we needed answered was where the work had gone, and a status board is built so that you cannot read that off it.
A delivery board is a Stated System. It is the version of the programme that fits on a screen: the capabilities, the features, the stories, the statuses, the burnup that bends the right way if you squint at it. It is genuinely useful, in the way a map is useful, and like a map it leaves out everything that did not survive being drawn. The Lived System is where the work actually goes: the item that jumped the queue last week, the dependency on a team you do not control, the feature that was committed in planning and has not moved since, the architect quietly holding four things together across three trains. The distance between the two is what I call the Drift, and a board read only for its colour hides the Drift by design, because colour is the one property it is built to keep reassuring.
The board is the question, not the answer
So I have stopped reading a board to find out whether it is green, and started reading it to find out what the green is built to keep me from seeing. That is a posture rather than a method, so let me make it concrete. There are four readings I now run over any delivery board before I trust a word of its status, and each one is a question rather than a number. None of them is hard. All of them are slightly uncomfortable, which is usually the sign that they are pointed at something real.
Four readings
The first reading is the side door. I ask how much of the capacity in front of me arrived without going through planning at all. On the programme I am describing it was, when we finally counted, thirty-one percent: a regulatory patch that a supplier slip had made urgent, a demo build an executive had asked for directly, a re-spin of a controller nobody had forecast. None of it was on the committed plan, all of it was real work being done by real people, and every hour of it was an hour not spent on something the board still showed as green. Side-door work is not a sin. It is information. The goal is never to shut the door, because the door is open for a reason. The goal is to see what it has been carrying, because that is the most honest account you will get of what the official plan was missing.
The second reading is the boundaries. I ask where each piece of work depends on a team it does not control, and, for each of those dependencies, whether the interface between the two has actually been agreed and whether anyone owns it. Years on safety-critical software taught me that the dangerous part of a system is almost never the components. It is the boundary between them, the place where two internally correct implementations disagree by a single assumption nobody wrote down. A backlog is a list of implementations. The dependencies are the interfaces. On a board the stories are loud and the dependencies are a thin line you have to go looking for, and the worst of them, the ones where the interface has no agreed shape and no owner, are exactly the ones that will not show up in any status until the iteration they detonate.
The third reading is the drift between committed and active. I lay what was agreed in planning next to what is actually being worked now, and I look at the gap in both directions. There is committed work that has not moved in two iterations, sitting green because nothing turns a stalled item red on its own. And there is active work that nobody planned, which is the side door again, seen from the other side. The committed-and-stalled and the active-and-unplanned are two halves of the same drift, and a board that shows you only the committed items, or only the active ones, lets you keep believing the plan and the reality are the same document.
The fourth reading is capacity, by which I mean where the people actually are rather than how many of them there happen to be. I look for the person who appears on the most items, and I ask what breaks if they are away for a week. On that programme it was a lead architect carrying six active items across four trains, which the board recorded as six healthy assignments and which was in fact a single point of failure with a calendar. I look for the committed feature with nobody on it, the work that lives in someone’s head rather than on the board. And I look for the safety-relevant story with exactly one name against it, because a bus factor of one on the part that can hurt someone is the kind of risk that stays invisible right up until it is the only thing anyone is talking about.
A status board is built to stay green while the programme slides. The four readings are the questions that make the slide visible.
Who pays for the gap
The readings are only half of it. The question that turns them from an interesting audit into a decision is the one I try to hold open over every gap I find, which is who is paying for it. Side-door work is paid for by whatever it displaced, usually the committed feature still showing green because nobody changed its colour when its people quietly walked away. An interface gap is paid at integration, by whichever team is downstream when the two assumptions finally meet. Stalled committed work is paid for by everyone who is still planning around a thing that is not happening. And an over-allocated architect is paid for, eventually, by the architect, and then by everyone who was depending on the six things at once. A gap with no name attached to its cost is not a gap somebody has decided to keep. It is just one that nobody has read yet.
The diagnostic
Take your current board, the real one your programme runs on. Do not ask whether it is green. Ask four counts instead, and write them down before you look at the status. What share of the capacity in front of you entered outside planning. How many cross-team dependencies have no agreed interface and no owner. How many committed items have had no movement in two iterations. And which single person appears on the most items, and what breaks if they are out for a week. The status will tell you the programme is fine. The four numbers will tell you which direction it is going, and the gap between the two readings is the thing your role actually exists to manage.
I have spent enough of my time describing boards that it seemed worth building one you can actually read this way, so I did. The E/E Solution Tracker is a live, interactive board for a fictional automotive programme, with the four readings built in as four lenses you can switch between: side door, boundaries, drift, and capacity. You can watch the same programme look fine under one reading and alarming under another, drag a slider to replay how the drift accumulated across the increment while the top-line status stayed reassuringly green, and, if you would rather, drop in an export of your own board and read it the same way. It is the framework in this essay, made into something you can move with your hands.
The programme in this article is anonymised and composited from more than one context, and the figures are illustrative of the pattern rather than drawn from a single team. It is intended to describe an organisational pattern, not a specific employer, programme, or team. The views are my own.
Reading the distance between the board and the work is one thread of the Drift framework, the spine of my forthcoming book Leading Agile When No One Agrees, which works through it across twenty-two chapters of scenes drawn from a career inside engineering organisations. The book is in final preparation for a Summer 2026 publication. If this piece resonates, the companion worksheets may be useful in the meantime, in particular the Side Door Audit and the five-question Drift Check. For anyone who would rather work in a terminal, drift-cli runs the same five-question check locally and never sends the result anywhere. A score that gets reported upward stops measuring the gap and starts producing it, so the tool keeps it on your machine by design.
More writing and book launch updates at kylehauslaib.com.