Revised rules of engineering leadership.
From early 2014 through late 2020, I was working in hypergrowth environments,
which are challenging, but also educational. The most valuable feature of hypergrowth is that
your mistakes reveal themselves next month rather than next year, because things go wrong very loudly when you’re moving fast.
I’ve been thinking a lot about hypergrowth recently, because Imprint’s business is growing quickly and we did a large batch
of hiring last year, but also because the AI-tooling shift has changed the pace at which it’s possible to work.
This post documents the new rules I’ve revised my approach to engineering leadership around,
and then talks through the specific projects I’ve worked on over the past year that caused
me to believe in these rules.
Migrations can be done by an individual rather than a team.
Even complex, large changes can be 95% owned by the driving individual or team, and done in 10% of the time.
As the initial cost of migrations goes down, the reward/penalty of each migration’s quality goes up:
even small sharp edges will break your colleagues’ mental models about the software you co-maintain.
The impact of individual judgment on your company has never been higher.
While 1st-pass code is nearly free, the cost of working code depends on your development harness, and is not free.
We’re in an era when many companies say that everyone should be writing code, however our experience
is that writing code that works well, while avoiding messy edgecases, remains difficult.
Just how difficult remains a factor of your development harness, e.g. your tests, CI/CD,
validation environments, preview-ability of changes, and so on.
While I personally don’t imagine it’s valuable for most folks at a company to be contributing code,
I suspect that most disagreement about that topic is actually a miscommunication:
even at a company where “everyone codes”, the marketing team isn’t reducing allocations in your servers,
instead it’s about whether there is a safe boundary where they can participate.
(Much like a SaaS product that allows customization by writing software.)
The good news is that this means the things that were most valuable to speed up engineering two years ago
are still the things that are most valuable to speed them up today.
Optimize the base-case of process for agents.
Most steps of most processes can be fully automated in most cases.
With the right harnesses, the right controls, domain context, and good judgment in their designers,
you can fully automate the base-case of most processes
in modern technology companies. For example, the base case of code review from a human
is slower and less effective than a good harness’ code review.
Of course, the harness will miss things, but so will human reviewers, and most areas
are relatively safe to make changes. Of course, there are some higher risk areas, where
this doesn’t hold true.
By effectively capturing these distinctions properly, we can go much faster without
introducing risk. By failing to capture these distinctions, we’ll create innumerable problems
for ourselves.
As a corollary, I think most planning processes like weekly or bi-weekly sprints are operating at
too low an altitude. Humans planning together still matters, but should be operating at a higher level.
Durable, high-ownership teams with domain-context are even more important.
One of my biggest lessons at Uber was that persistent, durable teams work magic
by accumulating domain-context, building a sense of camaraderie, and feeling an increasingly strong sense
of ownership over an area as they continue to work in it.
Even in an era where specifically doing something is much cheaper, you still have to do the right thing,
which has gotten a bit easier but not much easier, and structural improvements help address this.
(As a recent example of that, we had an issue in production where the necessary data to optimize it simply wasn’t being
captured at all, so the harness’ ideas to solve it were reasonable but wrong, since the only real path forward was
instrumenting the missing information.)
As a specific disagreement, there’s a prevailing idea that AI-first companies will be run by a small number of
genius engineers who create perfect versions of things one by one, doing such a good job that there’s nothing
to maintain. This is a very compelling vision, but I don’t see it happening. High judgment individuals can
wander across a company doing remarkable things, but at some point they do get hemmed in by lack of domain context,
which is why durable teams are the fundamental building block, even in this era.
Quick, good, and durable decision-making is a prerequisite to meaningfully benefit from AI.
Being able to replace a legal review with automation only works if Legal can commit to that change,
which depends on designing the automation thoughtfully, and also the teams’ willingness to collaborate.
Implementing a new feature is only valuable if you can decide to launch that feature.
Your team and company can only benefit from this increased pace of execution if you can make durable decisions
quickly, and those decisions are good. This is the primary reason, in my opinion, why the average CTO role has
necessarily become substantially more technical and less bureaucratic than a year ago.
In many cases, I am the only person who can make binding decisions when teams disagree on the path forward,
and that means I am making decisions constantly in this new world in order to maintain the pace.
(That’s not an argument that executives are better decision makers, just that binding executive decisions
are uniquely powerful to the extent that the executives themselves are aligned enough to honor those decisions.)
So, I genuinely believe the above rules based on my experiences over the past year, and let me try to
connect them to specific projects we’ve worked on that have convinced me of them:
These are just representative examples, we’ve done a lot more than these. The aperture of what’s possible has continued
to expand every month this year, but the things holding us back haven’t changed all that much: organizational misalignment,
lack of clarity, and poor technical architecture.
It’s a wild time to be working in technology.
