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 RSS The same points, as cartoonsTurning 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 with turning a request into a decision →
· 5 min read
How a platform team should take requests from other teams
An intake process for platform, data and other shared teams: split support from change requests, ask for the need, decide weekly and publish the list.
· 7 min read
How to write a one-page project brief
The six questions a one-page project brief answers, a weak and a strong line for each, what to leave out, and a plain-text template to copy.
· 7 min read
AI project requests: what to ask first
How to evaluate an AI use case before committing a team: the ordinary request bar, plus four questions about the task, the data, quality and failure.
· 9 min read
Declining a request by email: seven scripts to copy
Seven copy-paste emails for saying no: decline, park with a review date, ask what is missing, offer a smaller yes, redirect, answer sales, or tell a customer.
· 5 min read
The engineering intake process, end to end
The work intake process for an engineering team: one door, two questions, four recorded exits. No triage committee, no 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.
· 4 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.
· 4 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.
· 5 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.
· 4 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.
· 4 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.
· 3 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 with deciding what to commit to →
· 5 min read
Putting a project on hold: a review date, or it is a no
How to put a project or request on hold honestly: a review date or an explicit indefinite hold, what to write down, and what happens on the review date.
· 5 min read
Pushing back on an unrealistic deadline: three offers, not one no
How to push back on a deadline that will not hold: find out what kind of date it is, get a figure the team owns, and bring three offers instead of one no.
· 4 min read
Fixed scope or fixed date: pick one before you commit
A commitment can hold two of scope, date and capacity. How to choose which one flexes, how to write it into the commitment, and what to do when it moves.
· 6 min read
How much process does a request need? Four paths, chosen in a minute
Right-size approval by what a wrong commitment would cost: three questions, and four paths from a light confirmation to full planning to a recorded exception.
· 6 min read
How to prioritise tech debt against features
Tech debt loses planning because it arrives with no problem, outcome or cost of delay. Shape it like any demand, and know what evidence makes it win.
· 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.
· 4 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.
· 3 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.
· 5 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.
· 5 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.
· 4 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.
· 4 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.
· 5 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 with capacity and what to measure →
· 5 min read
How to justify engineering headcount: show what was turned away
A headcount case rests on four numbers: the team's honest capacity, what it committed and delivered, what was declined for capacity, and what that cost.
· 7 min read
Capacity planning when one team serves several product lines
Capacity planning for an engineering org with several product lines: plan the teams, rank across lines once per shared team. A worked example in FTE-months.
· 6 min read
How much capacity to reserve for unplanned work
Measure each team's interrupt rate over the last two quarters, hold the reserve as a named line, and decide now what happens when it runs out.
· 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.
· 3 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
How to plan engineering capacity for a quarter in four steps: each team's real capacity in FTE-months, sizing work, and what to do with what does not fit.
· 5 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".
· 4 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.
· 4 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.
· 5 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 with after the commitment →
· 5 min read
The say/do ratio: measuring delivery predictability without scoring people
The say/do ratio is commitments kept over commitments made. Three ways the number lies, how to count it from a record, and why it never sits next to a name.
· 5 min read
A project status meeting agenda that makes decisions
A 30-minute status meeting agenda: written updates first, then what changed, the decisions needed, changes to what was promised, and who is silent.
· 7 min read
Lessons learned: a template and examples
A three-sentence lessons learned template, six examples in weak and strong form, and how a lesson differs from a sprint retrospective and a post-mortem.
· 7 min read
How to tell stakeholders a project is late
When to tell stakeholders a project is delayed, the four parts of the message, and five project delay emails to copy, from a new date to a stop.
· 6 min read
A change request process that fits on one page
A lightweight change request process: what a request must state, who decides, and when to re-baseline with a reason. With a copyable checklist.
· 6 min read
When to stop a project you already committed to
Sunk cost, the three signals that justify cancelling, kill criteria set at commitment time, and how to close a stopped project honestly.
· 3 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.
· 2 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.
· 4 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.
· 4 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.
· 4 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.
· 4 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 with planning that stays honest →
· 4 min read
A risk register that gets read: mitigate it, accept it, or it blocks
A project risk register in five columns, the three ways a risk can leave it, and the rule that makes people read it: a serious open risk blocks the commitment.
· 5 min read
How to run a pre-mortem: forty-five minutes before you commit
A project pre-mortem in 45 minutes: imagine the failure, write reasons alone, pick the fatal ones, and turn each into a risk, a dependency or a cut.
· 6 min read
Delivery roadmap: how to build one that survives the quarter
How to build a delivery roadmap from commitments: the five columns, a worked example, the update rhythm, and the three ways a roadmap rots.
· 4 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.
· 5 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.
· 4 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.
· 4 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.
· 4 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.
· 5 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".