Writing
Notes on delivery governance, written while building DeliverySheet. Opinionated, specific, and about the part of the job that happens before the work starts — deciding what to commit to.
Follow by RSSTurning a request into a decision
What arrives is a sentence from someone who wants something. What you need is a thing that can be decided on. Start here →
· 7 min read
The engineering intake process, end to end
One door, two questions, four recorded exits. The whole intake process for an engineering team — without a triage committee or a twelve-field form.
· 5 min read
An intake form template with two required fields
A copy-paste intake form template for engineering teams: two required questions, one optional date, and the four exits every request must reach.
· 6 min read
Triage is deciding what happens next, not sorting by size
Request triage fails when it produces an ordering instead of decisions. The four exits, who sits in the room, and the fifteen-minute version.
· 4 min read
The side channel is rational
Requests arrive as DMs because the door leads to silence. Policing Slack fixes nothing; making the door the fastest path to an answer does.
· 6 min read
Five honest alternatives to the intake spreadsheet
Keep the sheet, move to Airtable or Notion, run a Jira intake project, add JPD, or adopt enforced states — the case for each, stated first.
· 4 min read
An intake form is a door, not a net
Most intake forms are nets — they catch everything and decide nothing. What the form should actually ask, and the one property that makes it work.
· 5 min read
Demand management is deciding, not collecting
An intake queue records wishes. Demand management shapes them, refuses some on the record, and commits the rest against capacity.
· 5 min read
Backlog bankruptcy: 400 unrecorded nos
A 400-item backlog is 400 decisions nobody recorded. Closing it is a batch of recorded declines and parks with reasons — not a purge.
· 7 min read
Separate the facts from the assumptions before you plan anything
Requests arrive as a blend of what is known, what is assumed and what nobody has checked. Written in one voice, the assumptions get treated as facts.
· 6 min read
Saying no is a decision. Record it like one.
Most requests that never get built were never actually declined — they were left to rot in a backlog. That costs more than a clear no.
· 7 min read
What makes a request shapeable
Not every message is a demand. The floor is low but it is real: a need, plus either who it affects or what happens if nothing changes.
· 6 min read
Not every request should enter the process
A bar at intake is usually described as bureaucracy. One sentence wide, applied at the door, it is the cheapest quality control a delivery process has.
· 6 min read
"SSO" is a topic, not a request
Half of what arrives in an intake queue is a subject area wearing the grammar of a request. The test that separates them takes five seconds.
· 6 min read
Waiting on information is a state, not silence
Most requests that die never got refused. They got asked a question and then quietly stopped existing. Waiting has to be a state with an owner and a date.
· 6 min read
How to say no to a stakeholder
The slow maybe costs more relationship than a fast no. What a good refusal contains, and how to deliver one to someone senior without burning anything.
· 6 min read
Moving delivery governance out of the spreadsheet
The trigger is not row count. What actually migrates when you move intake and capacity out of a sheet — and the one thing you genuinely give up.
Deciding what to commit to
What has to be true before a request becomes a promise, and what to do with the ones that never should. Start here →
· 5 min read
When everything is a priority, run the capacity line
"It's all P1" is not a prioritisation failure — it is a missing constraint. What changes when priorities have to fit under a per-team capacity line.
· 6 min read
Sprint commitment vs forecast: the argument is at the wrong level
Scrum replaced sprint commitments with forecasts for good reasons. The organisation still needs commitments — one level up, where promises are made.
· 5 min read
OKRs point. Commitments deliver.
An OKR names a direction; it doesn't promise anyone anything specific. Why teams that run on OKRs alone still miss dates — and what fills the gap.
· 5 min read
The date sales already promised
The customer has the date, engineering has the surprise. How to take a pre-promised commitment without pretending it was your decision.
· 5 min read
A definition of ready for commitments, not tickets
A sprint definition of ready checks tickets. The one that matters checks promises — the bar a demand clears before people and a date are committed.
· 5 min read
The mid-quarter ask is an edit, not an addition
Capacity did not grow when the urgent ask arrived. A mid-quarter request is an edit to a named commitment — the honest record names what it displaces.
· 5 min read
You don't need a scoring framework
RICE and WSJF rank unshaped demands to two decimal places. A readiness bar plus a visible capacity line does the work the score pretends to do.
· 8 min read
What a decision-ready demand actually contains
Not a template — the six things that must be established before a request can honestly become a commitment, and how to tell when one is missing.
· 8 min read
What goes in the quarter, and who decides
Quarterly planning fails as arithmetic before politics: capacity treated as a total, and no record of what you are not doing.
· 6 min read
An owner is a person, not a team
A team name in the owner field means the decision has no address — and the failure shows up at exactly the moment a judgement call is needed.
· 7 min read
Quarter planning without the theatre
A working quarter plan is a set of commitments the delivering teams agreed to — not a ranked wishlist. The meeting, the agenda, and what to stop doing.
· 6 min read
You will commit before you are ready. Make it cost four fields.
Banning early commitments does not stop them, it hides them. Recording them takes a minute and converts an invisible gamble into a named decision.
· 7 min read
Why delivery commitments slip before a single line of code
Most missed delivery dates are decided weeks before the work starts — when a request becomes a commitment without anyone checking it was ready.
Capacity and what to measure
Sizing work in units that survive a budget meeting, and measuring allocation instead of surveillance. Start here →
· 5 min read
A capacity planning template that fits on one sheet
The five columns a capacity plan actually needs, per team — and the two failures no spreadsheet template can fix, whatever you add to it.
· 5 min read
Ten projects in flight is a queue pretending to be progress
Running everything in parallel feels like motion and delivers like a queue. What the in-flight count costs, and the sequencing that fixes it.
· 5 min read
An estimate is not a commitment
A range with low confidence leaves the team and arrives upstairs as a date. What stops the hardening is making the promise a separate, recorded act.
· 6 min read
Capacity planning for engineering teams
The practice end to end: per-team FTE-months, confidence on every figure, walking demands down the capacity line, and the first demand past it.
· 7 min read
Estimating capacity when you don't know enough yet
The honest answers to "how big is this?" are a range, a range with low confidence, and "I need to look first".
· 7 min read
When a team is over-committed, say which thing slips
The honest response to too much work is not more effort or a re-estimate. It is naming which commitment moves, and telling the person who was promised it.
· 7 min read
Forecast what work will cost. Do not track what it did.
Finance needs a number before the work starts. That is a forecasting problem, and solving it with time tracking answers a different question badly.
· 7 min read
Allocation, not consumption: what an engineering manager should measure
The case for measuring what people are committed to rather than what they spend their hours on — and why consumption metrics degrade the data they read.
· 6 min read
FTE-months: a capacity unit you can defend in a budget meeting
Story points do not survive contact with finance. FTE-months are coarse, boring, and convert directly into the two answers leadership asks for.
After the commitment
Keeping a promise visible while it is being kept, closing it honestly, and learning something the next demand can use. Start here →
· 5 min read
The status report that answers questions
The four-part status report leadership can actually use: committed, closed honestly, at risk with reasons, and exceptions. Copy the shape.
· 4 min read
Your first 90 days: aim for one honest close
New engineering managers instrument velocity first. The record that actually builds trust is one commitment, closed honestly against what was promised.
· 5 min read
Reporting delivery to leadership: promises, not activity
Activity lists answer no question leadership has. Report promises against outcomes: what was committed, what closed honestly, what slipped and why.
· 5 min read
Close the quarter by counting the exceptions
Three counts close a quarter: honest closes, slips with named differences, and early-commitment exceptions. Each changes next quarter's line.
· 7 min read
Green is a judgement, not a colour
Status reporting decays into a colour nobody believes. What makes it useful again is requiring the reason, not the rating.
· 7 min read
"Delivered" is not an outcome
Closing a commitment with a checkbox loses the only information worth keeping: what shipped, and how it differed from what was promised.
· 6 min read
A retrospective that isn't theatre
Most retrospectives produce agreement and no memory. The one-question format: require one written lesson, attached to the work it came from.
· 6 min read
What "complete" should mean
Most systems call work complete when it stops. A more useful definition: complete when the outcome is recorded and something was learned.
Planning that stays honest
Separating fact from assumption, modelling cross-cutting work, and knowing where AI belongs. Start here →
· 6 min read
The RAID log, minus the theatre
Risks, assumptions, issues, dependencies — the RAID log is the right instinct wrapped in the wrong ritual. What to keep, and what a log can't hold.
· 5 min read
A discovery is a decision with a deadline
A spike that never ends is a parking lot. What separates discovery from research is a time-box, a target date, and a conclusion someone must record.
· 7 min read
AI should draft and challenge. It should not decide.
Where an LLM genuinely helps in delivery planning, where it must not be trusted, and the design rule that keeps the two apart.
· 7 min read
The dependency you don't own
Most delivery risk sits in work another team has to do for you — and the usual tracking treats it exactly like work you control.
· 7 min read
A decision without a record is a decision you will make again
Teams re-litigate the same architectural and scoping calls every few months, because what was recorded was the outcome and never the reasoning behind it.
· 6 min read
Scope is mostly what you're not doing
An in-scope list describes an intention. The out-of-scope list is what actually holds when someone asks for one more thing in week six.
· 6 min read
"No known risks" has to be a valid answer
Planning templates that only accept filled-in fields get filled in. The result is a risk register full of fiction, which is worse than an empty one.
· 8 min read
Vertical and horizontal work: the distinction planning tools miss
Delivery streams and cross-cutting concerns behave differently, need different capacity models, and fail differently. Most tools call both an "epic".