Always Sharp

I'm writing this from the inside of a transition I haven't finished yet. The kind of chapter where you can already feel its weight — but can't yet see what the after looks like.

This post is not a highlight reel. It's a prelude — the context behind why I'm here, how I got here, and what I hope to find. I'm writing it partly to process the transition, and partly because I believe the messy middle deserves more honest documentation than it usually gets.

The Chapter That Came Before

For several years, I worked inside a major media organisation — one of the larger broadcasters in the country. I joined as an engineer and, over the years, worked my way into a Technical Architect role.

The title changed, the instinct didn't. I started as a senior Java developer — billing systems, domain logic, the kind of code that quietly underpins how a business actually runs.

What shifted over time wasn't whether I was building, but what I was building. The craft evolved from software to platform: streaming infrastructure, identity and access management, CI/CD pipelines, internal developer platforms. Different materials, same builder.

At its hardest, the shift wasn't about the scale of the problems — it was about the nature of the work itself. As a developer, the path is clear: stories, tickets, acceptance criteria. You know what done looks like. As an architect, nobody hands you that clarity. You have to go find what's broken, what's quietly failing, what nobody has named yet. You develop an instinct for the gaps — and then you make the case for fixing them. The path isn't always there. Sometimes you're the one paving it.

A Groove Worn Too Deep

After a while, I settled into the rhythm of the architect role. The ambiguity that once felt disorienting became familiar. I knew the systems, knew the stakeholders, knew where the bodies were buried.

And that's when it started to feel wrong.

The organisation's direction shifted in ways that weren't always easy to follow. AI entered the picture — not as a feature, but as a force quietly reorganising what mattered and what didn't. Suddenly the conversations weren't about what to build next, but whether certain things needed building at all. The role I'd shaped around myself began to feel less like a fit and more like a groove I'd worn too deep.

I wasn't unhappy. I was comfortable. And comfortable, I've come to believe, is its own kind of warning sign — the kind that doesn't announce itself loudly, but accumulates quietly until you look up one day and realise you've stopped being challenged.

Was I growing, or was I just getting more familiar with the same walls?

Down to the Foundation

The opportunity that came next wasn't a tidy progression. It was a deliberate step into unfamiliar territory.

A chance to join one of the world's most technically demanding engineering organisations as a Systems Development Engineer — building and owning cloud infrastructure at scale. Not designing platforms that ran on top of infrastructure. Building the infrastructure itself. The layer that software like mine used to sit on.

I won't pretend I wasn't anxious. This was new. My experience at this layer of the stack was thin, and I knew it. There's a real gap between understanding how infrastructure works in principle and being able to own it in production — and I was starting on the wrong side of that gap.

But the anxiety was also a signal. I'd spent years building things that ran on someone else's foundation. Now I had a chance to go deeper — to understand, and build, the foundation itself.

So I said yes.

Scale Changes Everything

The difference between my previous role and this one isn't just a change of stack. It's a change of scale — and scale changes everything.

Where I used to see the whole engine, here you see a part of it. A small, intricate, critical part. And one of the first things you learn is how much that part matters — how a change in one small corner can ripple across something enormous. You develop a different kind of respect for the system fast.

Things that felt straightforward before carry a different weight here. A config change. A deployment tweak. A dependency update. At this scale, "simple" is relative — the blast radius is real, the coordination required is real, and the margin for assumption is a lot thinner than you're used to.

It's not just the architecture or the codebase you have to navigate. It's the organisation itself. There are dedicated teams for things I used to handle as a side concern. There are internal tools for workflows I used to cobble together myself. Things I thought were niche — the kind of thing only a handful of people cared about — turn out to have entire groups owning them, refining them, building on top of them.

And everyone here is a builder. That's the part that's hard to explain until you've seen it. Internal tooling exists in every corner. The instinct to build a better solution rather than accept a worse one isn't something you have to advocate for — it's just the culture.

For me, that's been equal parts humbling and energising. I've always taken pride in being full-stack — comfortable across the whole surface of a system. But I've never stretched my infrastructure and cloud muscle like this. Never had to. Now I do, every day. And I'm finding muscles I didn't know I had.

An Unexpected Turn

I'd barely found my footing when the ground shifted again.

Circumstances changed — the kind you don't see coming and can't fully control. What had felt like the start of something became, almost overnight, something I had to step away from. I won't go into specifics. Some things aren't mine to document publicly.

What I can say is that I suddenly found myself needing to find a new role. Internally, externally — whichever came first. And I had to move fast.

The position I was in made it harder than it sounds. I'd just completed onboarding. No production code. No deployments. No I shipped this to point to. Just weeks of ramp-up and a head full of context I hadn't had the chance to use yet. In interviews, that's a difficult thing to explain — and an even harder thing to prove.

And that's before you get to the question every external recruiter asks within the first five minutes: you've only been there a few months — why are you already looking? A reasonable question. A hard one to answer when the honest answer involves details you can't share. You end up finding ways to be truthful without being specific, which is its own exhausting skill to develop mid-panic.

Internal roles turned out to be just as rigorous as external ones — sometimes more so. Full interview loops. Systems design. Coding assessments. External interviews brought their own rhythm: LeetCode patterns, maintainability questions, data structures and algorithms, and systems design — resources like the System Design Primer and Karan Pratap Singh's system design guide became daily reading.

There's a quiet irony in that. AI was already part of what made my previous role feel stale — the force quietly reorganising what mattered and what didn't. Now it was reshaping the interviews themselves. Take-home assessments — once a standard way to evaluate technical candidates — have largely disappeared. When you can't know whether a submission reflects the person or the model, you bring the person into the room. Live coding, real-time, no buffer. The same knowledge, under considerably more heat.

I went from finishing onboarding to drilling interview prep almost overnight.

There's a particular kind of strain in holding both at once — the mechanical grind of interview prep and the quieter weight of circumstances you haven't had time to process. Neither gets your full attention. Both demand it.

I'll be honest: I've never been a natural interviewer — and I mean that in the fullest possible sense. There have been times I've sat on the other side of the table, running the interview, and somehow still ended up more nervous than the candidate. They were composed. I was not. The knowledge was there, but translating it under pressure — clearly, confidently, in the structured way interviews demand — has always been something I've had to work at. This time I didn't have the luxury of gradually improving. I had to get good fast.

So I drilled. Not just to learn the patterns, but to internalise them. To practise until the thinking became automatic — until I could walk into a room without the panic eating into my working memory. The goal wasn't brilliance. It was calm. Muscle memory, essentially. Know it so well you don't have to think. Just execute.

A Different Door

Two months of that, with an internal window that wouldn't stay open indefinitely. Every week brought more interviews, more loops, more assessments. The pressure of it compounded in a way that's hard to describe unless you've been in it.

And then, finally, an offer came through. A different team entirely. A completely different domain. And if anything, a steeper learning curve than the one I'd just been getting used to.

Second team. Second onboarding. The same first-week feeling — new systems, new vocabulary, new faces, new ways of doing things — except this time I knew what I was walking into. I'd just done this. I knew the shape of the disorientation, even if the specifics were completely different.

There's something almost darkly funny about it. I went from technical architect to new joiner, got used to being a new joiner, then became a new joiner again in an entirely different context. Each time starting from scratch. Each time carrying a little more scar tissue. We're barely halfway through the year. Third role.

There's an added wrinkle with this one: the team reorgs often. People come and go before you've had time to map the room — let alone find your footing in it. I've met people who've already cycled through teams in the time I've been there. It's a different kind of uncertainty — not just what am I building, but who am I building it with, and for how long.

It wasn't what I'd imagined when I said yes a few months ago. But it was real, and it was forward, and right now that matters more than direction.

Always Keep Your Knives Sharp

My mentor used to say it almost offhandedly: always keep your knives sharp.

I didn't fully appreciate it then. I do now.

Not because I was unprepared — but because I came close enough to unprepared to feel the difference. The interview loops, the LeetCode sessions, the systems design questions: none of it would have gone the way it did if I hadn't kept practising, kept building, kept staying current even when I had no immediate reason to. That sharpness was my leverage. The one thing I could reach for when everything else was uncertain.

The other lesson, harder to sit with: don't let the situation make the choice for you. Everything changes — roles, organisations, the ground beneath you. AI reorganised what mattered in my last role; now it's reshaping how engineers are evaluated. It won't stop there. The only real hedge is staying ready. Not anxious, not paranoid. Just sharp enough that when it shifts, you're the one deciding what happens next, not scrambling to catch up with what already has.

Always sharp.