A failure mode hiding in plain sight
There is a failure mode in cross-functional product work that is easy to miss if you are looking at it from the outside. Everything appears to be running. Standups are happening. Designs are moving. Stakeholders are being looped in. And yet the work keeps drifting, escalations keep surfacing informally, and the people closest to it start showing signs of fatigue that do not match the complexity of their individual tasks.
That is what was happening on a major platform migration we were running. Our senior designer had been carrying coordination responsibilities that extended well beyond design, bridging product, engineering, data, and support. She had built a clear execution plan and was delivering strong work within her lane. The product manager was engaged. The engineering lead was responsive. And still, the seams kept showing. Handoffs were getting lost. Decisions that should have taken a day were taking a week. Two collaborators who usually worked well together were developing friction that neither of them could explain.
When I sat down with my product counterpart to walk through what was actually happening, we kept arriving at the same conclusion: this was not a people problem. It was a structural one. The scope of coordination required to land this migration cleanly was director-level work. It required someone who could hold the full picture across five functions and make tradeoff calls that no individual contributor should be expected to make. The fact that our designer was handling it reasonably well had actually obscured the gap, because the work was getting done just well enough that nobody questioned whether the structure was right.
What we changed
We made three decisions in that conversation. First, we changed the ownership model. The designer would continue executing her work (nothing drops), but the coordination layer would sit formally with the two of us, product and design leadership paired as co-owners of the cross-functional cadence. Second, we stood up a small working group with a named representative from each function, a regular meeting rhythm, and a shared tracker. Third, we asked the designer to pause her direct outreach to the support and data teams until the structure was in place, so that none of those relationships would be strained by ambiguity about who was driving what.
The hardest part of that conversation was not the decision itself. It was protecting the designer from being read as the problem. When you surface a structural gap, the people closest to the work are the most vulnerable to misinterpretation. So the way we communicated the change mattered enormously. We led with the structural argument, named the scope mismatch explicitly, and framed the designer’s pause on outreach as a deliberate strategic hold rather than a performance signal.
Why this matters for design leaders
If you are a design leader and you have someone on your team who seems to be struggling, the first question to ask is not about their performance. The first question is whether you have set up a structure where their role is actually doable. The symptoms of a structural problem and a performance problem look nearly identical from a distance: missed deadlines, escalations, friction with partners. The difference only becomes visible when you sit down with the people involved and listen for what they are actually describing. In our case, the designer was not describing confusion about her work. She was describing a coordination burden that had no clear owner above her. That is a leadership problem, not an execution problem.
The fix took one conversation and two Slack messages. The hard part was seeing it clearly enough to have the conversation in the first place.