Building CODA
Restructuring a fragmented product organization through centralized design leadership, bringing structure, clarity, and predictability to cross-team collaboration.
CODA is not a product; it's an organizational design initiative. As Senior Director of Product Design at Orfium, I restructured the product organization by creating a centralized design operations and alignment model that brought together product designers, front-end engineers, and the design system team under unified leadership.
This case study tells the story of why the existing model failed, how CODA was designed to replace it, and the measurable impact it delivered across the organization. It's a story about people, processes, and the structural decisions that make or break a product team.
The Original Structure
Orfium operated under a distributed, value-stream-driven model. Four independent value streams each had their own embedded product, design, and engineering teams. This structure gave teams autonomy, but as the company scaled, coordination across streams broke down.
Each value stream functioned as a self-contained unit. Designers were embedded directly within product squads, giving them deep domain expertise, but at a cost. Design practice became siloed, with each stream developing its own patterns, conventions, and definitions of quality.
A company-wide restructuring then collapsed these four streams into fewer, broader teams. Designers were reassigned, reporting lines changed, and the tight alignment between design, product, and engineering shattered. Knowledge was lost, context fragmented, priorities shifted faster than teams could adapt.
This model worked when Orfium was smaller. But as the product surface expanded and teams grew, the cracks became visible: duplicated components, inconsistent interaction patterns, and a design system that existed in theory but was adopted unevenly across streams.
The Breaking Point
Delivery timelines slipped as shaped work entered build cycles with ambiguous scope and unresolved dependencies. Designers were producing specs that engineering couldn't execute, not because of skill gaps, but because there was no shared understanding of what "ready for development" meant.
Design output varied wildly between streams. One team's button component looked nothing like another's. Handoff quality depended on which designer you worked with, not on any organizational standard. Meanwhile, the design system team operated in isolation, building components nobody adopted because they had no seat at the product table. The problem wasn't individual performance. It was structural.
Designing a New Model: CODA
To solve the resourcing crisis, I proposed the creation of a centralized, shared team that could support all value streams dynamically. This team became known as CODA.
Instead of every product having its own designer and front-end engineer, CODA became a unified team that provided support based on actual priorities, company-wide objectives and the shaping pipeline rather than headcount distribution.
CODA consisted of four product designers and four front-end engineers. I co-led the team together with the Head of Front-End. The design system team was merged into CODA as well, forming a hybrid federated model in which ownership remained central, but contributions could come from anywhere in the organization.
"This structure preserved autonomy where it mattered and created central alignment where it was essential."
The Role of the Design System Inside CODA
Merging the design system team into CODA solved multiple problems at once.
The DS team was no longer isolated or under-resourced. CODA designers and FE engineers could rotate between DS and product initiatives, preventing stagnation. Design system work finally reflected real product needs instead of hypothetical improvements. And DS quality increased because contributions came from multiple contexts.
"This hybrid federated model meant that CODA provided governance and consistency while product designers across streams provided input and occasional contributions."
Operating Inside Shape Up
ORFIUM used a customized version of Basecamp's Shape Up framework. Each delivery cycle included six weeks of focused product work followed by one week of cooldown.
The embedded model was originally intended to align perfectly with these cycles: designers shaped work, engineers picked it up the next cycle and the system moved predictably.
Once resources shrank, this process broke down.
Design and FE work was no longer ready for engineering at the start of each cycle. Multiple teams were blocked simultaneously. Shaping work was created faster than we could support it.
CODA offered a way to re-synchronize the organization with Shape Up's rhythm.
To achieve this, I needed to create a new operational cadence for CODA in sync with the broader product cycles.
New Ceremonies
To keep CODA aligned internally and with the broader organization, six key ceremonies were introduced, each mapped to specific points within the Shape Up cycle.
Daily 15-min sync to surface blockers, share progress, and coordinate across active projects. Keeps the entire team aligned without lengthy meetings.
Structured collaboration sessions between designers and front-end engineers. Ensures design intent translates accurately into implementation.
Second pairing session at the cycle's midpoint. Catches implementation drift early and resolves design-engineering gaps before they compound.
Checkpoint to ensure upcoming work is well-defined before the next cycle begins. Shaping runs in parallel with the build to maintain pipeline velocity.
End-of-cycle evaluation against the definition of "ready for development." Ensures every deliverable meets quality and completeness standards before handoff.
Prioritization of cooldown tasks including DS work, shaping, process improvements, and tech debt. Sets the agenda for the recovery week.
Recurring review of DS contributions, component health, and adoption metrics. Keeps the design system aligned with product needs and growing sustainably.
- CODA Standups; Daily sync to surface blockers and coordinate across active projects
- Design & FE Pairing; Structured collaboration sessions between designers and front-end engineers (Weeks 2 & 4)
- Mid-Cycle Shaping; Checkpoint to ensure upcoming work is well-defined before the next cycle begins (Week 3)
- Readiness Review; End-of-cycle evaluation against the definition of "ready for development" (Week 6)
- Cooldown Planning; Prioritization of cooldown tasks including DS work, shaping, and process improvements
- Design System Review; Recurring review of DS contributions, component health, and adoption metrics
Measurable Impact
CODA's success was tracked through six key performance indicators spanning operational health and team effectiveness.
Cycle Readiness Improved
Shaped work entered cycles with clearer scope and fewer unknowns, reducing mid-cycle disruptions.
Resource Utilization Stabilized
Centralized allocation eliminated idle capacity and reduced the over-commitment that plagued the previous model.
Rollovers Decreased
Fewer projects carried over into the next cycle, indicating better scoping and more realistic commitments.
Cross-Team Alignment Improved
Shared ceremonies and a single leadership structure reduced miscommunication and conflicting priorities.
Design System Activity Increased
DS contributions grew as the team was integrated into product cycles, resulting in higher component adoption.
Employee Engagement Rose
Team satisfaction improved as designers and engineers gained clarity on their roles, impact, and growth paths.
Reflection
Building CODA taught me that the hardest design problems aren't on screen; they're organizational. Restructuring a fragmented product org required the same skills I use in product design: deep research, ruthless prioritization, clear communication, and iterative validation. The "user" was the team itself.
The most important lesson was that organizational design is never done. CODA wasn't a one-time fix; it was a living system that needed continuous shaping, just like the products it supported. The ceremonies, the Shape Up rhythm, the centralized resource model; each was a design decision that required iteration based on real-world feedback.