If you are not technical, the weekly update is the only instrument you have, and most weekly updates are designed to be reassuring rather than checkable. The fix is not to learn to read code. It is to ask four questions that cannot be answered with a confident paragraph.
A good question has one property: a vague answer to it is visibly vague. "How is the payment work going?" fails that test, because "good progress, a few edge cases left" is an acceptable-sounding answer that contains nothing. The four below cannot be answered that way.
Key takeaways
- Ask for things, not for status: A demo, a date, a number. Status is a claim; an artefact is evidence.
- Vagueness is the signal, not the content: You are not checking the answer, you are checking whether a specific answer exists.
- Write the answers down: Most of the value comes from comparing this week's answer to last week's.
- Four questions is enough: A longer list turns the meeting into a ritual, and rituals get performed rather than answered.
Question 1: what can I use today that I could not use last week?
Not what was worked on. What changed that you can open yourself.
This is the only question that cannot be satisfied with effort. A week where the honest answer is "nothing you can see yet, we are rebuilding the data model" is a perfectly good week, but it is a different week from one where something shipped, and you should know which kind you had.
Expect a link, a test account, or a screen recording. If the answer is regularly "nothing visible", ask how many weeks in a row that has been true. Three is normal on a hard piece of infrastructure. Eight is a project that has lost its way, or a team that has stopped breaking work into pieces small enough to finish.
Question 2: what is the next thing that will be finished, and when?
One item, one date. Not a list, not a sprint goal, not a percentage.
The value is in the repetition. Write down the answer. Next week, compare. A team that hits its own one-week forecast most of the time is a team that understands its own work. A team whose next-thing-and-date moves every week is telling you, accurately, that they cannot see the bottom of the task, which is worth knowing early rather than at the deadline.
You are not holding anyone to the date. You are measuring how well they can predict, which is the closest thing you have to measuring how well they understand the problem.
Question 3: what is currently blocking you, and who owns it?
Blockers are the most under-reported item on any project, because raising one feels like an admission. Asking for them routinely, every week, removes that cost.
The answer you want includes a name. "We are waiting on the payment provider" is incomplete; "we are waiting on the payment provider, I emailed them Tuesday, no reply, I will chase Thursday" is complete. Half the blockers on a typical project are things you could clear yourself in ten minutes: an approval, an account, an introduction, a decision nobody wanted to make.
If the answer is consistently "nothing is blocking us" while the dates keep moving, the blocker is inside the work and nobody has named it.
Question 4: what did we learn that changes the plan?
Software projects discover things. An integration that does not do what the documentation says, a data set that is dirtier than anyone expected, a rule in your own business that nobody wrote down. These discoveries are the main reason estimates move, and they are usually known weeks before they are reported.
Asking directly makes reporting them normal. It also gives you the raw material for the only judgement that really matters: is this project getting clearer over time, or less clear? A project that is getting clearer will land. A project where every week adds a new unknown will not, and no amount of pressure changes that.
What to do with bad answers
You will get one of three responses to a question like these: a specific answer, an honest "I do not know yet, I will find out", or a paragraph that sounds like an answer. The third is the one to watch, and the way to handle it is not confrontation. It is to ask the same question again next week, in the same words, and write down both answers.
Patterns are much harder to argue with than single instances. Four weeks of recorded answers will tell you more about a team than any audit, and they cost you twenty minutes a week.
If the pattern is bad and you still cannot tell whether the cause is difficulty or something else, that is the point at which someone technical needs to look at the actual work rather than the reports. That is a different exercise, and we describe it in what a technical audit covers.
Ali Boran Gazel