About me (2012)

So, let me tell you a little bit about me. I was born at a young age over a view over the South coast of England; I believe it was the 16th floor of the hospital at around 6 in the morning whilst the sun was still rising. I’m almost positive that if it were not for all the drugs and agonising pain that my mother would have appreciated the beauty.

However, I remember little of that place as at the age of 2 my family moved to a small town further West between Southampton and Portsmouth where I’d consider myself to have a rather ordinary and modest upbringing. However, 8 years later on my 10th birthday nonetheless, the family up and moved again. This time to West Norfolk. I remember not being terribly happy with the move and many a night wide awake, unable to sleep with concern.

But I came to love the place. And after several years in the education system in the local vicinity I was due to leave the place with an assortment of GCSE’s and A levels with a definite focus upon the natural world sciences and information/communications systems (or computers to most people). After a few decisions that were not really founded on logic I found myself in the October of 2005 at the University of Nottingham studying Biochemistry and Biological Chemistry.

I wish that I could say that I had an easy time at Nottingham, but that was far from the truth. Through a combination of factors, like some crazy relationships, a ridiculously demanding course, a difficult social life and developing inability to tolerate idiots or lad-ish behaviour it took a long time to acclimatise to any vague sense of normality. However, at some point something must have changed because at the end of 4 years and a Masters certificate, I was rather fond of the place and was sad to be leaving.

Alas I was moving on to bigger and better things. Still interested in the sciences and scientific research the choice of a PhD came easily and after much searching and jaunting up and down the country I decided upon the University of East Anglia in Norwich. And this is where you join me now. As a PhD student in the MacMillan group trying to work out how proteins bind to each other and ultimately how bacteria can kill each other without killing themselves. Which would make the ultimate aim to be assisting in the discovery of new, novel antibiotics.

How do you define successful engineering leadership?

The Philosophy

Many view technical leadership as being the “smartest architect in the room.” I see it as the opposite. My job is to build a room where I don’t have to be the smartest person because the systems, culture, and communication are so robust that the team can out-innovate me.

The Strategy

  • Alignment: Does every engineer understand how their sprint task impacts the company’s bottom line?
  • Velocity vs. Stability: We aren’t just “shipping fast”; we are building a predictable, repeatable engine that doesn’t collapse under its own weight at the next order of magnitude.
  • The Human Growth Curve: Success is when the engineering team’s capability evolves faster than the product’s complexity. If the team feels stagnant, the tech stack will soon follow.

What is your approach to scaling technical organizations?

The Philosophy

Scaling isn’t just “hiring more people” - that’s often how you slow down. Scaling is about moving from Individual Heroics to Organizational Systems.

The Strategy

  • The 3-Continent Perspective: Having managed global teams, I focus on “High-Signal Communication.” As you grow, the cost of a meeting triples. I implement “Asynchronous-First” cultures that protect deep-work time while ensuring no one is blocked by a timezone.

  • Modular Autonomy: I advocate for breaking down monolithic teams into autonomous units with clear ownership. This reduces the “communication tax” and allows us to scale the headcount without scaling the bureaucracy.

  • Automation as Infrastructure: At petabyte scale, manual intervention is a failure. I treat the developer experience (CI/CD, observability, self-service infra) as a first-class product to keep the “path to production” frictionless.

How do you balance high-growth velocity with technical stability?

The Philosophy

Technical debt isn’t a “bad thing” to be avoided; it’s a set of historical decisions that no longer serve you. Like any loan, leverage can accelerate growth when investments payoff. But if velocity and returns are slowing you need a payment plan before the interest kills you.

The Strategy

  • The ROI Filter: I don’t refactor for the sake of “clean code.” I don’t refactor a micro-service with no users. I refactor when the pain on that debt - measured in bugs, downtime, or developer frustration - starts to exceed the cost of the fix.

  • Zero-Downtime Culture: Especially at scale, stability is a feature. I implement “Guardrail Engineering” where the system is designed to fail gracefully, ensuring that a Series B growth spike becomes a success story rather than a post-mortem.

  • The 70/20/10 Rule: I typically aim to dedicate 70% of resources to new features, 20% to infrastructure/debt, and 10% to R&D. This ensures we never stop innovating, but we never stop fortifying either.