2023-09-07

My skip boss used the words “I’ll see if the jet is available” today. In so few words have I rarely had such a realization that someone isn’t concerned about the pieces on the board because they are playing an entirely different game.

The context being that a client wants to bring up the EO project sign off up by a month and get all of the execs in a room - on Tuesday. Of course, last minute flights to Toronto apparently run to $1000/seat and if the whole team is going the economics on private travel suddenly start to make sense.

But who knows? After this week I’m not much in the mood for fighting anymore. I’m just waiting for the kids to sleep so I can have my first shower in four days and get some sleep. I’m more than okay having someone telling me where and when to turn up. I feel like I’ve done enough decision making for the month already.

After emergency coding, hotfixes, pipeline runs and investigation - I finished working sometime around 00h30 last night. By the time I’d written some update emails to the exec and gotten the taste of being awake too long out of my teeth, I rolled into bed sometime around 1 to blackout.

At some point I had to keep rolling a toddler off of me that had suddenly appeared and was trying quite hard to bury his skull somewhere in my thorax. And before you know it, 6 AM rolls around and so starts another day of school prep, bus stops, journeys to daycare.

I think the biggest news of the moment is that the project is saved and will be delivered. The engineering work is done. The science is done. What remains is housework, cleaning and documenting everything. Everything that we tracked down became less important or irrelevant giving the timeline. I’m not sure I want to dwell on it today. Today I want to breathe. Today I want to sleep. There will be plenty of time to reflect upon what went wrong.

Older post

2023-09-06

Newer post

2023-09-08

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.