My first computing days go back to the early eighties.

I grew up in a home where curiosity was basically part of the furniture. If we did not know something, we did not “wing it”, we looked it up. Back then that meant pulling out the encyclopaedia together at the kitchen table, flipping pages as a family until we found what we needed. Today, the same reflex is “let’s Google it together”, or, increasingly, “let’s ask Perplexity”.

Curiosity was not a hobby in our house. It was a family habit.

Living in a border town with an international harbour also shaped that mindset. A harbour brings movement, languages, sailors, and a certain normality around the world being bigger than your street. Even international shopping trips were not exotic. Taking the ferry to Dover because the currency exchange made things cheaper was just… a thing you did.

A harbour teaches you early: the world is bigger than your street.

Then my father switched domains, from mechanical engineering to electronics and computers. And one weekend he brought home something that felt like science fiction: a TRS-80. No sleek design, no “plug and play”, more like electronics with cables and rituals. Even the operating system came from floppy disks.

I was instantly hooked.

Not long after, a second machine appeared: the Commodore PET, an all in one device with a built in screen, green letters, and an integrated keyboard. I still remember that it opened like a car trunk and you could literally see the chips inside.

The first computers were not devices. They were little rituals with cables and floppy disks.

Fun fact: the PET came with an early text processor in German, and that is how I learned that “speichern” means “save”.

The day I tried to “improve” Monopoly

Because the PET felt more powerful, I started writing longer BASIC programs.

At some point, I gave myself a challenge: build a version of Monopoly on the computer.

My idea sounded brilliant, at least to a young tech enthusiast:

• No more fiddling with paper money
• No more handling cards
• A digital bank that handles all transactions
• A random dice generator
• A command line interface where players enter their names and choices

I spent hours designing memory structures, typing lists of street names and chance cards, and learning that random generators need proper seeding, otherwise the dice became suspiciously predictable.

After a few days, it worked.

My friends came over. We were around the table, joking, negotiating, watching each other like hawks, and enjoying the whole little theatre of it. I was proud of my elegant digital banking system. My friends were proud of… not having to count paper money anymore.

And that’s when I discovered something terrible.

The program worked like a charm… and the game became boring.

The room got quieter. The laughs disappeared. That was my real bug.

I built Monopoly to remove the mess. I accidentally removed the magic.

Efficiency killed the fun

By removing the “inefficiency”, I had removed the actual experience.

The fun of Monopoly is not only in the buy or sell decisions. It’s also in the human stuff:

• the anticipation while rolling physical dice
• the slow movement of the token
• the side glances when you land on someone’s street
• the small hope that your friend will not notice
• the drama of handing over a stack of money you do not want to give

My software did the transactions flawlessly, but it killed the tension, the theatre, the social friction. It turned a messy human game into a clean financial spreadsheet.

That day I learned something that still shows up in innovation projects today:

Technology can optimise the process and still ruin the value.

I later realised the “inefficiency” was not a defect. It was part of the meaning. Friction is sometimes where attention, emotion, and commitment live.

If you only remember one thing from this story, let it be this: removing friction can remove meaning.

The real game was never the transactions. It was the human theatre around them.

The modern version of this trap

Fast forward to today, and you see the same pattern everywhere:

• an AI assistant that summarises meetings perfectly, but kills the team’s shared sensemaking
• a workflow tool that removes “wasted time”, but also removes ownership and informal alignment
• a dashboard that creates clarity for management, while making operators feel controlled instead of supported

In all these cases, the tech works. The adoption fails. Or it “adopts” but people quietly route around it.

Not because people hate technology, but because the real value was never only functional.

People do not resist tools. They resist what tools take away.

A practical lens: what are you really optimising for?

Here’s a simple question that can save you a lot of wasted build time:

Are you optimising the task, or the experience around the task?

In innovation, value is not only about speed, accuracy, and automation. Value is also:

• confidence
• trust
• motivation
• social signalling
• control and agency
• the feeling of progress

If you optimise the measurable part and damage the human part, you might end up with something that is “better” and still unwanted.

Get this wrong and you burn budget on tools that people avoid. Get it right and you speed up decisions, alignment, and delivery, which is where innovation results start compounding into growth.

This is the reason I keep coming back to one core idea in innovation work: start from the value you want to create before you jump to the solution. If you want a deeper dive into that thinking, this section on defining value before defining solutions captures the essence nicely.

This is also why I am cautious with innovation management done as pure theory. Frameworks like ISO 56000 are useful because they give language and structure. And for many organisations, that kind of structure is not optional. It helps align decision making, roles, and accountability. The tricky part is that structure on paper does not automatically survive real behaviour.

In the Foundation workshop we do something different: participants build a virtual innovation management system and then simulate a full year of innovation decisions, trade offs, and partner dynamics. And the real value is not only that people understand the elements of a system. It is that they start to experience what those elements do to each other once reality enters the room.

A simulation does something theory cannot: it brings hidden assumptions to the surface.

ISO gives you a map. Experiencing the simulation in the Foundation workshop shows you the traffic.

Everyone walks into innovation management with a mental model of what matters most:

• some prioritise governance and predictability
• others protect autonomy and speed
• some focus on portfolio choices and strategic fit
• others instinctively optimise for culture, engagement, and energy
• some see innovation as a process problem
• others see it as a people problem

None of these are wrong. But if you do not uncover them, you end up designing a system that only works for one viewpoint, while others quietly disengage or route around it.

None of our priorities are wrong. The danger is assuming everyone shares them.

In the workshop, those differences do not stay abstract. They show up in decisions, trade offs, and friction points. You see where a rule helps adoption, where it creates resistance, where a KPI drives better outcomes, and where it starts gaming behaviour. Participants usually walk out with clearer choices, fewer hidden disagreements, and a system they actually want to use, not just one they can describe. That is where results become more likely, and where you create the conditions for sustained growth.

If you want a simple mental shortcut: ISO 56000 can be a good map, and experiencing the simulation in the Foundation workshop teaches you what it feels like when the road is busy, when priorities clash, and when humans do what humans do.

Three quick takeaways you can apply in your next project

1) Map the human moments, not just the steps
Before you redesign a process, list the moments where people feel tension, pride, fun, or relief. Those moments are often where the perceived value lives.

2) Prototype the feeling
When you test a new tool or workflow, do not only ask “does it work?”. Also ask: does this feel better, safer, more empowering? If you do not test that, you are guessing.

3) Involve real people early, even if it hurts your ego
Tech people (and I say this with love) tend to fall in love with elegant solutions. People fall in love with what fits their reality.

Before you automate a step, ask what human moment you might be deleting.

A tiny Monday morning checklist to make this practical:

• What are we trying to make easier, and for whom?
• What part of the experience do people currently enjoy or rely on?
• What could disappear if we automate this?
• How will we know adoption is real, not polite?

If you recognise these patterns in your own projects and want to work on them, you can reach out via the contact page. I am glad to share ideas and examples.