> ## Content Index > Fetch the complete content index at: https://www.scopecreep.co.uk/llms.txt > Use this file to discover other available public pages before exploring further. # The status meeting that manufactures surprises - URL: https://www.scopecreep.co.uk/the-status-meeting-that-manufactures-surprises/ - Published: 2026-09-09T13:35:08.000Z - Updated: 2026-09-09T13:35:08.000Z - Author: Jamie Wright - Tags: Project Management In an earlier article about learning from [bad managers](https://www.scopecreep.co.uk/take-the-learnings-from-your-worst-manager/), one line kept coming back to me afterwards: if people only ever report good news to you, you have built a reporting system that manufactures surprises. It deserved more than a sentence, because it describes the most common failure in project delivery, and the least diagnosed, since the person best positioned to diagnose it is the person causing it. Here's the shape of it. A project reports green for weeks. Everyone attends the meetings, everyone says the right things, the dashboard glows reassuringly. Then, close to the deadline, the truth arrives all at once: it was never green, everyone below a certain level knew, and the surprise you're experiencing was assembled patiently, meeting by meeting, by a system you built and chaired. ## Watermelon projects The term for this: the watermelon project. Green on the outside, red all the way through. What's worth understanding is that no one decides to grow one. A watermelon is cultivated accidentally, by reactions. Somebody once brought early bad news to a status meeting. Perhaps they said a dependency looked shaky, or an estimate felt optimistic. And the room reacted: sharp follow-up questions with a courtroom flavour, a request to "unpack why we're only hearing this now", visible disappointment from someone senior, or the classic, being asked to stay behind afterwards. The messenger survived. But everyone watching that meeting ran the same quiet calculation: bad news costs the bearer, delivered here, in front of these people. From then on, the system optimises itself without another word from you. Problems get one more week of private fixing before they're mentioned, then another. Risks get rounded down on their way up each level, so that a developer's "this is in trouble" arrives at the steering meeting as "some minor headwinds". Nobody is lying, exactly. Everyone is managing your reaction, and your dashboard has quietly stopped measuring the project and started measuring the fear in the room. ## The question that gets honest answers Part of the fix is embarrassingly small: change the question. "Are we on track?" is a yes/no question asked in public, where one of the answers is expensive. You will receive yes for as long as yes is survivable, which is precisely until it isn't. "What's worrying you most right now?" is a different instrument. It presumes worry exists, which it always does, so voicing it stops being a confession and becomes answering the question as asked. It has no cliff-edge answer. And asked consistently, it teaches the team what you actually want, which is early sight of problems, not weekly reassurance. Other versions of the same instrument: "what would you fix with one extra week?", "what's the thing we'd regret not discussing today?", "where are we relying on luck?" All of them make honesty the compliant option rather than the brave one. ## Reward the messenger, publicly, on purpose Questions open the door; reactions decide whether anyone walks through it twice. The single highest-leverage habit available to anyone running a status meeting: when early bad news arrives, thank the person, visibly, before addressing the news. "Genuinely glad you've raised this now, while we can still do something about it." Then, crucially, make the follow-up about the problem, not the person's proximity to it. This costs nothing and feels unnatural, because your adrenaline wants to interrogate the news. Do it anyway, because the room is watching what bad news costs, and you're setting the price. Set it at zero and information starts flowing uphill of its own accord. Set it high, even once, in one bad moment, and you'll pay for that moment in silence for months. Ask me how I know. ## Separate the status from the meeting The structural fix: stop using a meeting to collect status at all. Status is data, and data should arrive in writing, asynchronously, before anyone gathers: what moved, what's blocked, confidence level, no theatre. Then the meeting, shorter now, spends its time where a meeting earns its keep: on the two or three items flagged red or wobbly, solving rather than reciting. This does more than save time. Written status, submitted without an audience, is more honest than performed status, because the performer's incentives are gone: no room to read, no senior face to manage, no colleagues to look competent in front of. And when the meeting only ever discusses problems, discussing problems becomes the norm rather than the incident. You've rebuilt the meeting so that bad news is the agenda instead of the ambush. One warning as you do this: watch your confidence numbers. If every item in every written update says 90%, the fear has simply moved into the form. Confidence scores are only useful in a system where writing 60% is safe, which brings us back, as everything here does, to your reactions. ## The mirror The uncomfortable summary is that a status report is a mirror. It reflects the project only as accurately as it's safe to. If yours has been glowing green and the ground feels strangely soft underfoot, the question isn't whether your team is being straight with you. It's what you did, in some meeting months ago that you've forgotten and they haven't, that made straight expensive. The good news: the system that optimised for your reactions will re-optimise the same way. Change the question, price the bad news at zero, move status into writing, and hold it for a quarter. The first honest red you receive will feel like failure. It's the opposite. It's your instruments coming back online, and it's the last surprise the system needs to manufacture.