2023-09-05

And with the start of September comes the summer heatwave that never happened. Temperatures have suddenly jumped into the 30s and with humidity around 90% it feels around 40. It’s the sort of weather that makes me instantly grateful for air conditioning to give me a fighting chance at sleep.

But also September brings maybe the end of the supermarket project. It’s been a bit of a rough one - and on many fronts. The project, the science, the staffing. Even when I thought I was clear of this thing, it finds a way to throw some last minute surprises at me.

With literal single digits to delivery and walking away for good a couple of last minute sanity and safety checks revealed that the solution was only producing 1/16 the volume of output it was a few months ago.

Was this expected? Who knows? Was the quality of the stuff we were producing reduced? Again who knows? And when did all of this happen? Beats me!

It just goes to show that the monitoring of the ongoing solution was subpar at best. And it highlights to me a woefully shortcoming in the amount of routine, end-to-end testing that we put in place.

As a former president said “the buck stops with me”. Which meant that I spent a large majority of my long weekend going through every single pull request over the last 6 months - line by line - and evaluating every change that could have made a difference to the model output. A thankless, dumpster diving activity trying to cross reference work against tickets and an absence of documentation. You would think at this point I would’ve learnt the lesson around writing documentation and keeping an audit trail for this exact reason.

But it’s the same on ever project. Every time I think this time the team will be different and people are grown ups and I won’t need to baby everyone into writing stuff down. And time and time again I get halfway through the project and realize that we’re stuffed and need a hard pivot. Perhaps the rational move would be to set high expectations early and just keep them there.

Older post

2023-09-03

Newer post

2023-09-06

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.