by Gary Worthington, More Than Monkeys

If there’s one constant in a 20-year tech career, it’s change. Languages evolve, frameworks fall out of favour, and business models pivot faster than you can say “Series A.” But if you’re someone like me, who’s been a founding engineer, a CTO, an agile coach, and a hands-on polyglot developer, then you learn to treat that change not as chaos, but as context.

This is a look back at my career. Not a victory lap, not a highlight reel, but a practical reflection on what I’ve done, how I work, and what I’ve learned about building things that last.

1. Building From Nothing

Some of the most formative years of my career came from starting things from scratch. There’s a rawness to building version one of something when there is no backlog, no architecture, and often no team. You’re the developer, the ops person, the tester, and the one answering support calls too.

At The Coaching Manual, I wasn’t just writing code. I was helping to invent the business. That meant designing for real-world constraints like poor mobile reception and low end devices, not just edge cases in the code. I was responsible for technical direction, hiring, delivery, and uptime.

Same story at Yepic, a social network for tradespeople. We went from zero to 15,000 users in under 12 months. That growth came from fast feedback loops, ruthless prioritisation, and a strong understanding of who we were building for. The codebase was clean, but the decisions were messy; like they should be when you’re iterating your way to product-market fit.

2. Fractional CTO: Deep Impact Without the Overhead

Over the past few years, I’ve taken on several Fractional CTO roles, embedding into early-stage teams and offering senior technical leadership without the commitment of a full-time hire. These roles are about more than just writing code. They’re about helping founders make good technical decisions quickly, without getting lost in the weeds.

At Your Pilates Physio, I helped transform a one-person operation into a robust, revenue generating, subscription-based video platform. We navigated everything from video encoding to payments to mobile optimisation — solving technical challenges in a way that supported long-term growth, not just launch-day hype.

At Cricket Allrounder, a global cricket coaching platform, I helped scale from an idea to over 75,000 users across multiple countries. That involved building and evolving a cross-platform mobile app, integrating coaching workflows, and making sure the tech could keep up with a highly seasonal, content-heavy model. We leaned on tools like Flutter, Firebase, and AWS to deliver something that felt responsive and polished, without needing a large team.

Fractional CTO work suits me well. It lets me jump into the heart of a business problem, make sense of the chaos, and build just enough process and platform to keep momentum going. It’s hands-on, it’s strategic, and it’s incredibly rewarding when it clicks.

3. Enterprise at Scale

I’ve also worked at the other end of the spectrum: places like Sky Betting & Gaming, Interactive Investor, and NHS Digital. These were complex environments where architecture decisions had long tails, and trade-offs had to be surfaced early.

At NHS Digital, I was a Principal Software Engineer working on national-scale systems. I focused on making cloud-native services secure, scalable, and performant. That included deep involvement in security reviews, automated CI/CD practices, and ensuring that the patient-facing experience was as fast as the tech behind it.

At Interactive Investor, I stepped into an Engineering Manager role and helped shape engineering culture during a time of rapid scaling. That included rolling out Scrum training, onboarding new engineering managers, and introducing practical metrics like DORA to improve delivery without over-optimising for velocity.

4. Leadership Without Letting Go of Code

Too often, engineering leadership is seen as a trade-off — you either manage, or you code. I’ve always rejected that binary. At More Than Monkeys, my consultancy, I help startups solve real business problems using technology. That means I still write production code regularly. It also means I spend just as much time in Miro, Figma, and Google Docs as I do in VS Code.

For me, being technical isn’t about clinging to old skills. It’s about bringing credibility to the conversation. Whether I’m working with product teams, mentoring junior engineers, or debugging why a Lambda isn’t triggering, being hands-on keeps me grounded in reality.

5. Working in the Messy Middle

A lot of engineering work doesn’t live in greenfield code or big bang releases. It lives in the messy middle, where legacy systems meet modern tooling and where business priorities shift mid-sprint, and where “technical debt” is often just a shorthand for decisions made under different constraints.

That’s where I tend to operate best. Helping teams unblock delivery, find clarity in uncertainty, and build sustainable paths forward. Sometimes that’s through process, sometimes it’s through code, and sometimes it’s just asking the right question in the stand-up.

6. What I Look For Now

Right now, I’m open to contract and interim opportunities via my consultancy. I’m especially interested in roles where I can:

• Help early-stage companies build strong technical and organisational foundations
• Lead or coach multi-disciplinary teams through delivery transformations
• Solve real-world engineering problems in Python, AWS, or TypeScript
• Balance delivery speed with long-term maintainability

I don’t chase titles. I look for places where I can bring clarity, accelerate progress, and leave things better than I found them.

Final Thought

If you’ve read this far, thank you. If you’re a founder wondering how to get your MVP shipped, a CTO looking to steady a wobbly platform, or a Head of Engineering trying to scale your team without breaking your culture, please get in touch.

I’m not here to “disrupt” your business. I’m here to help you build it properly.