I was looking for resources on change management and adoption. I found Seth Godin's TED talk "How to get your ideas to spread" - actually, I'd watched it years ago, but I rewatched it recently when I was thinking about a major frontend replacement project.
It clicked differently this time.
Not because it's about marketing products to customers - though it is. But because the same principles apply when you're trying to get an entire organisation to adopt completely new systems.
Seth Godin's central idea is simple: in a world where people has more choices than ever and less time to make them, being safe and average means being invisible.
His example is the purple cow. If you're driving past a field of brown cows, you don't notice them. But if there's a purple cow in that field, you absolutely notice. You might even stop the car and take a photo.
That's what "remarkable" means - worth making a remark about.
The traditional approach to spreading ideas - mass marketing to the average person - doesn't work anymore. TV advertising to the middle doesn't work. Safe products designed not to offend anyone don't work.
What works is finding the people who care deeply about your thing - the innovators and early adopters - and making something remarkable enough that they'll tell other people about it.
Around 2017, I was working on replacing an old Access-based ERP and MES system with a new web-based frontend. The scale was substantial - this system touched everything from manufacturing to quality control to dispatch.
My biggest worry wasn't the technology. It was that people wouldn't adopt the new system properly, so they'd resort to workarounds. And once people lose confidence in new systems, those systems become the platforms you can't build on in the future.
We couldn't just flip a switch and change everything at once. We chunked it up by area and worked through it systematically. But we couldn't just cherry-pick the easy wins - we had to go by business value.
Here's where Seth Godin's thinking became useful: we deliberately selected areas where we had early adopters of our systems. People who were naturally curious about technology and willing to give feedback.
We made sure these early adopters had access to both the legacy system and the new frontend. We worked with them to build as feature-rich an implementation as was practical.
The features themselves weren't revolutionary - slicker UIs, better filtering options, some IoT integrations to make their lives easier. But they solved real problems. And because we'd worked with these people closely, they understood the benefits.
They became our salespeople to the other operational teams.
This is exactly what Seth Godin talks about. You find the people who care, you give them something remarkable (or at least noticeably better), and they tell other people. The idea spreads.
I've seen this pattern work in different contexts. We worked closely with a major B2B trading partner - a retailer selling to consumers - on an integration API. They were willing to take an MVP, test it, and give us feedback to help us develop the product.
Initially it was very limited order entry. But we built out features for more complex orders and order tracking based on their needs. They got capabilities they wanted, and they agreed to speak to our other customers about this at events.
They actually did. At least once that I know of.
That's remarkable in the literal sense - they remarked about it to other potential customers. We didn't have to convince anyone. The idea spread because someone who cared told others it was worth caring about.
Here's the challenge: a lot of what gets deployed in business isn't optional. Like-for-like replacements. You can't make a new service desk system inherently remarkable.
But you can make the experience remarkable.
We implemented Jira Service Desk across most departments starting around 2018 or 2019. Tech teams first, then maintenance, HR, payroll, facilities, manufacturing - any team providing a service to internal customers.
It wasn't necessarily popular with service desk customers at first. People were used to just emailing someone or walking over to their desk.
But it made the service desk agents much happier. They could collect all relevant information in a ticket with mandatory fields. No more back-and-forth across multiple channels with emails updating tickets.
Once we got to critical mass - enough departments using it, plus the company growing - it became really popular with service desk customers too.
They were getting faster service. If they logged something to the wrong place, a service desk agent moved it to the correct place and the issue got resolved anyway. For new team members, particularly across multiple sites, it was easier to use the portal than find the right person to email.
If the feature solves a real pain point, and it does it better than anything that came before, people will talk about it. The idea spreads.
Seth Godin's talk is about marketing, but the lesson applies to any situation where you need people to change behaviour.
I've worked on big changes - new ERPs, factory moves. Everyone comes into these with a change mindset, which is great. But then workarounds and bodges creep in, and you have to catch them quickly before people go back into an execution mindset rather than a change mindset.
During a factory move, our MD found what we called "our first bodge" - brown parcel tape holding a bolt into a conveyor. I was a project manager then. That one became memorable because we caught it early and it became a running joke about vigilance.
Another time, as a systems manager, I made a software change to group jobs on barrows to make downstream processes easier. But there wasn't any benefit to the users doing the grouping, so they set the barrow limit really high and continued loading them however they wanted.
We didn't catch that one early. The behaviour had set. By the time we noticed, the workaround was normal practice.
That's the real risk. Not the technology. Not the training. It's that people will find ways around systems they don't trust or that don't make their lives easier. And once those workarounds become normal, they're incredibly hard to undo.
There's another principle I've learned: if you can't be remarkable, be the easiest thing to use.
The service desk portal spread because once it hit critical mass, it was just easier. The frontend replacement spread because the early adopters found it noticeably better. The customer API spread because it solved real problems for a partner who cared enough to tell others.
You can't just tell people to use new systems and expect it to work. You can't force adoption through mandates and training sessions alone.
You have to find the people who care - the early adopters, the innovators, the partners willing to test MVPs - and give them something worth talking about. Then you have to make sure what you're deploying is either the easiest thing to use or truly remarkable.
Because if it's neither, people will find workarounds. They'll lose confidence. And you'll have spent time and money on platforms that no one trusts enough to build on.
The technology isn't the hard part. Getting ideas to spread is.
I still don't catch workarounds as early as I should. I'm getting better at finding the early adopters and working with them first. But the gap between "people say they're using the system" and "people are actually using the system properly" is something I'm still learning to spot faster.
Not there yet.
Watch the TED Talk: How to get your ideas to spread | Seth Godin
Read the book: Purple Cow: Transform Your Business by Being Remarkable by Seth Godin