Build to Outlive

Working Backwards From Legacy

In 2025, I started thinking about "build to outlive" as something bigger than code quality.

Its architecture, yes - but also processes, operating habits, documentation, onboarding, decision-making norms, and the culture that silently shapes how things get built. My legacy as an engineering leader is not whether I shipped a big thing. Its whether what I built keeps working, keeps evolving, and keeps compounding after I am no longer in the room.

Earlier in my journey, I optimized for speed because the business needed speed. That pressure is real. But I have learned (sometimes the hard way) that urgency often hides a cost: the cleanup you promise you will do later rarely arrives. The interest shows up months later as fragility, slower delivery, and teams that spend more time coordinating and firefighting than building.¹²

The Trap of "Ship Crazy" and Team Bloat

One trap I have fallen into as a manager is equating impact with sprawl.

If my team "owned" more services, it looked like more influence. But in practice, it often meant something else: we needed more headcount just to keep the surface area afloat. More systems led to more on-call load, more context fragmentation, more dependencies - and eventually more people overhead just to keep the machine running.

And here is the part that matters: scaling people did not automatically fix the underlying problems. Sometimes it only diluted ownership further, until decision-making required a central orchestrator - someone who held the whole map in their head because no one else could.¹

What I have seen work better - consistently - is smaller teams with deeper ownership. Lean teams tend to understand the "why" behind what they are building. They ship with more conviction because they can feel the end-to-end impact. A small team with a strong culture can outperform a big team with a weaker one.³

The trade-off is real: this can slow down the first version. Wider ownership per person means more learning, more ramp-up, and more time spent building understanding. But in the long run, speed improves when more people actually understand the system and can make decisions without routing everything through one or two people.⁴

Move Fast, Break Things... But Build to Last

I have also had to evolve my relationship with "move fast."

Early in my career, speed often meant: ship now, refactor later. And I do not think that is always wrong. But I do think "later" is one of the most expensive words in engineering. The tidy-up rarely happens, and the next sprint arrives with new priorities. What is left behind is debt that keeps charging interest.⁵⁶

These days, a more accurate mantra in my head is:

Move fast, break things - but build robust.

Facebook went through a similar evolution, explicitly shifting the motto from "move fast and break things" to "move fast with stable infrastructure." ⁷⁸ I take that as a useful reminder: speed is not just about shipping; it is also about how quickly you can catch issues, recover, and keep moving without accumulating chaos.

One thing that sharpened this for me is the incentive gradient around demos. Demo-driven planning can be a useful lightweight structure.⁹ But I have seen teams (including mine) drift into optimizing for the demo itself: shipping something that looks good in a review while quietly taking on unspoken tech debt and fragility to get there. That is not malicious - its incentives - but the long-term outcome is predictable.

This is where I started separating conscious vs unconscious tech debt.

• Conscious debt: I know the shortcut I am taking, I can articulate why, and I have a plan to revisit it.
• Unconscious debt: we ship fragility by accident, and then normalize it until it becomes "how the system works."

This distinction maps closely to how many tech debt frameworks describe debt as deliberate vs inadvertent (or intentional vs unintentional). The point is not to eliminate debt. The point is to choose it deliberately, document it, and manage it before it becomes permanent constraints no one chose.⁵¹⁰

Designing for the Long Run: What I Actually Do Now

The "build to outlive" mindset is not just philosophy - it changes how I design.

One pattern I like: start simple, but design for evolution. I try to keep the codebase modular from the beginning (clear boundaries, clean interfaces), so we can split components out later if scale or org boundaries truly demand it.

I also try to keep myself honest here. Akin's Laws has two reminders I keep close: improvements beyond requirements are wasted effort, and better is the enemy of good. Longevity is not gold-plating. I aim for the smallest design that meets today's needs, with seams that let us strengthen it later.

I am not the first person to say this. The "monolith first" argument is basically: do not start with distributed complexity unless you have to - build something modular, learn your domain, and then break it apart when you actually know where the boundaries should be.¹¹¹²

I also find myself evaluating engineers (and system proposals) differently.

I care less about big claims and more about trade-off clarity:

• latency vs reliability
• abstraction vs speed
• coupling vs time-to-market

In 2025 - especially with AI hype everywhere - it is very easy to overstate impact. The best filter I have found is whether someone can explain what they gave up to get what they got. If you cannot name the trade-offs, you probably did not understand the system deeply enough (or you were not close enough to the decisions that mattered).

Within my teams, I try to make shortcuts explicit and governed:

• document the shortcut
• assign an owner
• write down the conditions under which we will revisit it
• keep it visible so it does not silently calcify⁵¹⁰

One Pack of Pirates

When I think about my ideal team shape, I keep coming back to a phrase: one pack of pirates.

Not in the "chaos" sense - in the values sense: high trust, direct communication, psychological safety, and shared principles. A lean group (say around 20) that is empowered to build what is needed with minimal ceremony, but with strong ownership and standards.

I have seen versions of this work in practice. When the team has trust and safety, people propose bold ideas and take responsibility for outcomes.³ When the team has an identity and pride, it creates a virtuous cycle of motivation and quality.³ And when learning is a lifestyle, the team stays adaptable as the tech and the business shift.³

The biggest advantage is cultural: the team understands the system deeply, owns it end-to-end, and builds with an implicit assumption that they will live with the consequences.

That loops back to the core takeaway I want to carry forward:

If I want my work to outlive me, I cannot optimize for busyness or sprawl. I have to optimize for:

• lean teams
• long-lived systems
• explicit trade-offs
• conscious shortcuts
• ownership that survives org changes⁴³¹