There's a certain frustration that comes from doing everything right — by the book, with experienced people, using proven methods — and still watching it fail. Not because the methods were wrong, but because the real problem was somewhere else entirely, and nobody had named it yet.
Marco Heimeshoff has been that person. In episode 20 of Stories on Facilitating Software Architecture and Design, he shares what he calls a "graveyard story" — a multi-year engagement where he introduced EventStorming, context mapping, domain storytelling, Wardley mapping, agile feedback loops, and still could not move the needle. What he eventually discovered wasn't a gap in technique. It was a fundamental mismatch in worldview, and almost no one in the room could see it, including him for quite a long time.
Everything Was Getting Better, Except the Thing That Mattered
Marco had been working with this company through a long transformation — moving from uncoordinated, imperative code toward cleaner architecture, introducing agile practices, building better feedback loops. By most measures, things were improving. But something kept failing underneath all of it.
"All these failings, even though they looked different in their signals, they all felt like the same thing," he says. "We never really delivered what they needed."
The next hypothesis was communication. If the teams weren't delivering the right thing, maybe they weren't talking to each other properly. So they introduced collaborative modeling — EventStorming sessions, context maps extracted from existing code, conversations about ubiquitous language. And that helped, for a while.
But something was still off.
The Room Felt Wrong and Nobody Could Say Why
The early EventStorming sessions were awkward in a way that Marco could feel but not immediately diagnose. The company had history. People had relationships — some warm, some not. Long-standing dynamics that didn't disappear just because there were now sticky notes on the wall.
"EventStorming made these things not safe to break," Marco says. "But it made things very transparent. You could feel where it's off, where people don't really go deep into details."
They used those signals. They ran feedback sessions after workshops. They asked people how they felt. They tried to build psychological safety. And that's where the real problem started to surface.
For Marco and the people already bought into collaborative improvement, asking "what can we do better next week?" felt positive and obvious. For others in the room, it felt like an attack.
"Feedback becomes violence," he says. Not loudly. Nobody stood up and said they felt threatened. Instead, there were jokes. Dismissiveness. People drifting off. And when pushed too directly, defensiveness and blame.
The Mismatch Nobody Named
A colleague introduced Marco to spiral dynamics — a framework for understanding how individuals and groups develop different value systems and worldviews based on the complexity of challenges they've faced. Without getting deep into the theory, the core insight was this: not everyone wants to improve the system. Some people want to keep the system alive, because it gives them belonging, stability, and a sense of identity.
For those people, a session designed to surface conflict and improve a shared model isn't a collaborative exercise. It's a destabilising one.
"You attack them, and you don't only attack their way of working," Marco says. "You go ahead and attack their identity without even knowing it."
He describes this realization with some discomfort. "Involuntarily, I was actually a person that just went through with an ax through a culture and really hurt those people."
The response wasn't protest. It was smirks. Jokes about tree-hugging developers and feelings. People saying "we just want to build software here." Signals that were easy to dismiss as resistance, but were actually something more personal.
A Boss Who Said Yes and Meant Something Else
The leadership dynamic made everything harder. The person at the top presented as a modern, progressive technology leader. They said yes to everything — yes to collaborative modeling, yes to EventStorming, yes to new methods. They showed up to every session.
And they sat at the back and watched.
"This is EventStorming and you are the person leading this company into the next millennium," Marco recalls thinking. "Here are sticky notes. Would you like to tell us what you think is the most important part?" The response: "No, no, you go ahead. I'll tell you if something is missing or wrong."
The signal was a smirk. Not a loud objection. Just a quiet, visible "this is cute" energy that everyone in the room could feel, even if nobody said it.
"You can feel where the boss isn't taking it seriously. And then I realized — all the methods in the world, all the expertise — you have no chance if your boss thinks this is cute."
Worse, that boss had quietly asked a separate developer to build the company's most revenue-critical new software outside of the whole process — fast, without the modeling cycle, without the language, without the second pair of eyes. And it worked. It made money. And it was janky in ways that would compound later.
Using Context Mapping for Culture, Not Just Code
At one point, Marco's team tried something unusual. They used bounded context mapping not just to describe software structure, but to describe the cultural structure of the organisation — trying to identify which groups had which kinds of mindsets, and where the boundaries between them needed to be respected rather than dissolved.
It helped, briefly. But it introduced a new problem: the moment people felt they were being grouped and managed based on some invisible classification, it felt like manipulation.
"The moment somebody catches on that you put us in a group because we are all alike," Marco says, "they're not reflecting on 'because we are the conservative part' — they think: 'you're putting us in a corner.'"
The loop deepened. Attempts to manage the cultural mismatch were read as more of the same imposition.
What He Would Do Differently
Looking back, Marco is clear about the two things he would change.
The first: leave earlier. Not as a defeat, but as a recognition that helping people against their will isn't help.
"I don't wanna hurt you with this," he says. "So if you don't want the help or the change, I don't wanna help you."
The second, and more interesting: stop trying to bring the company to his vision of what it should become, and instead ask what the next realistic step from where they actually are might look like.
"The result I produce doesn't have to be in a way that I like. My aesthetic realization of 'I like this shape, this is beautiful' — that's not what needs to be realized."
This is harder than it sounds. Marco came with experience from hundreds of companies. He had consulted with the authors of the books he was using. He had what felt like very well-grounded opinions about what good looked like. And those opinions were part of the problem.
What This Story Actually Demonstrates
- Getting a mandate from one sponsor is not the same as getting a mandate from the people you'll work with. A boss who pays for the engagement and says yes to everything can still be actively hostile to what you're trying to do — not loudly, but through signals that shape how everyone else behaves.
- Collaborative modeling methods make things visible that weren't visible before. That's valuable. But visibility isn't always welcome. Surfacing the conflict in a model is only productive if the people in the room have a shared interest in resolving it.
- Psychological safety is necessary but not sufficient. Marco's framing is sharp here: people also need to be intrinsically motivated to change. Safety removes a blocker. It doesn't create the desire.
- Local optimisation doesn't move a system if the bottleneck is somewhere else. They improved parts of the codebase, parts of the team dynamics, parts of the modeling practice. But the critical path ran through the cultural dynamics at the leadership level, and that never changed.
- Facilitation carries real power, and that power can harm. Walking into a system with methods, expertise, and the energy to improve things is not neutral. If the system doesn't want what you're offering, you can do genuine damage while believing you're helping.
One Question Worth Sitting With
Marco describes spending years trying to fix a company that, in some meaningful sense, didn't want to be fixed — at least not in the way he had in mind. The system was optimising to keep itself alive, and his efforts to change it were being absorbed, deflected, or worked around.
The honest version of this story is that the methods weren't wrong. EventStorming, context mapping, domain storytelling — none of these failed because they were bad tools. They failed because they were being applied to a problem they weren't designed to solve: convincing people who had no desire to change that change was good for them.
The question Marco leaves behind isn't really about which method to use next time. It's about what kind of mandate you actually need before you start, and how honest you're willing to be with yourself when the answer is: you don't have one.
Further Reading
Mentioned in this episode:
- Spiral Dynamics — Clare Graves (original research), developed further by Don Beck and Christopher Cowan. The psychosocial framework Marco used to make sense of why feedback loops worked for some people and felt threatening to others. He notes that searching for this online can take you into unreliable territory, so approach with care.
- DDD Heuristics — ddd-heuristics.com. A community-maintained collection of heuristics for domain-driven design that Marco mentions as a source of inspiration when looking for new things to try.
Worth exploring:
- Accelerate by Nicole Forsgren, Jez Humble, and Gene Kim. Research-backed work on what actually distinguishes high-performing software organisations — useful context for understanding why culture and feedback loops matter beyond methodology.
- Team Topologies by Matthew Skelton and Manuel Pais. Directly relevant to how organisational structure shapes software delivery, and how thinking about team boundaries connects to bounded context mapping.
- Thinking in Systems by Donella Meadows. One of the clearest introductions to why optimising local parts of a system often doesn't move the whole system — the underlying logic behind Marco's observation about the key value chain.
- Facilitator's Guide to Participatory Decision-Making by Sam Kaner. A practical resource on what it actually takes to create conditions where groups make decisions together — including the parts that don't work when people have fundamentally different needs from the process.
- An Introduction to the EventStorming Book by Alberto Brandolini. The foundational text on EventStorming, worth reading alongside stories like this one to understand both the method's strengths and the assumptions it rests on about participant motivation.
