For most of my career, I've worked closely with engineers. Embedded in teams, collaborating across functions, shipping software together. I thought I understood how engineering worked because I was always near it. Over the last year or so, I got closer. I started spending real time inside codebasesThe complete collection of source code used to build a software application., frameworksPre-built code structures that provide a foundation for developing software., and the tooling that actually holds software together—not as an engineer by training, but close enough to feel the difference.
Getting closer exposed a truth I suppose I had always known. Engineering operates with a deep, almost default commitment to abstraction and sharing. Engineers are constantly looking for ways to reduce future effort: factoring out common logic, naming patterns, building librariesReusable collections of code that developers can import to add functionality., and leaving behind structures that make the next piece of work easier.
Design, even when it's thoughtful and rigorous, often treats each problem as newly situated. Work is framed as too contextual, too human, or too specific to stabilise. As a result, progress tends to live in people and teams, not in systems.
Design is usually described as the more reflective, human-centred discipline. You'd expect it to be better at learning from itself. And yet, structurally, it struggles to do so. Design has precious few on-the-ground tactics for compounding decisions as it moves. We have a few bigger concepts and methodology books to lean on—double diamond, design sprints—nothing compared to the sea of often grass-roots level progress found in engineering.
In engineering circles recently, Dan Shipper put language to an idea many engineers already recognise: compounding work. The idea is simple. Each unit of effort should make the next one easier, not harder. Codebases, tools, conventions, and decisions are structured so that value accrues over time.
What matters here isn't the term or the tooling. It's the mindset: work is not just about shipping outcomes, but about improving the system that produces those outcomes. Seen through that lens, the contrast with design becomes clearer. Design work is often excellent in the moment, but fragile across time. Insights live in people. Decisions live in meetings. Rationale lives in slide decks that quickly lose their audience. When teams change or projects end, much of that value quietly evaporates. The result is not a lack of creativity, but a lack of continuity.
Nowhere is this difference more visible than in the open-sourceSoftware whose source code is publicly available for anyone to use or modify. software community. Engineering has spent decades figuring out how to coordinate large, distributed groups of people who may never meet. Through platforms like GitHubA platform where developers store, share, and collaborate on code., strangers contribute to shared systems, incrementally improving them, argue in public, forkCreating your own copy of a code repository to modify independently. when they disagree, and leave behind a visible history of how things evolved. Projects like LinuxAn open-source operating system built collaboratively by thousands of developers. exist not because everyone agrees, but because the work is legible, modular, and cumulative.
Design is also collaborative, but in a very different way. Design collaboration tends to be local, synchronous, and relationship-driven. Workshops, crits, stand-ups, and working sessions are where meaning is made. That human situated work is one of design's great strengths. But it also means that progress is tightly bound to specific teams and individuals.
Across the discipline, knowledge tends to travel through people rather than through systems. When it scales, it does so through books, talks, frameworks, and prominent individuals. These can be insightful and influential, but they are also brittle. They freeze ideas in time and centre progress on authorship rather than accumulation.
Engineering is not immune to that thinking, but generally, the physiology is not to wait for a single person to articulate the next big idea. There is a preference towards building infrastructure that allows many people to make small, durable contributions.
What makes this more interesting is that design already has a partial counter-example: design systems. If there is one area of design that clearly can compound, it's here. Design systems already demonstrate shared vocabulary, reusable abstractions, reduced marginal cost of change, and partial independence from individuals.
And yet, most design systems stall surprisingly early. In practice, they tend to concentrate on:
- Colour tokensNamed variables storing design values like colours or spacing.
- Spacing scales
- Buttons, inputs and the rest of the basic components
All useful, all foundational. The bedrock. What rarely compounds are the more consequential layers:
- Larger interaction patterns
- Multi-step flows
- Behavioural logic
- System-level constraints
- Decision rationale
In other words, the parts of design that actually carry meaning.
Even teams with mature systems often find themselves returning to first principles when working on flows or complex behaviours, rebuilding logic that already exists elsewhere. This happens so consistently that it's treated as inevitable. Tooling reinforces this assumption. Figma has made atomic componentisationBreaking interfaces into reusable building blocks. straightforward, but offers far less support once you move beyond components into behaviour across time. Over time, a belief hardens: anything beyond components is too contextual to stabilise. The result is a strange loop. Design assumes its work doesn't travel, so it never builds the structures that would allow it to.
Engineers can pull mature, iterated code packages into their work—pieces of functionality that can represent years of shared learning. They don't just save time; they carry decisions, trade-offs, and assumptions forward, all captured in GitA version control system that tracks every change to code.. If I want to solve a familiar problem, I don't start at bedrock. I import something that already embodies collective progress.
In design, if I want a qualitative research framework, a futures workshop structure, or a synthesis method, I usually start from a method someone once shared online or in a book. It's unversioned, stripped of context, disconnected from any wider history of improvement. I might tweak it, maybe improve it, but that improvement rarely travels beyond the team I'm on.
It's tempting to explain this away with practical reasons. Design work is messy. Context matters. Facilitation relies on judgement. Outcomes are hard to measure. All of that is true. But it's no longer sufficient. We now live in a world where memory is cheap, where context can be summarised, where decisions can be captured, and where knowledge can be scaffolded rather than flattened. The technical barriers that once made this unrealistic have largely fallen away.
What remains looks less like a tooling problem and more like a psychological one.
Design still treats much of its knowledge as inherently personal, situational, and non-transferable. Methods are seen as craft objects rather than shared infrastructure. Improvement is something individuals accumulate, not something the discipline compounds. We assume that if something travels too far, it must lose its humanity. And so we don't build the structures that would allow it to travel well.
Design culture has good reasons for resisting formalisation. Much of its value lies in judgement, empathy, cultural sensitivity, and working closely with real people in specific contexts. Not everything in design should scale, and not everything should be abstracted.
The problem is that design often treats all of its work as if it's too bound up in context to carry forward. The cost of that stance is easy to miss because it's distributed:
- Teams rediscover the same problems
- Decisions are revisited without awareness of why they were made
- Lessons are learned locally but rarely compound globally
- Progress depends on who is in the room, not what the system knows
This doesn't preserve humanity. It creates organisational amnesia.
Engineering learned long ago that abstraction is not the opposite of care. In many cases, it is an expression of it. Encoding hard-won lessons into systems protects future users and teams from repeating mistakes. It preserves intent beyond individual memory. Design has only taken that idea part of the way.
Until recently, there were practical excuses for this. Capturing rationale was expensive. Translating context was hard. Making work legible to outsiders took time most teams didn't have. Those excuses are weaker now.
Artificial Intelligence, mostly in the form of LLMsLarge Language Models—AI that can generate and analyse text., has changed the economics of memory, translation, and scaffolding. It is suddenly cheap to summarise decisions, surface precedents, translate between contexts, and help newcomers orient themselves. Engineering is already exploiting this to build systems that quite literally improve themselves. Design has access to the same tools, but far fewer shared conventions for using them.
Design discourse often frames this as a binary choice. On one side: humanity, creativity, small groups, trust, and care. On the other: abstraction, scale, systems, and formality. But engineering didn't scale everything. It scaled the parts that benefited from it, while leaving judgement, debate, and creativity intact.
The more useful question for design is not whether it should become more like engineering, but where abstraction actually helps. What aspects of design work truly depend on being local and embodied? And what aspects are merely undocumented?
Design systems hint at an answer. They show that design can compound, but also how cautiously it does so. Components are allowed to stabilise; flows and behaviours are treated as permanently provisional. That distinction may be the next frontier.
A compounding design discipline wouldn't try to automate taste or standardise empathy. It would focus on the less visible, but deeply consequential parts of the work:
- Making decisions inspectable, not just outcomes
- Capturing trade-offs, constraints, and rejected paths
- Allowing small contributions to improve shared patterns
- Ensuring progress survives team changes and time
None of this diminishes individual designers. It respects them enough to ask a more complex question: what remains useful when the people who made the decisions move on?
Engineering learned how to coordinate strangers. Design already knows how to work with humans. The open question is whether it can learn to do both at once.
Perhaps the future of design lies not in choosing between humanity and scale, but in being more deliberate about where each belongs. Keeping judgement, care, and collaboration grounded in small groups, while allowing knowledge, decisions, and lessons to compound beyond them.
That feels less like a manifesto and more like unfinished work.