My path into technology didn’t begin with a mission.
It began with surfing.
Growing up in the depths of Devon, the first person in our friendship group to get a driving licence (sadly, not me) became a sort of minor deity. Whoever could drive controlled access to the beach, and therefore access to happiness.
Surfing required petrol money though. And petrol money required work.
I quickly discovered I could earn more building websites than lugging pots around a garden centre, so that became my chosen path to petrol. What surprised me was how quickly I noticed a pattern:
Building stuff is easy.
Getting people to actually use it is… not.
Someone might ask you for a website, but what they really wanted was reassurance, simplicity, and a sense that the system was theirs. If anything felt confusing, the whole thing fell apart. Confusion meant questions. Questions meant delays.
Delays meant you didn’t get paid.
A powerful early lesson.
The gap between something being technically available and something being usable (or even remotely desirable) was vast. And although I didn’t truly appreciate it then, ignoring that human side of technology was a mistake I went on to make repeatedly. Just because you think the software or data works for you, doesn’t mean it works for anyone else.
I learned that lesson the hard way. Several times.
The Forecasting Model That No One Wanted
Early in my career, I spent months — literally months — building an elaborate forecasting model for a huge project. This thing had everything: Monte Carlo simulations, thousands of variables, sliders, toggles, colour-coded outputs. It was a data nerd’s Disneyland. We sourced data globally (which took ages). And we built a model that estimated hundreds of millions of pounds in projected contract value.
Just before the final pitch, after staying up almost all night to finish and test the model, we presented it proudly.
A senior partner walked in, looked at it for approximately four seconds, and said:
“Great work. But the price needs to be X.”
Why?
“Oh, I did something similar last year. It cost X. Ours should cost X too. Otherwise, the competitor will get the work.”
Wow. Months of work gone. Just… gone.
That was the day I realised something important: You can build the most sophisticated tool in the world, but if you don’t understand who it’s for, it’s basically an expensive screensaver. Did I learn from this immediately?
Of course not.
If We Build It, They Will… Not Come
And then we repeated the mistake.
When we first started building MetadataWorks, I collaborated with a brilliant team at Oxford University — very clever people. Together we built an all-singing, all-dancing metadata platform that was going to do everything.
And I mean everything.
The professor in charge would regularly stand on a table (literally) and shout about all the features it needed: X, Y, Z… and probably the whole alphabet.
We built it. The only issue?
No one — and I mean no one — apart from our little group could use the damn thing.
It was spectacularly powerful.
It was also spectacularly unusable.
To all intents and purposes, it was completely unintelligible to 99% of our users… and these weren’t amateurs. These were PhDs with strong data backgrounds. When a room full of doctoral software engineers would rather have a spreadsheet than your shiny new platform, you have a usability issue.
This was the point at which we discovered the terrifying truth of tech:
If you build it, they will come…
unless you’ve built something terrifying, in which case they will run away and ask for an Excel file.
Activity ≠ Impact
Looking back at my early data career, I was incredibly busy doing an incredible amount of absolutely pointless things.
I confused activity with output. Motion with progress. Complexity with value.
It’s a bit like surfing:
Yes, you can paddle for every single wave, but if you do, you will:
The goal isn’t to paddle more. The goal is to paddle well.
Data systems are the same. You can try to build everything for everyone… or you can sit back, wait for the right use case, and ride it all the way to the beach.
Stripping Back to What Matters
Over the past decade at MDW, we’ve spent far more time removing features than adding them. We learned (slowly, painfully) that the most valuable part of a metadata platform isn’t the feature list, it’s the parts people actually use. The parts that save time. The parts that make sense.
Everything else is noise.
It took years to understand that:
And in hindsight, that was the beginning of understanding data discovery, human-centred metadata, and why information systems must be designed with actual humans in mind.
Surfing taught me something that took years to appreciate:
Don’t chase every wave.
Wait for the right one.
Then commit.
It applies to data. It applies to products. It applies to life.
And it applies especially to young engineers who think more features always equal more value.
(They don’t.)
So how can I avoid making the same mistake?
If there’s one thing I wish I’d understood earlier, it’s that the biggest risk in any technology project isn’t that you can’t build it.
It’s that you build it brilliantly… and nobody uses it.
The easiest way to fall into that trap is to start with solutions. Features. Tools. Platforms. Dashboards. A shiny thing that feels productive. Because building is satisfying — it creates motion. And motion looks like progress.
But impact doesn’t come from motion.
Impact comes from delivering the right thing, for the right people at the right time.
That’s where a project charter becomes genuinely useful.
Not as bureaucracy. Not as a document you write once and forget. And definitely not as a tick-box exercise.
But as a tool to slow down your thinking before you speed up your delivery.
A good charter forces you to answer the uncomfortable questions early:
Most importantly, it helps you do something that’s deceptively hard:
Get everyone aligned before you start building.
Because even the best engineers can’t out-deliver misalignment.
If the sponsor thinks it’s about speed, the security team thinks it’s about control, the users think it’s about convenience, and the delivery team thinks it’s about technical elegance — you don’t have a project. You have a slow-motion argument with a backlog.
A charter doesn’t solve all of that. But it gives you a shared starting point: a way to agree what matters, what doesn’t, what “done” means, and how you’ll make decisions when priorities collide.
But it’s not a magic wand.
A project charter won’t guarantee success. It won’t replace user research. Or product thinking. Or good delivery. And it won’t rescue a project that’s built on the wrong assumptions.
What it will do is reduce the chances that you spend months paddling for the wrong wave.
It’s a simple tool — but if you use it properly, it stops you confusing activity with progress. It helps you strip things back, focus on outcomes, and build something that people actually want to use.
And if there’s anything surfing taught me…It’s better to commit to one good wave than exhaust yourself chasing every wave in the sea.
Find our project charter template here