Lecturing eh?

Well yesterday was the final session of my teaching seminar course, which was by and large a necessary evil for me to get a small certificate to say that I can continue demonstrating in the undergrad labs which is a) fun and b) well paid. So the last session was all about presentation skills and leading from the front. Which was then made clear after the initial blurb that 7 of the 28 of us would be getting up front and presenting a 4 minute talk about our PhD (pitched at a first year undergrad level) in front of a camera, to then be watched back and critiqued by the group plus two leaders of the session.

Everyone was then given five minutes to prepare, at the end of which names were pulled from a hat. In a move that came as completely unsurprising to me my name was chosen.

So with no over-heads, no script and no notes in front of me I launched into why life as a bacteria can be difficult when even on a needle point there can be up to 2 million of you fighting over food and mating with each other. So, just as evolution gave chimps sticks to beat each other with, evolution has given you colicins; which you effectively chuck at other bugs and it eats away their DNA so they cant eat, mate, live, nothing. However, when you’ve got hold of them you need to stop them killing you so simultaneous production of an immunity protein is required. This interaction is effectively what I study, and if it can be characteristed well enough; ie know how bugs kill each other, then we as humans can come up with new antibiotics to kill them that mirror the same action.

Needless to say, I thought I rushed through it all a bit quick and slurred my words a bit. However, watching it back, aside from the typical human thing of hearing their own voice back and thinking it’s terribly (as well as my stance) it didn’t seem that bad. But what was really shocking was that I was then asked if I’d done any teaching from the front before. Which I hadn’t really, only the usual uni presentations that everyone else has done at some point. I was then told by several peers and a former lecturer that they’d hire me in an instant on that performance.

Afterward, I was caught by the seminar leader and told that I should really consider lecturing as a career. Apparently I have a relaxed, informal style and conveyed the information well whilst making it relevant and most importantly really interesting.

So, given the parents, maybe there is a gene for teaching?

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.