Source
Lenny's Podcast: Product | Career | Growth — OpenAI’s Head of Design: This is the best time in history to be a designer | Ian Silber (August 16, 2026) ·
at 30:20 ▸
When this applies
when the rate of execution in one function vastly outpaces the rate another function can individually review/design for, creating a bottleneck
The takeaway
When one function can't keep pace with another's throughput, invest in reusable infrastructure/primitives for the slower function rather than trying to scale its headcount or speed linearly.
Why it works
Building composable primitives/building blocks lets many individual outputs inherit good design automatically, instead of requiring bespoke design attention on every new feature — trading one-time systems investment for ongoing per-feature cost.
One level up
Bottlenecks in a system are best resolved by changing the unit of work (from bespoke outputs to composable building blocks), not by trying to brute-force throughput.
Where it stops holding
This stops working when the features genuinely need bespoke, non-composable treatment because they serve fundamentally different user needs that a shared system would poorly serve.
Detail
rule: Default to 'don't design it if you don't have to' — check if an existing system/component/feature extension already covers the need.
threshold: Applied when engineers are 'shipping 5,000 PRs a day' and design can't review each individually.
rationale: Systems thinking and composability let design scale impact without scaling headcount at the same rate as engineering output.
In their words
We've had these conversations where I'm like, just do less. Like, my encouragement has been do less. Like, don't design it if you don't have to.