Why Your Event Modeling Workshop Didn't Stick (And What Actually Works)

Let me tell you about an agency I trained last year.

Smart team. Really smart. They picked up Event Modeling faster than almost any group I’d worked with. By the end of the two-day workshop, they were modeling complex workflows like they’d been doing it for years.

Three months later, I reached out. I always do.

The answer: “Martin, this isn’t working for us.”

I asked what happened. They told me they’d been using Event Modeling internally. It was brilliant for their team - helped them think through problems, align on solutions, see the full picture before they started building.

But then they had to deliver to their clients.

And their clients didn’t use Event Modeling. Their clients wanted requirements documents. Jira epics. User stories. Whatever format that specific client demanded.

So the agency would model everything beautifully with Event Modeling for internal clarity. Then they’d spend hours translating it all into traditional artifacts for the client.

They were doing double and triple the work. And they suddenly had multiple sources of truth. None of them truly trustable.. someone made changes in the Event Model, but forgot about Jira.. a requirements engineer added something to the Ticket, but nobody updated the Model.

Event Modeling wasn’t making them faster. It was making them slower. They couldn’t justify it anymore.

“We love Event Modeling,” they told me. “But we can’t afford to keep using it.”

That’s when I understood: Event Modeling doesn’t fail in isolation. It fails at the breaks in your value chain.

Where Most Methodologies Die

I very well remember my first event storming session. Back in 2016 or 2017, I think. We had this beautifully sketched out event storming result. All the sticky notes, beautifully aligned.

And you know what happened after?

Nothing.

At some point we made some photos, and cleared the wall because somebody needed it. End of story.

This is where most methodologies die. Not because they don’t work in the moment - but because nobody knows what to do with them after the session ends.

The model sits in a Miro board. Or in a photo on someone’s laptop. A Confluence Page.. And slowly, quietly, everyone goes back to doing things the old way.

The Point Enterprises Keep Missing

Here’s what I see happening in enterprise conversations: they fixate on tooling maturity.

“Is Event Modeling enterprise-ready? Does it integrate with our existing stack? What about vendor lock-in? What’s the roadmap?”

But they’re missing one of the major points of Event Modeling

It´s is a communication tool, not a tech stack decision.

Yes, you need some tooling eventually. But you can go pretty far without it - just using sticky notes or even stories you tell. Event Modeling allows you to get a bird’s eye view on the system, but also dive very deeply.

We often start on-site workshops with physical sticky notes to prove this exact point. It enforces even more collaboration. At some point we always switch to the digital board - it’s simply faster and more convenient.

But this proves the point: tooling is second nature.

The real value is in the communication. The alignment. The shared understanding.

Enterprises want to talk about tools. What they should be asking about is: Are we ready to change how we communicate and organize our work?

“What’s Not in Jira Doesn’t Get Done”

This is where good intentions meet reality.

I’ve watched this pattern play out over and over: A team wants to start using Event Modeling. They do a workshop. They’re excited. The model is beautiful. Everyone’s aligned.

Then it hits the organization’s processes.

“What is not in a Jira ticket doesn’t get done.”

So someone starts translating the event model into Jira tickets. And suddenly you have multiple sources of truth:

• The event model
• The Jira tickets
• The actual code

Which one is real? Who owns what? What happens when they diverge?

This is often the end of the event modeling experiment.

Because here’s the truth: Event Modeling won’t stick if you stick to your same old processes. If you need to do it in addition to what you are already doing.. then it just becomes more work.

You need organizational backing. You need to be willing to change how work flows through your company.

It’s Not About Modeling - It’s About Change

Ten years ago, organizations adopting Agile needed agile coaches. Not just Scrum training. Not just someone to teach them the ceremonies.

They needed someone to guide the organizational transformation. To help navigate the politics. To facilitate the difficult conversations. To help teams actually change how they worked.

Event Modeling is similar.

What’s needed isn’t just a “modeling expert.” It’s someone who can handle communication, facilitate change, and organize knowledge. Someone who can help you adapt your processes, not just teach you a new technique.

I’m often in this role with my clients. I provide guidance, I help navigate the integration challenges, I work with them to figure out how Event Modeling fits into their reality.

Because that’s where the real work happens.

What Actually Works: The 3-6 Month Reality

It starts with workshops. But that’s just the beginning.

Here’s what a successful Event Modeling adoption actually looks like:

We start with vision. What do we want to achieve? This works best when you’re starting a new project and you want to finally do something differently - to achieve better results. But it works equally well in Architecture Modernization - you need the same things - Vision, Understanding and a way forward.

We teach the methodology. How does Event Modeling actually work?

We do a proof of concept. Translate the model to code quickly, just to see if it’s possible.

Build Code Generators. Enable the Fastlane. Slow Lane is where we´ve been driving for the last decade.. time to switch lanes.

Then, if that works, we move into regular iterations. But we’re also looking at how to embed the whole process into the company:

• How do we integrate with Jira?
• How do we integrate with CI/CD?
• Can we translate slices directly to Jira tickets?
• Do we need additional descriptions or is everything in the model?
• Do we use additional diagrams like C4?
• How do we combine Event Modeling with enterprise architecture?
• Who needs to be involved when?

And we train an internal champion. Someone who has trust. Someone who can drive change and keep people engaged. Someone who can facilitate modeling sessions - very much like an agile coach.

The company picks this person. It can be anyone, but the best candidates are people with organizational trust and the ability to drive change.

The adoption takes takes 3-6 months. Not two days. But you get results from day one.

The Hard Truth About “Just Book the Workshop”

Often customers think: “Just book the 2-day workshop with Martin. It’s not that hard.”

They’re right - the workshop itself isn’t that hard. Explaining Event Modeling in 2 days is perfectly possible - at least the fundamental understanding of it. The methodology can be learned quickly. Some teams pick it up in two days and are modeling complex workflows by the end.

But there’s much more to it.

Without follow-up coaching. Without adapting your processes. Without organizational backing.

You’ll end up like that agency: loving the method internally, but unable to afford using it because it doesn’t fit your value chain.

Or like my first event storming session: beautiful in the moment, forgotten within weeks.

Event Modeling Adoption Is Possible

Let me be clear: Event Modeling adoption is absolutely possible. I’ve seen it work. I’ve helped teams successfully integrate it into their organizations.

It’s more powerful than most people realize. Not because of the tooling. Not because of the sticky notes.

Because it creates alignment. Because it makes implicit knowledge explicit. Because it helps teams see the full picture before they start building.

But it’s not just about sticky notes and workshops.

It’s about being willing to change how your organization works.

It’s about recognizing that if you model everything beautifully and then translate it all back into Jira tickets for your existing process, you’ve just added overhead - not value.

It’s about committing to making the event model your source of truth, and adapting your processes around it.

The question isn’t “Can we learn Event Modeling?”

The question is: “Are we ready to do things differently - can we actually move to the Fastlane?”

If the answer is yes - and you’re willing to do the work beyond the workshop - Event Modeling can transform how your teams plan, build, and deliver software. And in addition you get the powerful AI-Enabler you´ve been looking for.

If the answer is no, maybe it´s simply not the right time yet. The workshop alone won´t make a lasting change.

What could the Agency have done?

Remember that agency from the beginning? The one that had to abandon Event Modeling because it didn’t fit their value chain?

Here’s what they could have done differently: Instead of treating Event Modeling as an internal tool and their client deliverables as separate outputs, they could have made the event model itself the deliverable. Imagine handing a client a living, interactive event model instead of a static requirements document. A model they could explore, question, and evolve together. The Jira tickets could have been generated directly from slices in the model - one source of truth, not three competing ones.

But that requires a bigger shift. It means educating clients on why this approach helps. It means being willing to say, “This is how we work now, and here’s why it will get you better results. If you absolutely need, you can still get your Jira Tickets, but they are Read-Only more or less… No random editing”

We agree on Slices… And we change Slices.. And we deliver Slices..

That’s organizational backing. That’s commitment to the fastlane.

They loved Event Modeling. They saw the value. But they weren’t ready to change how they did business. We might try again in the future.

The question for your organization isn’t whether Event Modeling works. It’s whether you’re ready to actually change how you do the work - not just add another layer on top of what you’re already doing.

Are you?

Want to talk about what Event Modeling adoption would actually look like in your organization? Let’s have an honest conversation about how it could work for you.

Want to read more about Event Modeling in the context of Enterprise Organizations? Join the weekly Newsletter.

PS: we addressed this multiple times in our podcast - for example episode 14 and this episode 19