2023-09-01

Another excellent networking event thanks to the Avansai boys. I don’t quite know what it is that makes for a good networking night. Maybe it’s a case that I’m previously tormented by past experiences of bad events. But perhaps the mindset is different now. The last real networking events I attended were either initially when I landed in Vancouver and was desperately trying to find a job. Or they were in Vancouver when I had a job that I wasn’t enjoying and was trying to leverage the night to find something else.

In the first, I think I ended up in the wrong place. It always would turn into small business owners trying to pimp their services - and there isn’t much wrong with that - but it all felt very transactional.

In the latter, the events were often history by some up-and-coming company that had recently come into some new money and was shamelessly using the whole event as a sales funnel and/or long interview process.

These are the first times I’ve attended networking events with no real agenda. I’m just there to have a beer or two and have a conversation with some interesting people.

I suspect that having a curated attendee list goes a long way to this. As recruiters, they are going to be meeting a lot of people and they are going to have to have a reason to keep some of those people around in social circles even if they are not actively job hunting on either side of the table.

In fact, I’d go as far as saying that it was a very enjoyable evening. Having exposure to some new perspectives and new people is always great. But sharing some laughs around past experiences and war stories starts to feel a little like group therapy.

Maybe that’s what I’ve been missing for a while. I don’t have a lot of some connections outside of the workplace and now with the extra job title and responsibilities I feel a certain professional difference between many. My parents have argued that perhaps that barrier is of my own invention and I should insert myself into having lunch with the new guys and building a more natural relationship with them. But with leadership comes a certain expectation of not badmouthing the company, the clients and anything else. I feel like any opinions I express, however fleeting in my mind, likely hold a lot of weight to the others.

So to anonymously compare scars with a few other industry veterans is very cathartic.

Older post

2023-08-30

Newer post

2023-09-03

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.