2023-08-18

Where to begin? I recently was browsing through YouTube and got to the bottom of all of the usual suspects and started into the random suggestions. Whereupon one of the first recommendations was something with an outrageously clickbaity title of something like “I’ve been journaling for 13,000 days - here’s what I’ve learnt”

Needless to say, I watched it all 13 minutes of the thing. There was nothing new there that I haven’t seen before. But it did remind me that it is a practice that I should restart again. During my formative years of high school and college I blogged semi-regularly as a form of carthacis on a since defunct platform, called Bebo. I somehow wish I had managed to capture a dump of all of those memories before they disappeared in the digital ether, but alas, c’est la vie.

Over the years, my online blog moved online to a Wordpress site with sporadic moments of activity. Notable towards the end of university, and again once I moved to Israel.

Then within Canada, I tried “Morning pages” for a while. But the time commitment of 2 sides per day removed the fun of the thing - plus writing by hand these days is frustrating slow. After some Tim Ferriss recommendations, I also tried the 5-minute journal for a month or so upon moving to Montreal. But that didn’t stick either, but I felt that was concentrated enough. Or rather not enough of a time commitment to really have much inertia.

So here I am, the week of my 36th birthday, making a pledge. For the next month, I will commit to writing for 10 minutes per day. No jumping off point. No prompts. No real editing. I want this to be as easy as possible. I want this to be a stream of consciousness.

With a little time, perhaps I shall start to include a weekly, monthly, quarterly review process so that I can notice some general trends in what is going on.

For the sake of confidentiality, I shall keep names vague, randomly assigned and mostly in the abstract. After all, I mostly want this to be a reflection of my inner thoughts and not externally focused. Similarly, to avoid a recency bias and having people jumping in with commentary or support, I think I shall introduce an artificial delay of a few weeks between writing and posts being published.

I don’t want this to turn into a self-indulgent therapy session, just musings on a virtual page. And with that, concludes by first 10 minutes. Were they spectacular? Not by any stretch. But maybe, one day, my boys will find these scrawls and they might understand me better.

Newer post

2023-08-20

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.