Insights and Battle Scars
Leading Technology Through Change Since 1999
In 1999 I took my first job in IT, the summer before university. I was part of an ERP deployment project - unpacking computers, wiring up a factory floor and its offices, setting up Microsoft Exchange accounts for users who’d never heard the term. I didn’t think of it as the start of a career. I just knew the job was to make a specific thing work.
That’s still mostly what the job is, whatever the title says. Solving problems. Making the complex legible. Removing the friction that stops a business doing what it’s actually capable of.
Where the Distance Comes From
Somewhere along the way, the industry decided seniority means distance - the more senior you get, the further you move from the actual work, until you’re reading summaries of summaries and signing off on decisions you couldn’t execute yourself if you had to. I’ve watched capable people get promoted into that distance and stay there. There’s a case for it - distance buys scale, and nobody can stay hands-on with everything forever. What I do believe is that the best leaders stay capable of going deep when it matters - not as a habit, but as a choice.
Whatever the title said in any given year, I chose to stay close to the configuration screen, the migration plan, the budget line - not because the role demanded it, but because the decisions I was making at the top required it. That habit started early, doing the unglamorous work nobody puts on a slide, and it never left.
What changed over the years was scale: being handed problems complicated enough that the existing playbooks didn’t apply, and having to build new ones under pressure, in real time, with real consequences. That’s the part of a career that never shows up as a single line on a CV - but it’s usually the part that decides whether you’re ready for what comes next.
What the Work Has Actually Looked Like
The work has ranged widely - leading enterprise IT functions through major transformation, untangling technology stacks during corporate separations, running large-scale cost and efficiency programmes across organisations with hundreds of services and dozens of business units, working in pre-IPO environments as well as smaller organisations where speed and agility matter more than process.
If there’s a common thread in what I’ve gravitated toward, it’s organisations in motion - mid-transformation, mid-separation, mid-scale. Stable-state IT was never what interested me. The problem I find genuinely engaging is the one where the playbook doesn’t exist yet and the org chart is still being redrawn under you.
The thread through all of it is the same: technology decisions made at the top only hold up if the person making them still understands what’s happening at the bottom.
The Part That Isn’t on the Org Chart
None of that work gets done by one person, and it’s never really been the systems that interested me most - it’s the people who run them.
Every transformation, separation, or turnaround I’ve led has depended on a team I built, rebuilt, or inherited and had to reshape fast. Hiring for capability the org doesn’t have yet. Developing people into problems they haven’t faced before. Staying close enough to mentor, not just manage. That work is slower than any migration plan and it doesn’t show up on a Gantt chart, but it’s the actual mechanism by which anything at scale gets delivered - you don’t out-architect a hard problem, you out-team it.
That’s also, not coincidentally, the part of the job I’ve found most enjoyable. Systems can be redesigned. Watching someone grow into a role they weren’t ready for six months earlier is the part that’s stayed with me.
A Lesson That Didn’t Look Like One at the Time
One that’s stayed with me: leading a separation programme, sitting through a planning session where the technology split looked clean on paper - a few systems to duplicate, a few contracts to novate, a manageable timeline. What nobody had mapped was the complexity underneath it all: identity, data, UX - the quiet plumbing both sides assumed the other would keep running. Untangling that took longer than every system migration in the plan combined, and it never once made it onto the executive summary slide.
The lesson wasn’t about separations specifically. It was that the riskiest part of almost any technology programme is the part that’s invisible precisely because it’s still working. Nobody schedules a workstream for the thing that hasn’t broken yet.
Why “Insights and Battle Scars”
That’s the belief this publication is built on, and the reason for the name. A notebook isn’t a polished record - it’s where the working notes live, the half-formed conclusions, the things you noticed on the way to actually understanding something. That’s closer to what I want this to be than a highlight reel of a career that’s nowhere near finished. This is written for people leading technology through scale, separation, or change of any kind. Not a victory lap - the insights worth keeping, and the battle scars that produced them.
What’s Next
From next week, I’ll be writing about the things that don’t usually make it into the polished version of technology leadership: the discipline of not adopting the newest version of anything the moment it ships, what actually breaks when you separate a technology stack from a parent company, the gap between what a CFO wants to hear about an IT budget and what a CIO usually says, how you build and mentor a team capable of executing under pressure - not just staffing a chart, and the parts of the job that don’t get easier just because the title in front of your name has changed.
If any of that sounds useful, subscribe for new deep dive articles weekly.