What Would You Notice If You Had Unlimited Time?
Cover image by cottonbro studio
Once upon a time, in a specification workshop, somebody agreed to something.
It was a small thing. A sensible thing. The client asked whether a particular function could behave the way their old system behaved, and the answer was yes, of course, that's broadly what we'd planned anyway. Everyone nodded. The meeting moved on. Nobody wrote it down as a decision because nobody experienced it as one.
Except that "broadly what we'd planned anyway" and "what we'd planned" are not the same sentence. The gap between them is about four days of development effort, one integration nobody has scoped, and a quiet contradiction with something in the commercial baseline that was agreed eleven months ago by people who are no longer on the programme.
On a good week, I catch that. On a good week, something in the back of my head goes off on the train afterwards, and I dig out the original specification and check. But I run multi-year, multi-platform programmes. There is no version of my job that consists of good weeks stacked end to end. The thing in the back of my head is competing with forty other things in the back of my head, and some weeks the train journey is just a journey.
For most of my career I assumed this was simply the job. You hold as much as you can, you drop as little as you can, and you get better at knowing which things will hurt most when dropped.
Then, over the last few months, unintentionally, I stopped assuming that.
The question I stopped asking
Like most people in some sort of delivery role, I started using AI the way everyone starts using AI. Summarise this meeting. Draft this status report. Update my plan. Reasonable requests, competently handled, mildly useful. The output was fine and the experience was forgettable, like hiring an assistant who does exactly what you say and nothing that you mean.
The shift happened when I changed the question. Somewhere along the way, without quite noticing I'd done it, I stopped asking AI to do my work and started asking it to protect my judgement.
The intent of the prompt that captures it best is one I keep coming back to:
Don't let me forget the things I would normally notice if I had unlimited time.
That is a different request. It doesn't ask the machine to be a project manager. It asks the machine to hold the standard I hold on my best day, and apply it on all the other days too.
One idea, three costumes
It's easier to show than explain, so here are three places this is changing how I work.
Take blockers. Ask AI to review a programme and it will cheerfully produce a list of them, sorted by age, which is roughly as useful as sorting your post by envelope size. Age is not impact. The questions I actually carry around are different: which of these threaten delivery right now, which are merely old, which are waiting on the client, which are waiting on us, and which don't matter until October? An item that's been open for ninety days might be irrelevant. An item opened on Tuesday might quietly be holding the critical path hostage. Distinguishing the two is programme judgement, and it turns out you can ask for it by name.
Or take specifications. A workshop generates decisions the way a bonfire generates sparks, and most of them are harmless. The one question that matters on a fixed-price programme is the one nobody asks in the room: has today's conversation changed the contracted solution, or merely explained it? Clarification is free. Adjustment might not be. The two can feel identical at the moment they happen, which is exactly why the moment they happen is the worst possible time to rely on a human to tell them apart. So now something tells them apart for me, every session, without fatigue and without the reliance on brain space on the journey home.
Or take the plan. The lazy request is "move these dates." The request I make instead is closer to a set of house rules: don't move a date unless you can tell me why it moved, which assumption changed, whether the new forecast is defensible, and whether we've accidentally buried a dependency in the process. A date that moves without its reason attached isn't a replan. It's an erosion.
Three different tools, on the surface. Underneath, they are the same tool three times, because they all preserve the same thing.
Where programmes actually fail
Here is the observation this whole experiment forced on me.
Programmes rarely fail because someone wasn't clever enough. They fail in the blur. An assumption gets repeated often enough that everyone starts treating it as evidence. A clarification offered in good faith in a workshop quietly hardens into a commitment. A forecast, produced under pressure to have a number, becomes a promise that nobody remembers making but everybody remembers hearing.
Evidence, assumptions, decisions, commitments. Four categories that every experienced programme lead keeps separate instinctively, and that every organisation under pressure works tirelessly to smear together. Most of what we call programme judgement is the unglamorous discipline of keeping them apart. And most of what we call programme failure is what happens in the weeks after they blurred, before anyone noticed.
No human can police those boundaries continuously across a multi-million-pound programme. Not because we lack intelligence. Because we lack bandwidth. The dependency count alone outruns working memory sometime around the second workstream.
Which is the thing I find quietly extraordinary about this technology. Not that it knows the answers. It frequently doesn't. But it never gets tired of remembering the questions.
Haven't we just built another artefact?
There's an obvious objection, and it deserves better than a brush-off. I've written before about how programme plans stop being read as information and start being deferred to as authority. Isn't this the same trap with better wiring? Build a system that remembers everything, and people will stop remembering anything, and start treating its output the way they treat the RAG status: as a verdict rather than a prompt.
They might. That risk is real, and I don't think it can be engineered away.
But it can be positioned away. The difference lies entirely in what you do with the output. If the machine says "this decision may have changed the baseline" and you copy that into a log, you've automated judgement, and made it worse, because now it carries the false authority of print. If the machine says the same thing and you argue with it, check the original document, and discover it was wrong, or half right, or right for the wrong reason, then something else has happened. You've been made to look at a thing you would otherwise have missed. The judgement was still yours. It just wasn't left to fend for itself at eleven o'clock on a Wednesday.
A second opinion tells you what to think. A second brain reminds you what you were going to think about. The distinction sounds small. In practice it's the whole game.
The standard, kept
I didn't set out to build any of this. I set out to survive a large programme, and somewhere in the middle of surviving it I noticed that the most useful thing I could hand to a machine wasn't my task list.
It was my standards.
The most useful thing I could hand to a machine wasn't my task list. It was my standards.
The things I check when I have time. The questions I ask when I'm fresh. The distinctions I hold when nothing else is competing for the space in my brain. None of that is automation in any sense the word usually carries. Nothing got faster. What got better was the floor: the quality of my worst day moved closer to the quality of my best one.
So I've stopped wondering whether AI will replace programme managers. It's the wrong question, the lazy question, asked about the wrong scarcity. Intelligence was never the constraint.
Attention was. And attention, it turns out, is the one thing I can now keep in supply.
Originally published on LinkedIn on 2026-07-16. Read the original article
Comments