Agency to contracting to product: the same engineer, different time horizon

If you compress my recent career into one clean line it sounds very tidy: agency years at Torchbox, then contracting through Developerfy, then product work at Mabyduck.

Living it felt much less like a neat staircase. More like learning the same lessons at different speeds, under different kinds of pressure, with different people checking your work.

The biggest shift wasn't title. It was time horizon - and realising how much that one variable changes everything else.

Agency years: pace, ambiguity, and keeping people calm

At Torchbox (2019 to 2024), I spent a lot of time entering unfamiliar codebases quickly, making progress under delivery pressure, and working across design, content, strategy and engineering without anyone losing the plot.

Agency work forces a handful of habits you either learn or suffer for:

find constraints fast - scope creep is silent and lethal;
communicate in plain English, because clients aren't reading your inline comments;
scope for delivery, not for architecture theatre;
leave codebases better than you found them, even when no one would notice if you didn't.

The thing I underestimated at the time was the soft skill underneath all of it: keeping people calm when priorities shift every five minutes. That has nothing to do with engineering and everything to do with delivery. It still pays rent every week.

Contracting: creating value with limited runway

Contracting sharpened a different muscle. You're dropped into systems you didn't design, with limited time for perfect context, and you need to create real value quickly - or the engagement doesn't extend.

Every new contract I asked the same questions:

what actually matters right now, not what's on the backlog;
what risk is acceptable given the timeline;
what changes are reversible if I'm wrong;
what needs writing down for whoever comes after me.

That last one made me much stricter about leaving intent in the code and in the docs. If future engineers can't understand why I did something in one pass, I'm not done - even if the ticket says closed.

Contracting also killed my appetite for "let's explore for a few months." Exploration is fine. It still needs to land somewhere useful.

Product work: compounding outcomes over months, not sprints

Moving into full-time product work changed the scoring model entirely. You still need pace, but now you live with the long tail of your own decisions. That quiet accountability changes how you think.

The questions I ask now are more boring, and therefore more useful:

will this reduce repeated incidents over the next quarter, or just fix today's fire?
does this make delivery easier for the whole team, not just this feature?
can we reverse course if our assumptions turn out to be wrong?
are we improving reliability and speed together, or trading one for the other?

Earlier in my career I measured progress mostly by direct output - shipped features, closed tickets, lines changed. I still like shipping. But I care more now about whether the team ships predictably, without heroics, without someone staying late on a Friday to hold things together.

What stayed the same across all three

The context changed. The core principles didn't:

clarity beats cleverness, every time;
accessible, reliable software isn't optional;
good scope is ambitious and controlled, not just maximal;
most engineering pain is communication pain wearing a technical disguise.

Those principles held at agencies, on contracts, and in product teams. They're the ones I'd bet on continuing to hold.

Why I'm enjoying product work more right now

Product engineering has given me room to fix root causes instead of repeatedly treating symptoms. That's deeply satisfying if you've spent years in environments where you only ever got to treat the symptoms.

It also means fewer weekly fire drills - which, weirdly, gives me more energy for side projects and tinkering than I had when things felt constantly urgent. Turns out calm systems are good for uptime and for humans.

If you're making a similar move

The temptation when changing context is to reinvent yourself - to leave the old version behind. I'd push back on that.

Keep the pace from agency work. Keep the decisiveness from contracting. Add the durability that only comes from owning long-term outcomes. That blend has been the most useful version of engineering for me.

Final thought

Career transitions get framed as reinventions. Mine felt more like lens changes.

Same core values. Same enjoyment of building useful things. Better understanding of where speed helps, and where speed starts to get expensive.

And yes, I still enjoy a properly gnarly debugging session - provided it wraps up before Friday dinner plans.