Why is design blocking our roadmap, and why does it stay blocked?
When a design function becomes unreliable, product and engineering stop waiting for it. They write their own specs and route around the constraint. Those workarounds get encoded into process, and within a few quarters the organization is running on them. By the time leadership intervenes, the problem is operational rather than creative, and unwinding it means changing how leadership, product, design, and engineering work together while delivery continues.
Key facts:
- Broken design rarely remains a design problem. The organization adapts around it, and the workarounds eventually become the operating system.
- The backlog stops reflecting priority and starts reflecting what design could finish. This is usually the first visible symptom.
- Engineering does not stop making interface decisions when design is unavailable. It makes them at build time, without a record.
- Workarounds outlive the problem that created them. They get documented, taught to new hires, and defended by the people they made successful.
- Adding design capacity to a calcified process makes things worse first. The new designer is asked to serve the workaround rather than replace it.
The first symptom: a backlog that reflects feasibility, not priority
Roadmaps are supposed to encode what the business decided matters. When design becomes a constraint, the roadmap quietly starts encoding something else: what could be finished given who was available.
The substitution is difficult to see because nothing announces it. No one proposes deprioritizing the harder work. It simply keeps not being ready, and the sequencing accommodates that, quarter by quarter, until the roadmap is an accurate reflection of design throughput and an inaccurate reflection of company priority.
The tell is in re-sequencing conversations. If work moves because of who is free rather than what it is worth, priority has already been replaced. At that point the roadmap has stopped being a plan and become a forecast.
Engineering does not wait
The more consequential adaptation happens further downstream. Engineering teams have their own commitments, and a blocked dependency does not release them from those commitments. So they proceed.
Proceeding means making interface decisions during the build. Not deliberately, and rarely with any sense of overreach: a state that has no design gets an implementation, an edge case that was never specified gets a default, and a component that does not exist gets improvised from the nearest available one. Each decision is locally reasonable and individually small.
What makes this expensive is that the decisions are unrecorded. A design file has a history; an improvised empty state has none. Six months later nobody can say whether a given behavior was intended, and the cost of changing it is unknown because the reasoning was never written down.
The four common workarounds
In our work, common adaptations include product teams bypassing design, engineers filling product gaps, design joining too late, and leadership adding process to manage the symptoms. They tend to appear in roughly that order.
- Product teams bypassing design. PMs begin producing wireframes and specs to unblock their own work. This is often the point at which the organization stops noticing there is a gap, because something that looks like design output now exists.
- Engineers filling product gaps. Screens and states shipped without design involvement, because waiting was not an option, and components improvised from the nearest available one rather than waiting for the system. Initially framed as temporary. Within a year the product can contain several versions of the same element with no one owning reconciliation.
- Design joining too late. Review still happens, but late enough that changing anything is expensive, so it degrades into approval. The step survives; its function does not.
- Leadership adding process to manage the symptoms. New checkpoints, status reporting and approval gates introduced to control the delay. These address the visibility of the problem rather than its cause, and because they are installed from above they are the hardest of the four to remove later.
Each is a rational local response. Collectively they constitute a second, undocumented operating model running alongside the official one.
Why workarounds calcify
Workarounds do not persist through inertia. Three forces actively preserve them.
They get documented. A temporary practice that survives two quarters gets written into a runbook, because the alternative is explaining it repeatedly. Once written down it is indistinguishable from policy.
They get taught. New engineers and PMs learn the workaround as the way things are done. Within a year a meaningful share of the team has never experienced the original process and has no reason to regard the workaround as one.
They get defended. The workarounds made specific people effective during a difficult period. Those people are frequently now senior. Proposing to remove the adaptation reads as a criticism of how they succeeded, which is a political problem rather than a process one, and it is the reason these changes stall.
This is why the timing of an intervention matters more than its intensity. The same fix costs materially more at eighteen months than at six, and the difference is not technical.
Why adding capacity makes it worse before better
The intuitive response to a design bottleneck is more design capacity. It is not wrong, but on its own and at the wrong moment it reliably disappoints, for a reason that is structural rather than about the individual hired.
A new designer entering a calcified process is asked to serve that process. They receive requests shaped by the workarounds: produce a screen for a flow engineering already built, retrofit a component set to match what teams improvised, review work at a stage where review can no longer change anything. They are measured on responsiveness to a system that is itself the problem.
The predictable outcome is a competent designer producing low-leverage work, followed by the conclusion that the hire was wrong. In practice the sequencing was wrong. The decision path has to be repaired far enough that new capacity is directed at the actual constraint. Distinguishing this from a genuine capability or capacity gap is what the diagnostic is for.
Unwinding without stalling delivery
Workarounds cannot all be removed at once, because the organization is currently running on them. Removing them simultaneously stops delivery, which is the thing the intervention was supposed to protect.
A workable order:
- Restore the decision path first. Establish who decides and at what point the decision is binding. Nothing else holds while this is unresolved.
- Move design review earlier rather than making it stricter. Review that can still change something is worth a fraction of the effort of review that cannot.
- Adopt the best of the improvised component sets rather than replacing all of them. Teams built these because they needed them; one is usually close to right, and adopting it converts a workaround into the standard at almost no cost.
- Retire engineering-authored interfaces last, and selectively. Many are fine. The ones worth revisiting are those where the improvised behavior is now load-bearing and nobody can explain it.
- Leave the PM-drawn specs until the decision path holds. They are a symptom of the gap and will recede on their own once briefs arrive with direction attached.
Why this is more than a handoff problem
Design-to-engineering handoff is where this pattern is most visible, so it attracts most of the remediation effort. Improving handoff is worth doing, and specification quality, shared component libraries, and design-system investment all address real costs.
They are also the narrowest available reading of the problem. Handoff is one transition in a chain that starts with how priorities are set and who is allowed to settle a question. A team can have an excellent design system, a well-documented handoff, and a roadmap that still reflects feasibility rather than priority, because the constraint was never at the handoff. Design systems in particular are frequently proposed as the remedy for a decision-path failure, which is why so many are built and then not adopted: the system is not the thing that was missing.
Changing the pattern durably means working at all four levels at once — leadership, where priorities and authority are set; product, where briefs are written; design, where the work is done; and engineering, where it becomes real. That is an operating-process change rather than a documentation exercise, and it is the reason these engagements are measured in quarters.
Throughout, committed backlog work continues shipping. An intervention that pauses delivery to fix process is generally rejected by the organization within a quarter, whatever its merits, because the commitments that created the pressure are still outstanding.
Frequently Asked Questions
How do we know whether we have workarounds or just a normal process?
Ask when each practice started and why. A process step with an origin story that begins "we were waiting on design, so" is a workaround, however well it currently functions. Steps that were designed have a rationale; steps that accreted have a history.
Is it a problem if engineering makes interface decisions?
Not inherently, and in strong teams it is often good. It becomes a problem when the decisions are unrecorded and unreviewed, because the product then accumulates behavior nobody can explain or safely change. The distinction is not who decides but whether the decision leaves a trace.
What if the workarounds are working?
Some are, and those should be adopted as the standard rather than removed. The ones worth unwinding are those with a cost that shows up somewhere other than where the workaround lives: a reconciliation burden on a future team, a decision path that produces rework, behavior that cannot be modified because its reasoning is lost.
We are shipping fine. Is this still relevant?
Shipping volume is a poor indicator here, because workarounds are specifically designed to preserve it. The signals worth checking are whether the roadmap still reflects priority, whether interface decisions are recorded anywhere, and how many versions of common components exist in the product.
How long does unwinding take?
It depends on how long the adaptations have been in place and how senior their defenders are, which is why elapsed time matters more than team size. Engagements addressing this pattern have run six to eighteen months, though that is an observation about past work rather than an estimate for any particular situation.
Who should own the unwinding?
Someone with standing to change how decisions are made, which is usually a design leader rather than a project. Where the role is unfilled or the existing team is fully committed to delivery, this is the situation interim design leadership is for: senior direction and hands-on execution together, so the operating process changes while committed work keeps shipping.