My journey

The first thing I can remember wanting to understand was how the video games on my Commodore 64 actually worked. I figured this out by accident. The games loaded from cassette tapes, and one day, fiddling with the deck while a game was loading, I discovered that if I stopped the tape at the right moment I could see the code on the screen — raw, mid-load, half-decipherable but real. I started stopping the tape on purpose. Then I started changing things. Then I discovered, confused, that every time I rewound the cassette to play the game again, all my changes were gone, and I had to do the whole routine a second time, and a third, and a fourth. It was addictive. A hundred games, a notepad and pencil, and the keyboard. At some point I stopped playing the games entirely and just played with the code.

The second discovery happened at my grandmother's house. She spent her afternoons browsing TeleVideo — the Italian teletext service, pages of news and weather rendered in blocky coloured text on the TV screen. One afternoon I started punching in page numbers that were not in the index, and I found hidden pages filled with symbols that meant nothing to anyone watching television. I started copying them into my notepad, page after page, and carrying the notepad home to type them into my Commodore. This took months. Most of what I typed produced nothing, or errors, or things I did not expect. Slowly, through a lot of trial and error, I started to recognise patterns — they were hex codes, compiled instructions from the ASCII table, the same language the machine already spoke. The symbols on my grandmother's television and the code inside my games were made of the same thing.

That was the moment it clicked. Behind the games, behind the teletext, behind everything on every screen — there was code, and the code was what made all of it happen. Everything I could see was something someone had written. Coding never left me after that. I have studied and programmed in twenty-three languages and hundreds of frameworks since. I never cared much about the programming language itself, even though some of them completely changed the way I thought. What I cared about was how to express my creativity — and code turned out to be the best way I have found to do that.

The instinct from the Commodore years had a name, it turned out. Reverse engineering. I spent a good part of my career doing it professionally — pulling apart communication protocols to understand how systems talk to each other, tracing the paths that data takes between machines that were never designed to explain themselves. One of those projects involved reverse engineering the streaming protocol behind a well-known multimedia platform. The work eventually contributed to an open-source media server that other people built on for years. I did not set out to create something public. I set out to understand how the thing worked. The rest followed.

The subjects kept changing. I started by building applications for HR, which taught me more about how organisations actually function than I expected from a software project. Then particle systems for CGI and simulations, where I learned to think about emergence — thousands of simple rules producing complex behaviour. Then IoT, haptics, multi-touch technology, and the early AR and VR work in the years before either of those acronyms meant anything to most people. Somewhere along the way the teams I worked with won several industry awards — the first with Microsoft and Aston Martin for Silverlight and XNA, then others across design, innovation, interactivity, and things that at the time did not have a proper category yet. Mostly I remember the first one because of how strange it felt at a conference in Las Vegas with thousands of people applauding a technology that almost nobody in the audience had seen before. The awards were nice. The work that produced them was the part I actually cared about.

The languages changed with the subjects. Basic, Pascal, Assembler when I needed to talk to hardware directly, C and C++ when I needed low level programming, a long stretch in C# and the .NET universe, where every layer you pulled back revealed another layer underneath, and the whole thing taught me to think about software as architecture. More recently AI and the mathematics behind selective disclosure, cryptography and cross-boundary trust. My current favourites are Rust and Go, in that order, and I will defend that order at length if you give me coffee. I have never liked loosely structured languages — Python and scripting sit at the bottom of my list, and I suspect that says more about how my brain works than about the languages themselves.

I never stopped writing code. I just started doing other things on top of it — leading teams, making decisions, taking on the kind of responsibility that arrives whether you ask for it or not. I have been a CTO since 2012, and across twenty-five years I have built engineering teams in several countries, scaling one from three people in a single office to over seventy across four. I learned more from doing that than from any of the books I read along the way, most of which I now think are wrong about what they claim.

What scaling teaches you, if you do it for long enough, is that the parts of the work that look most important from the outside — strategy, architecture, hiring decisions, the sweeping calls — are not the parts that determine whether a company actually works. The parts that determine it are smaller, quieter, and almost impossible to point at. How people disagree. How information moves. Whether institutional memory survives the people who carry it. Whether the half-second of intuition that an experienced engineer has at three in the morning gets listened to by anyone in a position to act on it. There are academic fields that study each of these — knowledge management, organisational behaviour, information science — but I have never found a single one that looks at all of them together as parts of the same system.

The operational years are when I stopped believing that organisations succeed because of what is in them and started believing they succeed because of what happens between the things in them. I saw it happen in one place more clearly than anywhere else. A post-production company that grew from three people to over seventy full-time. The growth was constant and fast — every agency was calling, we were delivering quality work, and at peak we were running twenty projects a month, small and medium overlapping with large ones. I owned the R&D department under the CTO, and we were experimenting with everything — multi-touch environments, AR, simulation engines — technologies that required deep coordination between engineering and content creation, between the people who wrote the code and the people who made the audio, the video, the CGI.

Not everyone in the company was an expert. That turned out not to matter. What I witnessed was something I have spent years trying to understand since. The whole company aligned itself to a goal that nobody had written on a wall or announced in a meeting. It was personal. People decided on their own to come in at four in the morning to prepare the ground for colleagues arriving at nine. Others stayed through the night. We did not manage timesheets. We trusted people, and we gave them the kind of flexibility that only works when everyone genuinely cares about what they are making. I made sure, in ways that were not always visible, that individual wellbeing was being looked after even when the pace was brutal. The company became the largest post-production house in the country and expanded into four other countries.

I am driven by curiosity in a way I have never fully been able to control. It is the trait that has decided most of my direction in life — not ambition, not strategy, just the inability to leave a gap alone once I have noticed it. Learning and discovering are not things I do. They are who I am.

During the post-production years I collected certifications in project management, corporate finance, requirements engineering, business analysis — anything that touched the edges of what I did not yet understand about how organisations work. I had studied business administration years earlier and had consulted on the shift from paper-based HR to the first digital systems, but none of that prepared me for what I was watching happen between people at scale. The gap between what I knew and what I could see was too wide, and it kept bothering me. So I went back to university — evenings and nights, while running the technology department during the day — and took a bachelor's degree in business administration, then an executive MBA. It was a long streak.

Those degrees led me into organisational behaviour and knowledge management, and from there into a question I had been circling for years without knowing it. I dedicated my entire dissertation to social capital in the knowledge-based economy — how organisations create value through the relationships between people. It was an epiphany. For the first time I could connect the dots between everything I had experienced in the field and the dynamics I had been watching between people for twenty years.

By the time I finished I had proposed a couple of ideas that I now think matter more than I realised when I wrote them down. The first was that Social Capital — the term everyone uses — is the wrong name. What organisations actually generate through their relationships is a value that belongs to the interaction itself, not to either person in it, and that cannot exist without both. I started calling it Collective Capital. The second was a way to measure it — how the collective effort produces knowledge that no individual in the network could have created alone. A multiplier, not a sum. I called it the Social Factor.

The world has changed in a particular way since I finished that work. The things I was writing about — trust, judgement, the relational work that makes collective value possible — are now being handled, at least partly, by software agents, cryptographic systems, and autonomous workflows that did not exist when I was studying them. The humans are still there. They are no longer the only actors in the network.

That creates friction in places most people have not thought about yet. AI systems are probabilistic, but the world they are being dropped into — contracts, compliance, accountability — was built on the assumption that decisions can be traced and explained. Automation is replacing tasks, but not the traits that make certain tasks worth doing in the first place: the judgement that comes from experience, the trust that comes from years of working together, the instinct that something is off before any dashboard says so. The chain from knowledge to execution to value creation used to run through people. It is being rerouted, and the machines carrying it have no idea that they are.

There is also a tension underneath all of this that I think business has not been honest about. Technology is supposed to drive both exploration and competitiveness, but in practice most organisations optimise for productivity — what is fast, what scales, what fits into the next quarter. The things that are new, uncertain, or that create value for the larger society rather than the immediate bottom line tend to get squeezed out. Not deliberately. Just by the way we measure.

I have spent thirty years moving between these domains without realising they were the same domain. Writing code, then managing the people who write it. Building automated systems, then trying to figure out what has to stay human. Reverse engineering how machines talk to each other, then studying how people do. I did not set out to work at this particular intersection, but it is where everything I have done seems to converge.

Humans are still at the centre of all of it, and I think they have to be — not as a principle but as a practical matter, because without them the system does not hold together. What it takes to keep them there, and what changes when you add non-human actors to a framework that was built for human collaboration, is what I am working on now.