Revised rules of engineering leadership. | Irrational Exuberance<br>From early 2014 through late 2020, I was working in hypergrowth environments,<br>which are challenging, but also educational. The most valuable feature of hypergrowth is that<br>your mistakes reveal themselves next month rather than next year, because things go wrong very loudly when you’re moving fast.<br>I’ve been thinking a lot about hypergrowth recently, because Imprint’s business is growing quickly and we did a large batch<br>of hiring last year, but also because the AI-tooling shift has changed the pace at which it’s possible to work.<br>This post documents the new rules I’ve revised my approach to engineering leadership around,<br>and then talks through the specific projects I’ve worked on over the past year that caused<br>me to believe in these rules.<br>Revised rules<br>Migrations can be done by an individual rather than a team.<br>Even complex, large changes can be 95% owned by the driving individual or team, and done in 10% of the time.<br>As the initial cost of migrations goes down, the reward/penalty of each migration’s quality goes up:<br>even small sharp edges will break your colleagues’ mental models about the software you co-maintain.<br>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.<br>We’re in an era when many companies say that everyone should be writing code, however our experience<br>is that writing code that works well, while avoiding messy edgecases, remains difficult.<br>Just how difficult remains a factor of your development harness, e.g. your tests, CI/CD,<br>validation environments, preview-ability of changes, and so on.<br>While I personally don’t imagine it’s valuable for most folks at a company to be contributing code,<br>I suspect that most disagreement about that topic is actually a miscommunication:<br>even at a company where “everyone codes”, the marketing team isn’t reducing allocations in your servers,<br>instead it’s about whether there is a safe boundary where they can participate.<br>(Much like a SaaS product that allows customization by writing software.)<br>The good news is that this means the things that were most valuable to speed up engineering two years ago<br>are still the things that are most valuable to speed them up today.
Optimize the base-case of process for agents.<br>Most steps of most processes can be fully automated in most cases.<br>With the right harnesses, the right controls, domain context, and good judgment in their designers,<br>you can fully automate the base-case of most processes<br>in modern technology companies. For example, the base case of code review from a human<br>is slower and less effective than a good harness’ code review.<br>Of course, the harness will miss things, but so will human reviewers, and most areas<br>are relatively safe to make changes. Of course, there are some higher risk areas, where<br>this doesn’t hold true.<br>By effectively capturing these distinctions properly, we can go much faster without<br>introducing risk. By failing to capture these distinctions, we’ll create innumerable problems<br>for ourselves.<br>As a corollary, I think most planning processes like weekly or bi-weekly sprints are operating at<br>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.<br>One of my biggest lessons at Uber was that persistent, durable teams work magic<br>by accumulating domain-context, building a sense of camaraderie, and feeling an increasingly strong sense<br>of ownership over an area as they continue to work in it.<br>Even in an era where specifically doing something is much cheaper, you still have to do the right thing,<br>which has gotten a bit easier but not much easier, and structural improvements help address this.<br>(As a recent example of that, we had an issue in production where the necessary data to optimize it simply wasn’t being<br>captured at all, so the harness’ ideas to solve it were reasonable but wrong, since the only real path forward was<br>instrumenting the missing information.)<br>As a specific disagreement, there’s a prevailing idea that AI-first companies will be run by a small number of<br>genius engineers who create perfect versions of things one by one, doing such a good job that there’s nothing<br>to maintain. This is a very compelling vision, but I don’t see it happening. High judgment individuals can<br>wander across a company doing remarkable things, but at some point they do get hemmed in by lack of domain context,<br>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.<br>Being able to replace a legal review with automation only works if Legal can commit to...