From the help desk to the architecture

In 2014 I was a desktop support engineer. The job was to keep other people working — to get to a broken machine fast, understand what had actually failed rather than what was reported, and put it back before it cost anyone a day. Within four years I was running a team of six, handling desktop and server support for clients across a dozen different industries.

That period taught me something I have never seen taught in a strategy deck: systems fail at the seams, and the seams are usually where two teams disagree about who owns something. The technical fault is generally the symptom. The cause is organisational.

Everything since has been the same work at increasing altitude. As a CRM consultant and solutions architect, the seams were between sales processes and the systems meant to support them. As IT Manager for a national franchise network, they were between head office and three hundred independently owned stores. At a B2B travel platform, they were between infrastructure that had grown organically and a business that could not tolerate downtime. Today, setting enterprise application strategy across a house of hospitality brands, they are between brand autonomy and group governance.

What I actually do

Most of my work has been some version of the same task: an organisation has systems that grew separately, and it can no longer answer basic questions about itself. My job is to make the systems agree — and then to build the governance that keeps them agreeing after the project ends.

The second half is the part that gets skipped. An integration without governance decays. Within eighteen months someone has procured a tool outside the architecture, a data owner has left, and the organisation is back where it started with better documentation of how it got there.

Why I still stay close to the technical detail

I hold an MBA in IT Service Management and ITIL 4, and I have also done ethical hacking certification, Microsoft security fundamentals, embedded and robotics work, and Python development. That combination is deliberate.

Architecture produced by people who have never operated a system tends to be architecture that cannot be operated. Having spent four years being called when things broke at 2am, I design differently — with more suspicion of clever dependencies, and more respect for the person who will be on the other end of the escalation.

Most enterprise IT leaders cannot build. Most builders have never run a three-hundred-store rollout. The useful ground is in between.

How I work with people

Every system on this site belongs to someone other than IT — to Finance, Operations, Marketing, HR, or to a franchisee who owns their own business and can simply decline to adopt what you have built. I have never been able to mandate anything into existence. The work has always been to make adoption the obviously better option for the person being asked to change.

That is also how I lead teams. I have mentored IT staff across several organisations, and the measure I care about is what they went on to do afterwards.