What to ask for in a weekly update

Five questions, and they are the whole article. What got harder than you expected this week, and what did you do about it? What did you decide without me? What did we say would start this week that has not started? What would you cut if we lost a week? What is running in production now that was not running last week — and did anything have to be rolled back? Ask those five every week, in writing, and you will hear about trouble weeks before it reaches a date. Ask for a percentage complete instead and you will hear about it on the day the date moves.

The reason a normal status update fails a non-technical founder is not that engineers are evasive. It is that the standard format reports activity — tasks touched, tickets closed, a progress bar — and activity is not progress. The clearest statement of this comes from an unlikely place. The US Government Accountability Office's schedule assessment guidance says outright that "recording progress by entering percentage complete is not recommended, because scheduling software adjusts the remaining duration to yield the entered percentage complete. Estimating a percentage of work or time complete is an inexact science" (US Government Accountability Office, GAO Schedule Assessment Guide: Best Practices for Project Schedules, GAO-16-89G, December 2015).

The guide then explains exactly how the number misleads, and every clause will be familiar to anyone who has sat through a weekly call. "Task managers may confuse inputs and outputs, assuming that if they have worked 7 days on a 10-day activity, they must be 70 percent finished." "An activity could have used up 80 percent of its scheduled time yet have accomplished only 10 percent of the work." And the part that indicts most software updates directly: "While 25 percent complete may be a viable estimate for a 4-day activity, it is an entirely ambiguous progress measure for a 50-day activity." A founder told the build is sixty percent done at week six of a ten-week engagement is being told how much time has passed, dressed as how much work is finished.

The replacement is one substitution: stop asking how far along something is, and ask how much is left. The same guidance recommends it for the same reason — "asking activity managers for information on actual duration and remaining duration is a more natural question than requesting a subjective measure of time passed." So the question is how many working days of effort remain on this, and what date do you now expect, asked every week about the same named items. The value is not in any single answer. It is that remaining effort which does not fall is the earliest honest signal a project produces: a task at five days remaining for three consecutive weeks has consumed fifteen days and moved nowhere, and nobody had to admit anything for you to see it.

Question one: what got harder than you expected, and what did you do about it? A good answer is specific and already contains a response — the third-party API rate-limits us below what the import needs, so we moved it to a background job and it now takes four minutes instead of ten seconds, which changes the screen you saw in the demo. A bad answer is "nothing major". Something is always harder than expected in a week of software; an update with no friction in it has been polished for you, and polish arrives instead of warning.

Question two: what did you decide without me? This one does the most work, because the dangerous decisions are the ones nobody thought to escalate. Every week a team makes choices that look technical and are commercial: which cloud region the data sits in, which third-party service was added, whether a record is overwritten or versioned, what happens to a user's data when they cancel. Each is a line in a future security questionnaire or contract. A good answer is a short list with a reason and a reversal condition for each — we chose this, the alternative was that, here is what would make us change. A bad answer is silence, and the second-worst is a decision presented as already immovable. Which calls are yours and which are genuinely craft is set out in what a non-technical founder should own; this question is how you find out whether that division is being respected.

Question three: what did we say would start this week that has not started? Slippage hides in not-started work far more reliably than in late work, because a task that has not begun generates no news. It has no partial progress to report, no blockers to raise and no percentage to revise downward — it is simply absent, and absence is what a busy reader never notices. A good answer names the item, says why, and says what displaced it. A bad answer is an update listing only what was worked on, which is the default format of every status report ever written and the reason this question has to be asked explicitly.

Question four: what would you cut if we lost a week? This is the most useful question on the list and the one founders almost never ask, because it sounds hypothetical. It is not. The answer tells you three things at once: what the team privately considers least essential, whether they believe the date is real, and whether anyone has thought about the trade at all. A good answer is immediate and specific, because a team that has been sequencing properly already knows the order. A long pause means nothing has been ranked, so the first unplanned week becomes a negotiation under pressure rather than a decision already taken. Ask it every week even when nothing is wrong; watching the answer change is watching the plan think.

Question five: what is in production now that was not last week, and did anything have to be rolled back? This is the one question with an objective answer, and there is a well-researched vocabulary for it. DORA, Google Cloud's software delivery research programme, names five measures, of which four matter to a founder: deployment frequency, "the number of deployments over a given period or the time between deployments"; change lead time, "the amount of time it takes for a change to go from committed to version control to deployed in production"; change fail rate, "the ratio of deployments that require immediate intervention following a deployment"; and failed deployment recovery time, "the time it takes to recover from a deployment that fails and requires immediate intervention" (Google Cloud, DORA's software delivery performance metrics). Treat the first two as a habit, the last two as a warning light.

The point of asking is not to score the team, and the research is explicit that scoring is how the measure dies. The same guidance lists the pitfalls plainly: "Setting metrics as a goal. Ignoring Goodhart's law and making broad statements like, 'Every application must deploy multiple times per day by year's end,' increases the likelihood that teams will try to game the metrics." It warns equally against "having siloed ownership", since "isolating teams with specific metrics can lead to friction and finger-pointing." Read them as weather, not targets. A week with no deployment during active development is a question, not an accusation, and the useful follow-up is why — a hard problem, a broken pipeline, or work quietly accumulating into one enormous merge.

Insist that the update is written, and short, and the same shape every week. This is not ceremony. Google Cloud's DORA research found documentation quality amplifying the return on every technical practice it measured: teams with above-average documentation quality saw a 656% lift to organisational performance from continuous delivery against 63% for teams with below-average documentation (Google Cloud, DORA capabilities: documentation quality, from the 2022 State of DevOps Report). That research measures internal technical documentation, not status reports, so do not read it as proof that your weekly email is worth seven hundred percent of anything. Read it as evidence for the cheaper claim it does support: written-down knowledge is not overhead on this work, it is the multiplier on it. A verbal update leaves no record and cannot be compared with last week.

On cadence, track more often than you report. The same GAO guidance recommends exactly that: "Program managers should consider tracking progress in the schedule more frequently than the reporting period... If schedule status is being reported weekly, then progress should be tracked daily," because doing so "allows management insight into the causes of issues that are being reported before the end of the reporting period." For a founder that means the weekly written update sits on top of something the team already maintains daily. If Friday's update is the only place progress is recorded, it is a composition, not a report.

Five answers that should worry you, in ascending order. "On track" three weeks running with no friction named — nothing has been surfaced, so you are being managed rather than informed. The same item in progress for three consecutive weeks with no change in remaining effort. A decision you hear about first as something that cannot now be changed. A new third-party dependency added without being named, which is a subprocessor, a bill and a failure mode arriving together. And the most predictive of all: "we will catch up next week." Teams do not catch up; a plan that assumes recovery is a plan with no slack that has not yet admitted it. Two or more of those in a month is the moment to ask for remaining-effort numbers on every open item at once.

What you owe in return, because this is a contract and not an interrogation. Answer within a day when the update contains a question for you: the most common cause of a stalled week is a founder decision requested on Tuesday and delivered the following Monday. Never punish the friction you asked for — the first time a team reports something that got harder and is met with alarm, the next update is polished and the early-warning system stops working. And keep the questions stable: their value is in comparison across weeks.

Two structural things make the five questions easier to answer honestly, and both are chosen before the engagement starts. The first is a defined end: an AI integration sprint or any fixed-scope engagement gives every weekly update a fixed reference point, so remaining effort means something, whereas an open-ended retainer has no denominator and the question stops being answerable. The second is that the artefacts are yours as they are produced rather than at the finish — the full list is in the handover: what you must receive, and a team that commits to your repository from day one produces a weekly update you can verify rather than trust. A multi-tenant agency operating system we built is the shape where this matters most: projects, teams, contracts, invoicing, subscription billing, role-based access and an AI knowledge assistant — the kind of scope where what is not started matters more each week than what is.

On Monday, send the five questions to whoever is building for you and say you will ask them every week. Then do it. A startup software development company that welcomes this is telling you something real about how it runs, and one that finds it burdensome is telling you something equally real — for a team that already knows the state of its own work, the questions take about twenty minutes a week. If you are still choosing who to ask, the same tests apply during selection, and they are written up in the criteria for choosing a software development partner.