Where AI actually paid off across a software development lifecycle, and how it cleared legal, risk, and a development organization that did not want its process touched.
AI was expected to make individuals faster. Delivery was stalling at the handoffs between product management, design, and development.
A company-wide no-AI policy, and a legal organization that had never approved company data leaving its own servers.
A governance model, a six-week pilot, and a rollout plan, cleared by risk, legal, and a development organization that would not change its process.
The strategy came to me because I knew the full software development lifecycle and had built my expertise in design operations, which is where the change would land hardest. Design already worked as the bridge between product management and development, so everything else in the plan had to cross it.
The request assumed AI makes individuals faster. Work was stalling in the space between them.
Give each team AI, each team gets faster, and delivery gets faster with them.
The teams were already quick. Time was going to the handoffs, where intent had to be translated and rebuilt before the next team could start.
The two handoffs became the targets. Work that lived inside a single team was deprioritized regardless of how easy it looked to automate.
The policy was driven by a fear that proprietary work would end up training a competitor’s model. None of that was a surprise. Individual contributors were already using AI quietly, because they could see the market moving without them, and the strategy had to legitimize that practice.
Three groups could have stopped this, and none of them could be won the same way.
A veto over any company data reaching a server the company did not control.
Meeting their governance rules instead of arguing the policy.
A refusal to let anyone change how development worked.
Leaving their process intact, and routing the few changes that did reach them through senior developers leadership wanted to keep happy.
Quiet AI use with no sanctioned path, and no reason to adopt a new one.
Legitimizing the practice, then making training a prerequisite rather than an option.
Approval was never a single decision. Each group was cleared on its own terms, and together those positions set the acceptance criteria: a workflow qualified if it sat at a transition point and could run without moving company data off company servers or changing how the receiving team worked.
Seven tools, wired so that one of them was the place people actually worked.
The central surface. Concepting, review, design system work, and the handoff to development all happened in one place.
Project management, surfaced inside Figma through custom widgets.
Research findings, available where the design work was happening.
Product analytics, sitting alongside the designs they described.
External tests, run without standing up a separate project.
Design system components as working code, without pulling from the library.
Each connection was a custom widget or plugin built in house, so the integration held together without adding Jira Cloud to the stack, and nobody had to leave the file they were working in to find what they needed.
A small slice of a large organization, run fast, with every finding feeding the proposal leadership eventually approved. The scope followed the path a concept actually takes, from design through review to a development handoff, with the design systems team pulled in to build or update a component along the way. Senior developers were included on purpose, so they could see what the change did for their own work and make that case upward themselves.
Turnaround came out of Jira using measures leadership already required on regular projects, so nothing new had to be instrumented to run the pilot.
The pilot existed to find what needed changing, and four assumptions broke in the process.
Participants had a month of sandbox access, the full training material, and direct access to me. Most arrived having opened none of it, because nothing required them to.
People do not read the rules, and a single violation could have cost the whole organization its access. Monitoring for policy breaches became part of the design instead of something to add later.
Individual contributors got faster and the work piled up at the transition points, until the workflows around them were widened to match the new pace.
Where part of a team used the new workflow and part used the old, everyone fell back to the old one, because it was familiar and easier. Deployment had to be organized so no project ever ran in both modes at once.
The rollout that followed made training a prerequisite, tied delivery expectations to actual tool usage, and extended timelines to absorb the slowdown while people learned the new way.
Ideas get mocked up with design support and tested externally before anyone commits to building them.
The handoff carries the design system with it, so a developer sees which component was used and how it was configured.
Development to deploy was left alone on purpose. That is the workflow development leadership wanted untouched, and it was not where the delay lived.
Several of the new workflows corrected problems the company had carried for years, independent of any tool. Producing work in a vacuum became difficult, so fewer things arrived at a handoff as a surprise and delivery errors fell. Review time dropped with product, design, and development working in one file rather than three. Teams also tested more ideas earlier, because standing up an external test stopped being a project of its own.
Every organization runs the same loop, and it looks the same whether you are watching one designer’s afternoon or a three-year strategy. The Unified Systems Framework is how I find where that loop breaks, and it is what produced the strategy above.
Goals, intake, and every point where work changes hands, observed from inside the teams rather than read out of the process documentation.
→ The real workflowAt each of those transition points, what the receiving side expected against what actually arrived. No new instrumentation required.
→ Where value leaksGovernance, decision ownership, review, and a pilot scoped to test the transition points under real delivery pressure.
→ Governance and a pilotThe loop runs at every scale. What changes is how broadly the problem has to be understood before anyone can act on it.
Now let’s make sure that value arrives.