Government · Team Leadership
A government project hit its delivery deadline, in part because the design team stopped being a parallel track and became part of delivery. Designs went to build faster, with less waste, and a delivery manager who'd never had visibility of design work could finally see what was happening and why.
The design team was operating as a separate unit from the delivery team, producing scope-heavy solutions that had to be stripped back before build, with no usability testing in the time that remained. I restructured the team to embed designers in delivery squads, anchored all design work to the roadmap, and created feedback loops between design, product, and engineering, while continuing to deliver as an IC throughout. The project hit its immovable delivery date, the delivery manager gained clear, ongoing visibility of all design team work, designs reached build faster with scope aligned to delivery constraints from the start, and usability testing was no longer cut, it became part of the process.
The project was a Brexit project relating to the import of Animals, Food and Feed into the UK. It had a fixed, non-negotiable delivery date. The design team was active and appeared productive, but the delivery manager had no reliable way to understand what they were working on, whether it mapped to roadmap priorities, or whether it would be ready in time. The risk wasn't that designers weren't working, it was that their work might not land where and when it needed to.
The design team operated on a separate planning track from delivery. They ran their own sessions, used different work-tracking methods, and weren't meaningfully constrained by scope or delivery timelines.
The result was predictable: designs consistently came back described as "gold plated", full of nice-to-have features and interactions that looked good but couldn't be built within the constraints. Before any design could be signed off for build, a non-trivial amount of time was spent stripping it back. By that point, there was no runway left for usability testing. Designs went to engineering untested.
This wasn't a skills problem. It was a structural one, and it had been in place long enough that nobody felt empowered to challenge it.
The most important thing I learned early was that the problem was already understood inside the team. Almost everyone, designers, engineers, product people, recognised the structure wasn't working. They had ideas for how to fix it. They just didn't feel they had the agency to act.
That changed the job significantly. This wasn't about diagnosing a problem and persuading people to change. It was about creating the conditions for a change people already wanted.
The second insight was structural: designers were solving problems without delivery constraints as an input, and embedding them in squads would fix that, not by limiting creativity, but by making constraints visible earlier.
It wasn't a creative failure. It was an information failure.
The delivery date was immovable, so the restructure had to happen around live delivery, not instead of it. There was no dedicated transformation runway, I was also delivering as an IC throughout the three months. The design team couldn't pause; they needed to keep supporting delivery as the structure changed. And the existing structure had been set by a previous design lead, so changes needed to feel collaborative, not like a verdict on what came before.
Before doing anything structural, I ran 1:1 interviews across both the design and delivery teams. I deliberately avoided a team-wide retro, group settings would have anchored people to the existing dynamic and made honest feedback harder to surface.
What came back confirmed the insight: most people knew what wasn't working and had ideas for how to fix it. From there, the plan almost wrote itself.
I designed a structure where designers were embedded in feature delivery squads, working directly alongside product and engineering. A user researcher worked ahead of the squads, pulling from the roadmap to ensure designers had research findings before they needed them. I sat outside the squads as design team lead, alongside a service designer, to provide consistent direction and a holistic view across the product.
I shared the plan with the team before presenting it to stakeholders, incorporating their feedback before seeking buy-in. The team owned the change rather than receiving it.
Once approved, I rolled it out incrementally but quickly, with cross-functional retros (including representation from product and engineering) as the ongoing feedback loop.
Embedding pace and squad fit. The hypothesis was that dropping designers into squads immediately would create friction before trust was established, so the embedding was phased, designers joined squad ceremonies first before taking on tracked squad work, giving time for relationships to form. The transition was smoother than expected; most designers were relieved to have clearer context for their work. The bigger adjustment was on the engineering side, getting used to design being present in sprint planning.
Work tracking in Jira. Designers added high-level tasks to squad boards without story points, so their work was visible to the delivery manager without affecting velocity calculations. This worked well as a lightweight solution, it surfaced design progress without creating overhead or introducing design into engineering estimation conversations.
The delivery manager described having clear visibility of design work for the first time. He could see what each designer was working on and how it connected to roadmap priorities, without needing to chase updates or interpret a separate planning system.
Within the squads, designers reported feeling more grounded in their work. Having delivery constraints as a live input, rather than a late-stage reality check, shifted how they approached scope from the start. Regular research playback sessions (at least weekly) meant that by the time designers needed insights, they already had them.
The restructure itself was never going to have a dashboard, so the proxies are the honest measure here, and they're real: the project hit its immovable date, usability testing went from zero (no runway left for it) to a standing weekly practice, and the time previously spent stripping back gold-plated designs simply stopped being needed.
The lesson I keep coming back to: when a team already knows what's broken, the job isn't to diagnose the problem and persuade people to change, it's to create the conditions for a change they already want, and then let them own it rather than hand it down to them. That's held up in every restructure I've done since.
I'd try to establish shared metrics for design quality earlier, not just delivery metrics. We had good proxies (dates hit, testing restored) but no agreed way to measure whether the work itself improved as a result of the structural change. That would have made the case for the restructure more concrete, and given the team a clearer target beyond "ship on time".