Creating a centralized UX <> Engineering team
Restructuring a fragmented product organization through centralized design leadership: four value streams reorganised into one hub.
- Sr. Director of Product Design, ORFIUM
- 2016 to 2024
The hardest design problems are not on screen. They are organizational.
CODA is an organizational-design initiative, not a product. As Senior Director of Product Design at ORFIUM, I restructured the product organization by creating a centralized design operations and alignment model that brought product designers, front-end engineers, and the design system team under one leadership. This is the story of why the old model failed, how CODA replaced it, and what it changed.
- 4 to 1
- 8
- 6
- 6
Co-led with the Head of Front-End.
The original structure
ORFIUM ran on a distributed, value-stream model. Four independent streams, each with its own embedded product, design, and engineering people.
Autonomy came at a cost. Each stream became a self-contained unit, and design practice siloed. Every stream grew its own patterns, conventions, and definition of quality. Duplicated components, inconsistent interactions, and a design system that existed in theory but was adopted unevenly. The model worked when the company was small, then the cracks showed as the product surface and the teams grew.
The breaking point
A company-wide restructuring collapsed the four streams into fewer, broader teams, and the alignment between design, product, and engineering shattered.
Designers were reassigned, reporting lines changed, context fragmented. Shaped work entered build cycles with ambiguous scope and unresolved dependencies. Designers produced specs engineering could not execute, not from a skill gap, but because there was no shared meaning of "ready for development". Handoff quality depended on which designer you happened to work with. The design system team built components nobody adopted, because it had no seat at the product table.
The problem was not individual performance. It was structural.
Designing a new model: CODA
Instead of every product owning its own designer and front-end engineer, I proposed one centralized, shared team that could support every stream dynamically. That team became CODA.
CODA allocated support based on actual priorities, company objectives, and the shaping pipeline, not a fixed headcount split. It was four product designers and four front-end engineers, co-led with the Head of Front-End. The design system team merged in too, forming a hybrid federated model: ownership stayed central, but contributions could come from anywhere.
The design system inside CODA
Merging the design system into CODA solved several problems at once. The system team was no longer isolated or under-resourced. Designers and engineers could rotate between system and product work, which prevented stagnation. The system finally reflected real product needs instead of hypothetical improvements, and quality rose because contributions came from many contexts.
Operating inside Shape Up
ORFIUM used a customized version of Basecamp's Shape Up: six weeks of focused work followed by a one-week cooldown.
The embedded model was meant to align with this rhythm. Designers shaped work, engineers picked it up the next cycle, the system moved predictably. Once resources shrank, it broke. Work was not ready at the start of cycles, multiple teams blocked at once, and shaping outran the capacity to support it. CODA was the way to re-synchronise the organization with the Shape Up cadence.
New ceremonies
To keep CODA aligned internally and with the wider org, six ceremonies were introduced, each mapped to a point in the Shape Up cycle.
| Ceremony | Cadence | Purpose |
|---|---|---|
| CODA Standups | Daily, 15 min | Surface blockers, share progress, coordinate across active projects |
| Design and FE Pairing | Weeks 2 and 4 | Structured designer and engineer collaboration so design intent translates accurately |
| Mid-Cycle Shaping | Week 3 | Ensure upcoming work is well defined, shaping runs in parallel with the build |
| Readiness Review | Week 6 | Evaluate every deliverable against the definition of "ready for development" |
| Cooldown Planning | Cooldown week | Prioritise system work, shaping, process improvements, and tech debt |
| Design System Review | Recurring | Review contributions, component health, and adoption |
Measurable impact
CODA's success was tracked through six indicators spanning operational health and team effectiveness. All six moved in the right direction.
Cycle readiness improved
Shaped work entered cycles with clearer scope and fewer unknowns, reducing mid-cycle disruption.
Resource utilization stabilized
Centralized allocation removed idle capacity and the chronic over-commitment of the old model.
Rollovers decreased
Fewer projects carried into the next cycle, a sign of better scoping and more realistic commitments.
Cross-team alignment improved
Shared ceremonies and one leadership structure cut miscommunication and conflicting priorities.
Design system activity increased
Contributions grew once the team was in the product cycle, and component adoption rose.
Employee engagement rose
Satisfaction improved as people gained clarity on their roles, impact, and growth.
Reflection
The user was the team itself.
Restructuring a fragmented org took the same skills I use in product design: deep research, ruthless prioritisation, clear communication, and iterative validation. The most important lesson was that organizational design is never done. CODA was not a one-time fix, it was a living system that needed continuous shaping, just like the products it supported.
CODA is part of my work at ORFIUM, alongside the Ictinus design system and the ORFIUM platform.