Staying Close to the Work

Introduction

Over the years, I’ve learned that the quality of software is closely tied to how involved you are in building it.

The further I moved away from hands-on work, the less effective I felt.

From building software to overseeing processes

As my career progressed, I naturally moved into technical leadership roles and, eventually, into a purely management position. On paper, it made sense: broader scope, more responsibility, less day-to-day involvement.

In practice, something important was missing.

I was no longer designing systems, weighing technical trade-offs, or building things directly. My role became focused on overseeing processes rather than shaping solutions. Processes matter, but they aren’t a substitute for hands-on involvement.

I’ve found that, for me, software quality comes from staying close to the details. When decisions are made too far away from the people doing the work, important trade-offs get lost. Over time, that distance shows up in software that’s harder to use and systems that are harder to change with confidence.

That wasn’t a direction I wanted to continue in.

Choosing to stay hands-on

I realised that where I add the most value is by staying directly involved in design and development. Not just writing code, but understanding problems properly, making careful decisions, and seeing those decisions through to shipping software. Keeping the loop tight between design, development, and feedback matters.

Moving into contracting allowed me to do exactly that.

It gave me the independence to remain hands-on while still working at a senior level. I could take responsibility for real systems, work closely with development teams as well as product management, and stay involved in the details that ultimately determine whether software succeeds or fails.

This is what led me to found Compiled Creations, a consultancy built around senior, hands-on software development.

Independence, variety, and building my own things

There were other motivations too, and I think it’s worth being honest about them.

I wanted independence: the freedom to make good technical decisions without being constrained by internal politics or rigid processes.

I wanted variety: exposure to different domains, products, and teams. Working across a range of projects sharpens judgement and makes patterns, good and bad, easier to recognise.

And I wanted time to build my own projects.

That last one matters more than it might sound. Building your own software forces you to live with your decisions. It makes you care deeply about maintainability, clarity, and long-term trade-offs, because you’re the one who has to deal with them later. That freedom also means I’m constantly learning and sharpening my technical judgement.

All of these things make me better at my work.

What this means for clients

For clients, this approach has some very practical benefits.

You’re working directly with the person making the technical decisions, not through layers of management. There’s no hand-off between strategy and implementation, and no dilution of responsibility.

When something works, I’m accountable. When it doesn’t, I fix it.

It also means the focus stays where it should be: on building software that is understandable, adaptable, reliable and supports the business rather than becoming a liability over time.

A deliberate choice

Starting Compiled Creations wasn’t about stepping away from responsibility. It was about choosing the kind of responsibility that matters most to me, and, I believe, to the people I work with.

I wanted to stay close to the work, close to the decisions, and close to the outcomes.

That’s what Compiled Creations is for.