How to fix your decision making processes with Andrea Magnorsky

Satisfying Software – Andrea Magnorsky - Transcript

Why companies struggle to make good decisions

Gien: Why do you think companies are bad at making decisions?

Andrea: I wonder if companies understand their decisions well enough to know whether they're making good ones. They may have big processes, but the real reasons behind those decisions tend to get lost in translation — or something else gets recorded. Or the big decision gets broken down into so many smaller decision records that you can't see the wood from the trees. I'm more interested in how to track those trees of decisions.

Gien: I've noticed similar things. Companies sometimes have a framework in place and think, that's enough. We have a process, we follow it, and we'll get a good decision at the end. But the process only guides a small part of it. The analysis, the generation of options — that's just not there. Or the problem is completely wrong: the decision you're trying to make is fine in isolation, but it won't actually solve your problem.

Andrea: And it doesn't start at the problem. By the time you're engaging with someone about a decision, you ask where the problem was discussed — and you find out that John wrote a 35-page document, but nobody read it. There's a tendency to split up and delegate problems to gain efficiency, but this strips out the shared understanding of the problem space, the generation of options, and the actual decision itself. A decision that isn't implemented isn't really a decision. And if it was "made" but nobody followed through, different people will have completely different versions of what happened. The truth ends up living only in the software — understood only by people far removed from the original decision-making.

Decision records: making them useful rather than ceremonial

Gien: Communicating a decision afterwards — at the very least making sure everyone who needs to know is informed — is very lacking. And when I look at Architectural Decision Records in companies, there's often no guidance on how to actually analyse a problem, generate options, and work through to a final choice. The ADR template is there, but it gives you nothing about the process of arriving at a decision.

Andrea: The problem gets worse in bigger companies, where people are handed a framework and told to use it — without any sense of what granularity to work at or how to engage with it meaningfully. What I've seen work is introducing decision records not as a form to fill in, but as an iterative process. You write a draft, add what you know about the context, list pros and cons, ask questions, and invite the people who'll be affected. Iterate. Use some kind of forum — synchronous if possible, when you're starting out — where people can engage with the document and address comments before it's accepted. And be explicit about which scale of decision you're documenting: a decision within a team looks different from one that affects multiple teams, even if the bones are similar.

Gien: One thing I often hear is that teams responsible for a decision do want input from others — it's going to affect them — but they never get any response. And when I ask how they sought feedback, they say they sent a link to the page and asked for comments whenever people had time. That's so vague it's almost guaranteed to fail.

Andrea: That's exactly why I think you need to start synchronously. Moving to async works once people know what good looks like — once they've learned to engage usefully with a decision record. If you jump straight to async with no model for what useful feedback looks like, you lose everything in translation. The template and naming matter less than you think; whether it's an ADR, an RFC, or your company's own format doesn't matter. What matters is that it contains enough context that someone reading it in six months can tell whether circumstances have changed enough to warrant revisiting it. That doesn't mean ten pages — it means the right content.

Gien: And writing concisely is genuinely hard. I use visualisation techniques — pro-con mapping and a few other frameworks — so by the time we're done working through the decision, most of the content is already there and I can pour it straight into the record without a huge amount of extra work. But it's still work.

Andrea: Even with a framework, going through it properly takes time. And the more people involved, the longer things take — not just to include them, but because if a decision affects a lot of people, it will generally take longer to implement too.

Involving the right people — and no more

Gien: People often can't distinguish between the different levels of involvement. Some people have essential knowledge — you genuinely can't make a good decision without their input. Others can contribute something useful asynchronously. And some just need to be informed after the fact. But organisations tend to collapse these categories and involve everyone the same way.

Andrea: And involving the wrong stakeholders can massively derail a decision. If a C-suite person turns up — maybe because you hoped their presence would help with influence — the dynamics in the room shift. People go quiet, or they align with the most senior voice. The discussions that need to happen stop happening. It's the HIPPO problem: the Highest Paid Person In the room tends to shrink conversations, whether through agreement or silence.

Gien: And sometimes the HIPPO feels pressure to have an opinion because people expect it from them — even when the reason they were invited was just to be informed. In which case, you can cut them out of the whole discussion and just send an email afterwards.

Andrea: Their position is genuinely hard, though. Senior leaders make a lot of decisions under high uncertainty, and they're used to appearing certain — or at least projecting confidence — which can read very differently to a room of people who want to validate their thinking more carefully.

Gien: The feedback loops are also completely different. As a software developer, you push to production and you can see fairly quickly what your decision produced. As an architect, you might wait years before you know if you went in the right direction. Someone who was excellent at making decisions as a developer can be completely lost when they move into a role with longer horizons and more uncertainty.

Andrea: It is a very different skill. With shorter feedback loops, experiments give strong signals — clearly right, clearly wrong. With longer-lasting decisions, the signals are harder to read. And organisations often overemphasise metrics that favour the preferred option. If everyone liked decision A over decision B, A's metrics look wonderful and nobody's asking what they might be missing.

The Decision KP Map

Gien: This is one of the reasons I like your Decision KP Map so much. It lets you visually show where the knowledge sits — or doesn't. If we're considering event-driven architecture and you put it on the map, and there's almost nobody with real experience, that's immediately visible. One person who worked on it once, five years ago, with senior people setting things up around them — that's not knowledge you can build on. And it becomes obvious that picking that option comes with a cost: you need to invest in education, time, and budget.

Andrea: Yes — and I want to clarify: the KP stands for two things. Knowledge-Power, but also Key People. The mapping practice is where the real return comes from. When you do the map for a specific decision — not a project, not a team, just this one decision — you start to see things clearly. The same person who seems very powerful generally might have very little power or knowledge in the context of this particular choice. And vice versa: someone with no formal authority can move into a position of real influence just by asking the right questions at the right time.

Gien: Have you noticed that in more loosely structured organisations, the people with more power also tend to have more knowledge?

Andrea: Not as a consistent pattern. I've seen teams where someone had no authority at all, but asked such insightful questions that they effectively moved into the "can make change happen" axis. And when you track the same decision over time — mapping it again as things develop — you see people shift. Someone joins the group, the whole map reshuffles. That's the value of it being decision-specific and iterative.

The rant: recipes vs. custom solutions

Gien: We're at the end of the podcast. What are you still frustrated about when it comes to decisions in companies?

Andrea: The generic version of my frustration is this: most people want a recipe to solve their problem, and at the same time, they want a completely custom solution. These two things are fundamentally at odds. A bespoke solution costs more — like a handmade shoe versus three pairs of flip-flops for ten euros. You can try to reframe the conversation around where a company's real differentiator lies and invest there, but the pull toward a silver bullet is very strong. And it's especially hard when you're trying to teach something — people keep asking why it can't be simpler. The tagline of the DDD book is literally about complexity. It shouldn't come as a surprise. You have to become comfortable with the discomfort. I feel like our industry has been circling this for years, and I'd love to see us actually move past it.

What does satisfying software mean to you?

Andrea: Satisfying software is being able to trust, and to work somewhere where trust is genuinely the default. I've worked in environments like that, and I think that's where you can build truly satisfying software — because people trust you, and you trust them. Trust that they know what they're doing. Trust that if you don't know, you can say so, and that's okay. Satisfying software means working with people you trust, and who trust you.