About

As a teenager, I was a metalhead and wanted to be a guitarist. I studied software engineering because I was drawn to tech, mostly to tech companies and the impact they had, but it was the backup plan. Music was the goal.

At the age of 17, I moved abroad to study software engineering, still hoping that I would play guitar professionally. I still remember my first class, when the professor typed System.out.println("hello world") and said it would print hello world. I looked around the room for the printer (for real!).

That first year was a struggle, my classmates had all taken CS in high school, and I didn't, so I was learning from scratch while catching up. With enough perseverance, books, YouTube, and a wonderful tutor who made it all click (thank you, Dave!), I managed it.

Learning to program from scratch was an uphill battle, but the harder part was the identity crisis. I'd played guitar for seven years and tied my whole identity to music, so loving software felt like a betrayal. I had a mentor who helped me see that you can be more than one thing, that the skills carry over, and that becoming an engineer doesn't stop you from being a musician.

Software turned out to be creative in the same way. You're writing instructions for a machine, but you're also writing a narrative: someone else has to read your code, your systems, your architecture, and follow the story you left them. I read everything I could to get better at that (and I still do, even in the age of AI — crazy!).

The more I learned about patterns, architecture, organisation, and testability, the more it confirmed that the creative part mattered.

It wasn't only code, either. I fell for systems: operating systems, distributed systems, infrastructure, pipelines, all of it. I figured that out early, from talking to people during my internship, being curious about what they actually did, and, above all, from mentors who upskilled me and guided me through my career. They had given me what formal education couldn't: hands-on experience, direct guidance, and attention. It felt like an apprenticeship. They're some of the most talented people I've come across, and I am ever grateful for them and what they have taught me!

One question led to the next, and at some point I started teaching myself assembly outside of school. I was never going to write it professionally, it was simply to understand the layer beneath, which makes you better at the one above.

That love of learning became an obsession. I optimised for one thing and one thing only: learning as much as I could about software, and whenever the pace slowed, I looked for the next challenge. I know that's usually considered bad career advice, at least on paper. For that stage of my career, it was exactly the right call, because it put me in very different environments and each one shaped me differently.

I worked in large Fortune 500 organisations where software served millions of people and change was slow. Those years taught me reliability and why process exists: when the cost of failure is high, moving carefully is necessary. Breaking things isn't an option when people's health and money are on the line.

They also taught me to design carefully, because problems compound fast, and when change gets bogged down, you have to compound your improvements too, or the work buries you.

I also worked in startups and smaller companies, where the rules were the exact opposite. Small teams, fast decisions, everyone wearing several hats. Engineers weren't only writing software; they were shaping products, talking to customers, designing infrastructure and making business calls. Those places taught me ownership and gave me the room to experiment, fail, recover and become the engineer I am now.

I don't think either one is better than the other. I'm grateful I got both.

Eventually I got curious about the business side. How you build products people actually care about, what it takes to build a company, why technical excellence on its own is never enough. And how hard could it be?

Pretty hard, as it turns out.

One of my earliest attempts was a platform exploring whether exposing readers to a broader range of expert perspectives could reduce ideological polarisation. It was around the time Twitter was going through an identity crisis and online conversations increasingly felt like us versus them, and I genuinely believed technology could help people think more critically before forming an opinion.

The market had other ideas. People already had sources they trusted, and even the ones who liked the idea weren't interested enough to pay for it. It was the first time I realised that solving an important problem isn't the same as solving a painful one. That lesson has stayed with me ever since.

Later, some friends and I built Payvo. The idea was simple on paper: automatically pick the best credit card for every purchase, so you'd maximise rewards without thinking about it. It turned out to be anything but simple. The deeper we went, the more we found out how fascinating and how complicated payments really are. Digital wallets, payment rails, POS systems, authorisation flows. Every answer uncovered another layer.

The business never became what we hoped it would. Oddly enough, that's not what I remember. What I remember is the excitement: evenings spent experimenting with Android devices trying to intercept payment requests, reading documentation we'd never had a reason to open, celebrating every small breakthrough like we'd dug up buried treasure.

Talking about it still makes me smile. There's something deeply satisfying about exploring a domain you've never seen before with people who are just as curious as you are.

Another project, AssetWarden, taught me a completely different lesson. Customer interviews made it clear very quickly: the problem existed; it just wasn't painful enough. We could have built it anyway. We decided not to. Walking away from an idea is often harder than starting one.

None of those companies became the business I hoped they would. I don't see them as failures; I see them as my business education. Engineering taught me how to build systems. Entrepreneurship taught me how to understand customers, incentives and markets, and why assumptions deserve to be challenged. Those lessons permanently changed the way I approach software.

Something else changed over the years too. For a long time I believed that maximising learning meant constantly chasing the next challenge. I still believe in seeking challenge, but I've learned that some lessons refuse to be rushed.

You only understand the consequences of an architectural decision after you've maintained it for years. You only appreciate trade-offs after you've lived with them. You only understand organisations after you've watched them grow, change, succeed and struggle.

I still optimise for learning. I just no longer measure it in months.

Two lessons matter more than the rest.

The first is that many things in life are systems, or subsystems of one. Understanding how those systems interact has become one of my favourite ways to approach a difficult problem: clear boundaries, clear ownership, aligned incentives, and simple interactions almost always outperform unnecessary complexity.

The second is that people are not one of those systems. People are wonderfully complicated. They have ambitions, insecurities, motivations, fears, strengths, blind spots, and lives that extend far beyond work. Two people can go through the same situation and walk away with completely different perspectives.

That sounds obvious, and you'd still be surprised how many leaders try to systematise their staff anyway: weekly one-on-ones that lead nowhere, and no real effort to understand the team as people.

I care about helping people grow, and what that takes is different every time. Sometimes it's giving someone room to work it out for themselves; sometimes it's pushing them because you can see they're capable of more than they think; and sometimes it's just listening.

Let's not forget the humanity in our interactions.

I'm moving into leadership now, and that's where it all links up: systems, people, and business.