I Wrote Down Eight Risks. All Eight Happened. Nobody Moved.

Months after I'd left Adaptavist, the CEO of one of our customers messaged me on LinkedIn. Hey, what happened? We were relying on it.

He was asking about an e-learning product I'd built there, the line that eventually became Learn for Jira. It had been killed. I got on a Zoom with him and walked him through the whole thing. Most of what I told him was already written down in a document from more than a year earlier. Before we started building, I'd formally outlined eight risks to that product. By the time it was shut down, all eight had materialized. Not five of eight, not the obvious ones. All of them.

I want to be careful about how that sounds, because the satisfying version of this story is not the true one. The true one is worse and more useful.

The register worked. That was never the problem.

The risk I remember most clearly is the one that did the most damage: we were building training for a platform, and the company that made the platform started investing in its own training. They could outspend us without noticing they'd done it. That was on the list from the beginning, described about that plainly.

The others were the ordinary kind – the ones any experienced person writes down at the start of a thing like this, and which sound like reasonable concerns rather than predictions. I'm not going to reconstruct them one by one, because I'd be reconstructing rather than remembering, and the specific contents matter less than the fact that the document existed, was accurate, and sat there.

We also went nearly a year into building before hiring our first marketing person. For a product whose entire thesis depended on reaching people who didn't know they wanted it, that's not a subtle gap. Nobody was hiding it. It just never became the thing anyone did something about this week.

What a register is actually for

Most advice about risk registers is about how to build one – the columns, the scoring, the likelihood-times-impact matrix, the cadence of review. That advice is fine and it's solving the easier half.

A register is a detection instrument. It's good at surfacing what a group of experienced people already half-know and haven't said in the same room at the same time, and the act of writing it down does real diagnostic work. Mine caught everything. Eight for eight is not a near-miss.

But detection and action are separate systems, and only one of them lives in the document. A register has no authority, no budget and no relationships to spend. It records that someone noticed. Whether anyone moves depends entirely on the incentives around the table, and the register has no way to reach those. Scoring a risk 9 out of 10 doesn't obligate anybody; it just means the row is a different colour.

So when a register fails, it usually hasn't failed at its job. It did the detection and then stopped, because that's where its job ends, and everyone mistook the completed document for a completed response.

Why written-down risks stay untreated

For a long time I filed this under my own failure to escalate loudly enough. Then I read the research, and it turns out this is the normal case, studied and named.

Kutsch, Denyer, Hall and Lee-Kelley examined 21 information-systems projects across 10 organisations. In all but five, the project manager had disengaged from formal risk management before ever executing a risk response, and in most of the projects the majority of formally identified and assessed risks were never allocated to anyone or treated at all. Identified, written down, agreed – and then left there.

In related work, Kutsch and Hall put names to the rationales people use to leave a known risk alone. The one that landed hardest for me was taboo: raising a risk creates anxiety in stakeholders, and in the extreme case naming it clearly enough might get the project cancelled. So risks get suppressed at the point of identification, or stated in language soft enough to survive the room. The others are variations on the same theme – arguing the risk isn't really in scope, disputing whether the estimate is credible, or agreeing it's real but deciding the cost of acting now outweighs waiting to see whether it actually happens.

Read that last one again, because it's the one that sounds most like good management. Waiting to see whether a risk materializes is a defensible position right up until it does.

Nobody gets credit for the disaster that didn't happen

Underneath all of it is an incentive problem that no amount of process fixes.

A five-year survey of project teams published this year found that in high-risk situations, upward risk communication failed about 79% of the time, and in the most dangerous conditions – high perceived risk, low perceived capability to handle it – the misalignment between what the team saw and what leadership was understood to see ran to roughly 97%. Exactly the configuration where early action matters most is where the signal reliably doesn't arrive.

The survey's explanation is the part worth keeping. Acting early on a risk has costs that are immediate, visible and attributable: delay, reallocation, someone's roadmap gets worse, someone looks like they overreacted. The benefit is a disaster that doesn't happen, which is invisible and belongs to nobody. No one has ever been promoted for the outage that didn't occur. Given that trade, optimism isn't a character flaw in the organisation, it's the rational play for almost everyone in it.

Which means the person who says the inconvenient thing is spending something real to say it, and the register – a document with no job title and nothing at stake – can't spend anything on your behalf.

What I'd do differently

Not "escalate harder." I escalated. The document was clear.

What I'd change is that I'd insist on a decision rather than an acknowledgment. There's an enormous difference between a room agreeing that a risk is real and a room deciding what it's going to do about it, and the first one feels almost identical to the second while costing nothing. If the answer is "we accept this risk and we're proceeding anyway," that's a legitimate answer and I've given it myself – but it has to be said out loud, by a named person, and written next to the risk. Accepted risks and unexamined risks look the same in a register six months later, and only one of them was a choice.

The other thing I'd want is someone from outside the incentive structure to read the list. Not because they're smarter. Because they can say "this one is going to kill you" without it costing them a relationship, a roadmap slot, or a reputation for being difficult. Everyone inside the building is paying a price to raise their hand. Someone outside it isn't, and that's most of what you're actually buying.

The part I didn't expect

The product died, and it was genuinely hard. Frustration, embarrassment, guilt, and an "I told you so" I couldn't say to anyone. I'd built the thing. My name was on it either way.

What happened next was not what I braced for. When the CEO asked me what happened, I told him straight – including the parts that were on me – and what he took from the conversation wasn't that I'd been right. It was that I could look at something that wasn't working, walk away from the sunk cost, and describe it accurately afterward. He told me that if I ever needed a job, he wanted to be the first person I called. He'd watched the whole thing from the outside, and he'd landed where I had: we underinvested and missed the window.

A public loss didn't make my position worse. Being able to tell the truth about it made it better, which I did not see coming and have counted on several times since.

If you keep a risk register, go open it. Find the oldest item nobody has touched, and get a person's name and a date next to it, or an explicit decision to accept it and move on. Either one is worth more than the document you have now.