Addition

How rules accumulate, and why no one ever subtracts
Addition

No startup begins life with a thousand-page HR policy.

In the beginning, there is no HR. No compliance team. No handbook. Policy can be summarized as:

don’t be a dick

And for a while, the “don’t be a dick” rule works.

Until one day, someone is an asshole.

Strictly speaking, being an asshole isn’t explicitly covered by the “don’t be a dick” rule. So now we need a “don’t be an asshole” rule as well.

Then there’s that incident.
We realize suddenly that being creepy isn’t technically covered by the aforementioned dick or asshole rules.

So we add another one.
Did we need a creep rule? No… not until the exact moment we wished we had one.

And so it goes on.

Every rule, in isolation, makes total sense.
None of them added maliciously.
Each one a rational response to a real mistake, made by a real person, at a real moment in time.

It’s only in the aggregate that we start to suffer.

Take a local university, for instance.
Faculty are required to buy their own office furniture. Fine.
But there’s also an explicit carve-out: professors cannot have a sofa in their office.

There’s only one reason a rule like that exists, and it wasn’t the sofa’s fault.

Whatever happened should have been covered by our general “don’t be creepy” principle, not encoded into furniture policy.

The rule was added with student safety in mind.
The downstream consequences, never considered.

This is exactly how it works in tech and Big Corporate.

Every time I go before a change release committee - seeking sign-off from solution architects, the network team, the firewall team, and a dozen others…
I know that none of them are acting in bad faith.
They’re all just trying to do their jobs.
They’re all white-knuckling it, whispering to themselves, “please not this week.”
Trying to protect their teams from shrapnel when something explodes.

But in the aggregate…

Now I have seventeen committees.
Each with bespoke concerns.
Each with comments to address.
Each a carried scar.

It’s easy to add.
More rules, more guardrails… feels like safety.
Nobody wants more risk.

No one ever subtracts.
Subtracting requires understanding the system holistically.
Subtracting accepts responsibility for an uncertain future.

Multiply these micro-decisions across an organization of thousands, or decades of history, and it’s a miracle that anything ever gets done.

Maybe this is why consultants exist.
A parallel lane outside the normal channels.
Change at arm’s length.
Not because it’s better - but because someone, temporary and expendable, is willing to hold the risk.

But consultants still require a champion.
Someone who understands the system.
Someone to navigate the storm.
Someone willing to push for better.

Change will come.
Not cleanly. Not safely.
But because, eventually, someone chooses yes.

Sometimes, that someone is an asshole like me.

2025 review - health & fitness
The Paradox of Control

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.