Delivery & Risk
Proactive Is Not a Personality Trait. It's a Calendar Entry.
Principal Architect · 16 April 2026 · 6 min read
Nobody told me the difference between being proactive and being quick, so I got it wrong for most of a decade. Replying fast is not being proactive. It is being good at reactive, which is a different skill and a much cheaper one.
"Be more proactive" is the worst feedback in our industry
Someone has said it to you in a review, probably in the bit at the end where they run out of specifics. It sounds like guidance. It isn't. It describes a result and dresses it up as a behaviour, and nobody has ever gone back to their desk and successfully done "more proactive" on a Tuesday.
What the person actually meant was something you could have written in a diary. You should have told me about the supplier lead time in April rather than in June. You should have asked the finance director's question before he asked it in front of the steering group. You should have chased the security sign-off instead of waiting for it to arrive.
So when you give that feedback to someone on your team, name the moment. "In the design review last week, you spotted that the failover path was untested and you noted it. I needed you to book the test." That is coachable. "Be more proactive" is a personality note, and personality notes make people anxious without changing anything they do.
The same goes for the version you tell yourself.
Thinking two steps ahead is a diary problem, not a brains problem
The leaders who look like they can read the future are mostly doing one boring thing. They have protected time in the week when nothing is on fire, and they spend it on week six.
That is the whole trick. If it isn't in the calendar it doesn't happen, because week one will always expand to fill week one. There is always another incident, another escalation, another thing that genuinely does need you today. Reactive work is infinitely available and it feels like progress, which is exactly why it eats everything.
Mine is Thursday morning, 45 minutes, and the invite has the question written in the title so I can't quietly turn it into another status call: what will we wish we had started today, six weeks from now?
It is a low-glamour meeting. Two people, a document, some silence. It has saved me more dates than any tool I have ever bought.
The data centre exit that survived because of a Thursday morning
A building society, two ageing data centres to get out of, an 11-month plan and an infrastructure group of about 18 people. I ran that weekly session with the network lead, nobody else, 45 minutes.
In the first month it turned up three things the plan had quietly assumed away. The cross-connect lead time from the colocation provider came back at 9 weeks, not the 3 the schedule had inherited from a previous project. The network vendor had a change freeze running from mid-December to the first week of January, sitting exactly across the planned cutover weekend. And a wildcard certificate was due to expire 5 days after go-live, owned by an engineer who had left the year before.
None of that was clever. There was no insight involved. It was just two people reading their own plan forwards instead of backwards, with the phone in a drawer.
We moved the go-live date once, in month two, by 5 weeks. It cost us one uncomfortable conversation with a sponsor who had already told his board a date. That is a genuinely bad afternoon and I am not going to pretend otherwise. But moving a date in month two is a planning decision. Moving it in month nine, with contractors booked and a freeze looming, is a failure, and everyone in the room knows the difference.
Answer the question on the slide before it gets asked out loud
The second half of the habit is cheaper and works immediately.
Before any meeting with people more senior than you, write down what they are going to ask. You already know. The finance director asks about run cost after go-live. The operations director asks who carries the pager and whether they have been trained. The sponsor asks whether the date has moved and, if it has, what he is supposed to tell his boss.
Put the answers in the pack. Not in an appendix, in the body, before the question comes. The effect on a room is out of all proportion to the effort. The conversation moves from interrogating you to deciding something, which is what you wanted from the meeting in the first place.
Where you don't know the answer, say so in the pack with a name and a date next to it. "We don't have the run cost yet. Priya has it by the 29th." That is not weakness. Weakness is being asked, guessing, and being wrong on the record.
The unglamorous half: closing your own loops
Almost everyone in this industry is decent at saying "I'll find out." Far fewer are reliable at the part that comes after.
Keep a list of things you owe people. Not a project plan, not a ticket queue, a list of promises with names on it. Every time you say you will check something, it goes on the list, and the list gets read before you shut the laptop. When you come back to someone unprompted two days later with the answer they had already given up on, you get a kind of trust that no amount of competence in a meeting will buy you.
It also protects you from the most common way capable people lose credibility, which is not failing at hard things. It is being slightly unreliable about small ones, repeatedly, until people start routing around you.
Monday
Book one recurring calendar entry. Forty-five minutes, a day that is not Monday or Friday, one other named person, and put the question in the title so it can't drift into a status update.
In the first session, write the list of everything that has to be true six weeks from now, and put a name against the two items nobody owns. Then go and tell those two people that they own them, today, out loud, rather than hoping they read it in a document.
Principal Architect
Founder of the Institute of Technical Leadership, writing from two decades of technical delivery.


