2024-01-11

Mortality

A podcast has had me reflecting recently. Maybe journaling in this semi public venue where anyone with the way-with-all could seek it out and read along with my life. Well, is that such a selfless task?

Is it perhaps just another way of trying to create a corpus. A body of works. Renown in some form. Which, when all is said and done, isn’t that just another vein attempt at immortality and trying to somehow live on after my own passing.

As that old saying goes, we die twice. Once when our body and mind part ways, and again when no one will ever think of us again.

Some mighty names and minds have reached a pseudo escape velocity past death. Names like Newton will echo through the ages. But how much do people really remember of these people?

Newton for instance was a devote Christian, and spent much of his life in silent prayer. And whilst we remember him for mathematics and gravity, most people don’t know that he spent almost the rest of his life trying to turn common metals into gold.

Or perhaps I’m just overthinking things. Perhaps I’m just welcoming the distraction. I could really use it.

Planning & politicking

This week has seen me on site with a client for a multi day planning event trying to objective set for the year and then accurately plan and goal set for the next quarter.

Clearly, no one there knows the Mike Tyson quote of “everyone has a plan until they’re punched in the face.”

It was the worst kind of big corporate experience. In a nondescript grey box next to the airport. The corridors, hum with fluorescent lights. All the doors are locked. Our conference room. White walls, grey carpet, grey plastic chairs, grey plastic tables with a view that overlooks a grey car park and grey skyline.

A room full of the sort of people that would rather talk about the thing, than just do the thing. Who would rather plan a thing, than do the thing. Who would rather call a committee to discuss the thing, instead of doing the thing.

Just. Do. The thing.

With some quick math, given the 50 people in the room, I estimated that the event cost the company close to a quarter million. That’s a lot of cabbage. That’s a lot of productivity.

However, it was useful to me for it crystallized my thinking on a few topics.

It made me appreciate that I don’t work in a 1960s prison for one.

But it made me realize that the apathy has kicked in with this project. Between the politicking, education of people that really should know better and terrible catering there were a few moments that until very recently would have made me angry.

But I can’t even be bothered to be angry anymore.

I’m just numb.

However, the politicking was extremely successful so we now have an arranged deliverable - which isn’t crazy - and it should leave the product in a good place for them to take it and run with (even after we depart).

As such, I spent most of my afternoon setting up our Waterfall strategy. Something that I’m affectionately calling The Exit Plan.

With only 12 weeks until our final day, by the time we take out some time for documentation and knowledge transfer, the rest of the project - at least at a week-to-week level - essentially writes itself.

Is it glamorous work to be once again be in the project management seat, planning out the essential from the dropped?

No, not really. But if this is the thing that stops non-delivery lawsuit, then it’s time well spent.

Additionally, he really does give me a final countdown to focus on.

Older post

2023-12-24

Newer post

2024-01-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.