That slightly racist car game

Walking to the car last night after Jason’s humiliation at badminton I was reminded again of a little game that I invented on Friday. A game that after some time I affectionately named “Jerry, Jap or Yank”. The game itself was created as I waited for an every 5 minutes bus (I stood there for 37 minutes in the end) outside Cambridge train station.

After some time of generally starring at nothing it dawned on me that nothing seemed to be driving past me except VWs and Audis. Upon this realisation it then become somewhat of a personal challenge to then try and spot cars that went past that were not of German construction (or at least design). This itself became quite a difficult game as by and large the vast majority of traffic traveling into the train station cul-de-sac are private hire taxis in nature. This meant that almost every thing going past was a VW Passat, large Audi (A6-esque) or Mercedes van-taxi conversion. Less often were BMWs or Skodas, but then these are both still German in design.

The only frequent cars that were excluded from the German rule turned out to be Ford Mondeos (yank) or Toyota Corelloas (Japanese representation). Far less often were London Taxi cabs (the largest remaining British car manufacturer) and Frog cars (Peugeot 4007 and Citroen C5). And in last place was the strange entry by the Koreans, with the Kia van type 7-seater thing.

So my only conclusion that I can take away from the modestly racistly named game is that Cambridge only seem to buy Jerry or Jap cars. Big ol’ diesel ones at that. Very strange from a very proud, old, “green” city like Cambridge. But more importantly, are there only 11 cars in the world now?

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.