Delivery & Risk
The Two Hour Habit That Stops Projects Going Sideways
Principal Architect · 14 April 2026 · 6 min read
I lost a delivery date once while working harder than I ever have. Fourteen hour days, every ticket answered, every meeting attended, inbox at zero most nights. The project still went sideways in week nine, and when I went back through it afterwards, every single cause was visible in week four.
I just never looked up.
Being reactive doesn't feel like failing
That's the whole trap, and it's worth sitting with for a second. Reactive work feels excellent. It's responsive, it's visible, people thank you for it, and by six o'clock you can list what you did.
Proactive work feels like nothing. You spend two hours and produce no output anyone can see. You send four messages and get two shrugs and a "yeah, good point, I'll check". Nothing happened. The reward for doing it well is a week in which something notably doesn't go wrong, which is not a reward your brain recognises.
So the honest problem isn't that technical leaders don't know they should think ahead. Everyone knows. The problem is that thinking ahead loses every single time to an urgent thing, because the urgent thing has a person attached to it who is waiting for you.
Which is why this has to be a block in your calendar with a name on it, rather than an intention you carry around. Nobody has ever looked three weeks ahead by deciding to be the sort of person who looks three weeks ahead. You book the time, or it does not happen.
What actually goes in the two hours
Two hours, once a week, same slot. Not with the team. Not with a laptop full of Slack notifications. Mine is Friday morning, but the day matters less than the consistency.
You're doing four passes, and each one is a different question.
The loop you owe. Everything you said you'd come back to and haven't. Not your task list, which contains work. This is the promises list: the question from the security lead you said you'd check, the estimate you told procurement you'd confirm, the answer you owe an engineer about their objective. Half of these take four minutes each. All of them are currently costing someone else a decision they can't make.
The three week horizon. Not next week. Three weeks out. What needs to be true by then that isn't true yet? Who needs to have signed something, ordered something, or freed someone up? Three weeks is the right distance because it's far enough that you can still fix things cheaply and close enough that you can see it clearly.
The question you're about to be asked. Put yourself in your sponsor's chair on their worst day. What will they ask you in the steering meeting? If you don't have the answer, that's this week's work, not next week's embarrassment. This single habit changes how senior people see you more than anything else on the list.
Where the slack went. Every plan has some. Look at whether you've quietly spent it. A plan with no remaining contingency in week five is a plan that will be late, and the earlier you say that out loud, the more options everyone has.
That's it. No tooling, no template, no ceremony. A notebook and an uninterrupted room.
Week four of a twelve week migration
Here's what it looks like when it's working.
A 12-week migration of a warehouse management platform for a logistics business. Week four, Friday, two hours.
The loop pass turns up three things. The lead owes the finance business partner a confirmation on the licence count, four days old. They owe an engineer an answer about whether she's leading the cutover rehearsal, which she has asked about twice and is clearly starting to read as a no. And there's an unanswered question from the third-party integrator about test data, sent on Tuesday, sitting in a thread that went quiet. Three messages, eleven minutes total.
The horizon pass finds the real one. Week seven needs a full-day freeze on the warehouse floor for the parallel run. The operations manager has verbally agreed. Nothing is booked, and the site plans shift patterns six weeks in advance, which means the actual deadline for that decision was yesterday. One call on the Friday afternoon gets it into the shift plan. Skip the two hours and you find this in week six, when the answer is "you can have it in week ten".
The sponsor pass produces one uncomfortable prediction: they will ask whether the go-live date is still safe, and the truthful answer is "yes, if the integrator hits their week six milestone, and I have no evidence either way". So the lead asks the integrator for evidence on the Monday, rather than being asked for evidence on the Thursday.
The slack pass shows testing has already eaten five of its ten contingency days, in week four of twelve. Nothing to do about it yet. It goes in the update as an amber flag so that when it becomes a problem in week eight, nobody is hearing about it for the first time.
Two hours. Nothing dramatic. One booked shift freeze that would have cost three weeks, and a sponsor who now finds out about risks from you rather than from someone else.
The version that fails
Worth naming, because people do this bit wrong. The two hours is not for building a risk register nobody reads, and it's definitely not for producing a document that proves you spotted something. If the output of your two hours is an artefact rather than a set of actions with names and dates on them, you've turned a leadership habit into paperwork, and paperwork is where accountability goes to hide.
Every item that comes out of the session ends up as one of three things by the end of that day: something you did, a message to the person who can do it, or an escalation with a recommendation attached. Nothing survives the session as a note to self.
Monday
Open your calendar and put a two hour recurring block in it, before the week fills up. Give it a name your team will understand, something like "delivery review, do not book", and tell them what it's for so they stop treating it as free space.
First session, do only the first pass. Write down every single thing you've told someone you'd come back to and haven't. That list will be longer than you expect, and clearing it will take you less than an hour.
Principal Architect
Founder of the Institute of Technical Leadership, writing from two decades of technical delivery.


