how i work

I’ve spent a lot of time thinking about what kind of engineer I am. Not in a navel-gazing way ‐ in a “companies keep testing me for things that aren’t my strongest suit while ignoring the things that actually make me useful” way.

Most CVs tell you what someone has built. This page tries to tell you something more useful: what happens when I join your team.

The Short Version

I’m a senior software engineer with 8+ years of production experience across frontend, backend, and AI integration. I write React and TypeScript fluently. I build MCP servers in Go. I’ve led AI adoption initiatives and shipped tools that measurably improved how teams work.

The biggest difference I make isn’t technical. I make teams function better. Not through process documents or motivational speeches ‐ through diagnosis, investment, and the kind of sustained, often invisible work that turns a struggling team into one that ships confidently.

I think of my skillset as a π sitting on a platform:

   _____________        ← Broad technical range
   |           |
   |           |        ← Two technical depths
   |           |
  _______________
 |               |      ← Organisational multiplier
 |_______________|

The two depths are frontend engineering and AI systems. The broad bar is full-stack capability. And the platform underneath ‐ the bit that makes everything else actually work in context ‐ is a set of organisational skills I’ll explain below.

The Technical Depths

Frontend Engineering

React, TypeScript, component systems, accessibility, design sensibility. This is the depth I’ve been building for eight years ‐ component libraries used across international teams, complex financial journeys with cross-functional collaboration across product, UX, banking, and compliance. I care about how things feel to use, not just whether they render correctly.

AI Systems Engineering

Not the hype version. The practical version ‐ the boring-but-useful parts of AI integration. I’ve built MCP servers in Go, led an AI coding assistant pilot for an engineering organisation, shipped AI-powered tools that produced a 60% reduction in test writing time, and designed documentation automation systems. I think about AI as a tool that requires engineering judgement, not a replacement for it.

I also think a lot about what AI adoption actually looks like inside real teams ‐ including the uncomfortable parts. Like the research showing experienced developers work 19% slower with AI tools while believing they’re 20% faster. That kind of gap matters, and I’d rather understand it than ignore it.

The Broad Bar

I’ve shipped production work across the stack ‐ Node.js, Python, Go, infrastructure, deployment, system design. I’m not the deepest expert in any one of them, but I can contribute meaningfully wherever the problem lives. When something doesn’t fit neatly into one team’s domain, I don’t wait for someone else to pick it up.

The Platform Layer

I’ve started calling this the “platform layer” because these aren’t soft skills ‐ they’re the operating system that determines whether technical capability actually translates into organisational outcomes.

I synthesise information across leadership boundaries

In my current role, I’m synthesising the views of multiple senior leaders ‐ each with different perspectives on AI strategy and engineering direction ‐ into a coherent pilot rollout plan. That’s not unusual for me. I tend to end up at the intersection of people who need to agree but haven’t yet found the language to do it. I’ve done this between engineering and operations, between product and architecture, between management and individual contributors.

It’s not “stakeholder management” in the corporate sense. It’s more like translation ‐ taking ambiguous, sometimes contradictory input from people who care about different things, and producing something clear enough to actually execute against.

I diagnose what’s actually wrong

One of the first things I did when joining my current company was compile an eight-page report on the technical, cultural, and organisational issues I’d observed ‐ and share it with engineering leadership. Nobody asked me to do it. I just kept noticing things that seemed connected and eventually had to write it down.

I tend to see technical symptoms as organisational signals. A staging database got wiped because a cleanup function wasn’t scoped properly? That’s not just a code problem ‐ that’s a knowledge silo problem, a documentation culture problem, and a safeguard design problem, all encoded in a few lines of code. I wrote an internal tech blog post about it through the lens of Conway’s Law, because sometimes the most useful thing you can do as an engineer is hold up a mirror.

I transform team dynamics

I joined a team that was regarded as one of the worst-performing in the engineering organisation. Poor delivery, poor dynamics, low morale. Over time ‐ working closely with the engineering manager, advocating for mislevelled engineers, investing in psychological safety and healthy disagreement ‐ that team became one of the highest-regarded. Fast iterations, thoughtful planning, engineers who’d been promoted into senior roles now driving the team’s success.

I can’t take sole credit for that ‐ the EM, PM, and promoted engineers are the ones sustaining it. But I invested heavily in creating the conditions for it to happen.

I don’t wait to be asked

AI strategy proposals, documentation modernisation across 53+ repositories, hackdays, component libraries, coding assistant pilots ‐ the best things I’ve shipped were never on a roadmap. They were gaps I noticed and filled. The difference between initiative and insubordination is whether you bring people with you.

I hold my position when it matters

Across multiple organisations, I’ve navigated situations where my approach ‐ whether it was advocating for a technical direction, pushing for external visibility, or challenging a process that wasn’t working ‐ was met with resistance from senior leadership. I’ve learned that consistency and evidence work better than confrontation. When you bring data, stay professional, and genuinely look for the approach that works for everyone, positions tend to shift over time. Not always, but often enough that the effort is worth it.

What I’m Looking For

I work best in environments that value the whole picture ‐ not just the code, but the thinking, communication, and team investment that makes the code actually matter. Companies where being the person who spots the organisational problem is valued as much as being the person who writes the cleverest algorithm.

Specifically: remote, strong engineering culture, colleagues I can learn from, and enough structure that people aren’t constantly firefighting. I don’t need to be at a household-name company ‐ I need to be somewhere that takes engineering seriously and gives people room to do their best work.

Want to know what drives all of this? Read my constitution.

If any of that resonates, I’d love to talk. You can find me on Bluesky, LinkedIn, or GitHub. Or just read more of my thinking on the blog.