2023-09-09

I’ve been thinking about friendship a little recently. I heard a story of a fraternity brothers that had known each other now for four decades. Last month, one of the brothers was taken early by a quick and painful fight with cancer. The other 4 brothers crew in and across oceans and continents to be there for the death of a man they might also an entirely lifetime ago.

After he died, the brothers - all wildly successful in their own domains - took an additional week out of their lives to close the estate, clear his home and ensure that his surviving kids would be taken care of.

In contrast, our primary couple friends here in Montreal have been notably pulling away from us for some weeks. It’s been a slow retreat in my mind, but something clicked in N’s head last night. She is becoming hardened to this now after many years in academia where it is the normal for friends to move around the planet every few years to chase the next position. But I could tell that this realization still stung.

For me, the surprise was lessened as my read on the person was as a social butterfly. Connected to many, but dances in the wind, never settling in only a breath of wind.

Recently, plans have never been cemented. Questions of future plans are always met with cagey and deflective responses.

Enough. I’m too old and intolerant for people that cannot be straightforward. I know what I am. I am comfortable in who I am.

I have known for many years, I have a small number of people that I could call on. Proper relationships. The sort you can pick up after a few years and pick up a conversation as if it were last weekend.

My regret is that, of these 5 or so people that I would help die, they are all so far away. What of the friend that’s just there for a weekly beer?

Maybe I need to fix that.

Older post

2023-09-08

Newer post

2023-09-10

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.