How I Got Here

I didn't set out to become a Technical Director. I set out to build things - and then spent twenty-five years following that instinct through a series of roles, environments, and technologies that eventually led me to where I am now: leading the technical team at Elysium, a bespoke software company that's been delivering for over thirty-one years.

Here's the path that got me here, and why it matters to the work I do today.

The Early Years: Learning What "High Stakes" Means

My career started at BAA - British Airports Authority - at Gatwick, where I spent a year as part of the enterprise solutions team during my university placement. I was building internal business systems, helping migrate legacy databases to Oracle, and presenting solutions to management. I was also twenty years old and being trusted with infrastructure that airports depended on. BAA invited me to stay after my placement, but I went back to finish my degree at the University of Brighton.

After graduating, I joined Code 27, a development shop in East Grinstead, where I progressed quickly from developer to senior developer and team lead. It was there that I got my first real taste of leading projects through their full lifecycle - design, development, testing, delivery, and the long tail of maintenance that nobody warns you about.

Through Code 27 I was contracted to Lloyds Register of Shipping, where I worked as a Business Analyst on rules-based engineering software for the shipping industry. That role taught me something I still carry: how to sit with business stakeholders, extract what they actually need (as opposed to what they think they want), and turn that into a technical specification that holds up under scrutiny. The safety-critical mindset I developed in those environments - where technical debt isn't just an inconvenience but a genuine business risk - still defines how I approach software today.

Elysium: The Perfect Fit

I joined Elysium in 2010 as a Senior Developer, and I haven't looked back.

In the early days, my work was deeply hands-on. One of my first major projects was implementing PDF rendering and label-printer integration for a courier management system that had been running since 2005 - a Rails application that is still in production today, having been through every major framework version from Rails 1 to Rails 8. Working on a codebase with that kind of history teaches you things that greenfield projects never do: how software ages, where the real fracture points are, and why decisions made a decade ago still matter.

Over time, the main focus of my work moved from building core features to leading the development team. I took on this role gradually, managing projects and developers as well as balancing the competing demands of client expectations, technical quality, and delivery deadlines. When Elysium restructured in 2014, I accepted the Technical Director position - a role that shifted my focus from writing code every day to overseeing the architecture and technical direction of everything we deliver.

But I never stopped being a practitioner. On any given week, I might be planning a major Rails upgrade for a long-standing client, reviewing the architecture of a new AI integration, or helping a customer work out whether they need a bespoke build at all. I stay hands-on because it's the only way to make good architectural decisions - you can't lead a technical team if you've lost touch with the reality of the code.

What We Build

Elysium's work spans a wide range of industries and challenges, but a few projects illustrate what we do best.

Our longest-running Rails project - that courier system I mentioned - has been in continuous operation for over twenty years. It manages bookings, shipping updates, invoicing, and partner integrations. It moved to Haml templating in 2006, gained a Gemfile in 2010, an ActiveJob background processor in 2014, and has been through more upgrades than I can count. It now needs only a light touch each year to stay secure and current. That application didn't survive by accident. It survived because its owners understood that bespoke software is a long game, not a project.

Our largest current engagement is a suite of AI-backed recruiting tools - an API backbone with microservices targeted at recruiters, hiring managers, admins, and applicants. The client started as a specialist team and grew through a series of acquisitions over the past seven years, each one bringing a new software challenge. Their platform today is the product of years of disciplined prototyping: build it, test it with a small audience, make a fast decision on whether to grow it or let it go.

One of our most meaningful partnerships is a suite of healthcare applications - including a mental health management platform that was used by the NHS during Covid and is currently being used by Ukrainian health providers to treat intrusive memories. That engagement started with a small, focused data analysis tool and grew into a ten-year operational partnership spanning multiple products. It's a relationship that exemplifies what I believe about this work: the initial build is the start of the investment, not the whole of it.

What I've Learned

Sixteen years at one company may not be the norm in this industry, but it certainly is at Elysium. The variety of the work has never let me get bored, and the longevity of our client relationships means I get to see the full arc of a product's life - not just the exciting launch, but the hard decisions about what to sunset, when to rebuild, and how to keep a codebase healthy over years and decades.

That long view has shaped how I think about software. I've learned that the hardest part of the job isn't technical - it's having the courage to tell a client that their idea needs redirecting, or that the feature they love is the one holding them back, or that an off-the-shelf solution might serve them better than a bespoke build. The trust to have those conversations is earned over years. It's also, I've come to believe, the most valuable thing a technical partner can offer.

Writing

I've recently started writing about the things I've spent two decades learning - the intersection of software architecture, engineering leadership, and the practical realities of building software that lasts. You can read my articles on the blog, where I cover topics from making codebases ready for AI agents to the operational realities of maintaining bespoke software over decades.

If you're interested in my writing for a publication or collaboration, I'd be glad to hear from you.

The best way to reach me is via the contact page.

You can also find me on LinkedIn.