Large companies do not lack status. They drown in it: red-amber-green cells, percent-complete bars, weekly decks. What they lack is status that says whether the hard part is behind us. This paper proposes a hill chart whose dots are placed automatically from a declared stage and the work recorded against it — and which treats every human correction as a clue rather than an overwrite.
1The problem
Picture a programme with five workstreams and forty deliverables, owned by people in four time zones. Each one has a ticket, a page, or a spreadsheet row. Each one reports progress. Almost none of those reports answer the only question a leader actually has: is this going to land, and if not, where is it stuck?
Percent-complete is the usual answer, and it fails for a structural reason. It assumes work is a straight line from zero to done. Real work has two phases. First there is uncertainty: nobody yet knows the shape of the solution, what systems it touches, or who has to agree. Then there is execution: the approach is known and it is a matter of doing it. A task can be "sixty percent complete" and still have its biggest unknown sitting in the remaining forty.
At scale this becomes invisible work. People carry unknowns in their heads. Blockers live in chat threads. The status page says "on track" until the week it says "red", and by then the decision that could have helped was needed a month ago.
2Why a hill
Basecamp's hill chart names the two phases directly. The left slope is figuring it out; the crest is the moment nothing unknown remains; the right slope is making it happen. Each dot is a piece of work, and its position is a person's honest sense of where that work stands.
That honesty is the strength of the original. It is also what makes it hard to run across a large organisation. Someone has to remember to drag forty dots every week. Positions drift toward optimism. Nothing connects the dot to the evidence behind it, so a dot on the downhill slope and a dot on the uphill slope look equally credible. And there is no way to see a whole workstream as one dot made of many.
3Options we considered
There are three honest ways to decide where a dot goes. We compared them on the four things that matter at scale.
| Approach | Honesty | Effort to maintain | Rolls up to streams | Resistant to gaming |
|---|---|---|---|---|
| A. People drag every dot | High while people care | High; decays within weeks | No | Low — optimism wins |
| B. Computed from tickets | Low: tickets measure activity, not certainty | None | Yes | Low — close tickets, move dots |
| C. Declared stage, placed by the record, corrected by people | High, and the corrections are visible | Low: update the stage and tick items off | Yes | Medium — disagreement surfaces |
Option C keeps the human judgement Basecamp was right about, but takes the chore away. It also creates something neither of the others has: a measurable gap between what is written down and what people believe. That gap is the most useful signal in the whole system.
4The proposal
What we record
Each deliverable has a name, the outcome it should produce, the workstream it belongs to, its owners, the system components it touches, a stage, and a short list of items. Items come in five kinds, and each answers a different question about the work:
- Open questions: what we need to know.
- Decisions: what someone specific has to decide. Who decides is optional; how long it has been waiting is recorded automatically. A decision that affects several deliverables is simply recorded in each of them.
- Scope parts: what we are building — a feature, a migration, an integration. A part is either open or built; there is no progress in between. Each can optionally carry an owner and a link to its epic.
- Next steps: what someone does next — check on a team, get estimates by Friday. Optionally who, and by when.
- Blockers: what is in the way, of anything.
The record is expected to be incomplete. With dozens of owners updating asynchronously, much of what happens is never written down, and the chart is designed around that rather than against it.
Where the dot goes
The stage chooses a band on the hill. Inside the band, the record moves the dot. On the uphill stages it moves as questions are answered and decisions are made; on the downhill stages it moves as scope parts are built. Next steps never move it: they describe activity, not certainty — the same reason option B was rejected. An open blocker holds the dot at the start of its band and draws a short red bar across the slope in front of it, like a chock under a wheel. The blocker changes only where the record places the dot; it stops no one from doing anything.