The Risk You Can't Name Is the One That Lands

Two in the morning, a cutover weekend, and a room of tired people staring at a screen because the third party payment gateway won't accept traffic from the new address range. Someone eventually says the sentence I still think about: "I did wonder about that, actually." He'd wondered about it in May. It was now November. He'd never said it out loud because he wasn't sure enough to raise it and he didn't want to look like he was creating work.

Look at any risk register you've ever seen. Supplier lead times. Key person dependency. Budget overrun. Integration complexity. Environment availability.

They're all real. They're also all safe to write down, and that's why they're there. Naming them costs you nothing socially. Nobody is embarrassed by "resource availability risk". It doesn't accuse anyone, it doesn't reveal that you don't understand something, and it doesn't imply that a decision already taken was a bad one.

The risks that actually sink deliveries are the ones with a social cost attached to saying them. Try these out loud in a room and feel the difference:

"I don't think the client's own team can do their half of this, and their programme manager knows it."

"The architecture we signed in February assumed a data volume nobody has checked since, and I suspect it's wrong by an order of magnitude."

"We are three months in and I still can't tell you who signs off go live."

"Half the team think this design doesn't work and they've stopped arguing about it because they lost."

Every one of those is a genuine risk with a clear consequence. Not one of them is going to appear on a register that's filled in by emailing round asking for risks, because each one requires somebody to admit ignorance, contradict a superior, or say something uncomfortable about a colleague. Silence is free. Speaking up costs.

That's the actual problem with risk identification, and it is not solved by a better template. Your register is not a reflection of what threatens your project. It's a reflection of what your team feels safe writing in a shared file with their name attached.

There's a second category too, and it's quieter. The risks nobody can name because nobody has the full picture. The network engineer knows the address ranges are changing. The integration developer knows the gateway has an allow list. Neither of them knows the other fact, so neither can form the sentence, and the risk exists purely in the gap between two people who've never been in a room together. Nobody in that cutover at two in the morning was negligent. The information was distributed across three heads and no process ever brought the heads together.

So here's the technique that beats "does anyone have any risks", and it is the single highest value hour I know of in delivery work.

Get six or seven people in a room. Mixed: not just your seniors. Include the person who does the builds, the tester, whoever talks to the client's operations team most. Then say this, and say it in the past tense, which is the part that matters:

"It's Tuesday the fourteenth of March. The project has failed. It's obvious to everyone, it's been escalated, the client is furious. Take four minutes on your own and write down what happened."

The past tense does something to people's brains that a question about the future does not. Asking "what might go wrong" invites speculation, and speculation feels presumptuous, so people offer you the safe generic answers. Telling them it has already failed removes the social risk entirely. They're not accusing anyone or predicting doom. They're describing a hypothetical that you invented. In that frame, people will write down things they would never say in a status meeting.

I ran one of these on a data centre migration at a payments processor, with a 16-person digital team. Eight people in the room, four minutes of silent writing, then round the table. The things on the register before the session: hardware delivery, change freeze windows, key person dependency. The things that came out of the session:

The only person who understood the replication setup was three weeks from the end of a contract that nobody had renewed, and two people in the room had assumed someone else was handling it.

The client's application owners had not been told the migration was happening in their maintenance window, because the communication plan assumed their programme office would cascade it, and their programme office had been restructured in January.

Nobody could name who would make the call to roll back, or what the criteria were. Four people gave four different answers, all of them confident.

None of those three were on the register. All three were known, partially, by somebody in the room. The migration went fine, and it went fine because of a Wednesday afternoon in a meeting room with a whiteboard, not because of the register.

The extra trick: when the writing is done and people are reading theirs out, watch for hedging language rather than for the headline. "It should be fine as long as they get us the credentials." "I'm fairly confident the throughput is okay." "In theory the failover is automatic." Every one of those is a risk wearing a disguise. Stop the room and ask the follow up. What happens if the credentials come late. Who checked the throughput, and against what number. When was the failover last actually tested, with a date.

The hedge is the person telling you where the uncertainty lives while trying to remain polite about it. Learn to hear it and you will find more real risk in a corridor conversation than in a quarter of register updates.

Book a room for this week. Thirty minutes is enough. Invite six people including at least two who are not senior and at least one who talks to the client more than you do.

Give them the failed project, the specific date, the four minutes of silence, and then go round the table one at a time so nobody gets talked over by the loudest person. Write everything on the board without arguing with any of it. Arguing in the session teaches people the price of speaking, and then you never get the good ones again.

At the end, pick the three that made your stomach drop. Those go on the register that afternoon, with your name against them, a mitigation, and a date. The rest can wait.

And the person who says "I did wonder about that, actually" gets a thank you in front of everyone, loudly, on the spot. That's the moment that determines whether anyone tells you anything next time.