Miro Reframe: From idea to dev-ready story, with Josh Guice
Josh Guice, Field CTO at Liatrio, says he can usually tell within the first few conversations whether a client’s AI rollout is actually working. Two or three people are quietly doing something impressive with it. Everyone else is stuck, spending more time wrestling with the tools than they used to spend on the work those tools were supposed to replace.
He compares it to dropping a new graphics card into an old motherboard. The card itself is fine. “That video card doesn’t fit in the motherboard you have anymore,” is how he puts it, and no amount of AI velocity inside an unchanged team changes the shape of what that team ships.
Guice has spent two decades arriving at the next thing early: DevOps before it had a name, cloud before it was standard, and now AI, full time. At Liatrio, a 200-person consultancy that spends most of its time helping large enterprises act more like “the startup that’s about to disrupt them,” he sits inside this exact gap for a living, between AI that’s been rolled out and AI that’s actually changed how the work gets done. What he tells clients to fix is the team size and the spec, not the model.
The pattern he keeps finding
Three signs come up on almost every engagement:
- The team and org structure sitting there completely untouched,
- Adoption concentrated in a handful of people, and
- AI ‘adoption’ supposedly being present but shipping velocity hasn’t improved.
Team structure and software architecture tend to mirror each other, Guice points out, so an organisation that never rethinks its team shape usually can’t rethink its product shape either.
There’s evidence that this isn’t unique to Liatrio’s client list. McKinsey’s most recent State of AI research put enterprise AI use at 88%, but only 37% of companies could point to any measurable earnings impact from it. The factor that separated the two groups most clearly was whether they’d actually redesigned the workflow, not how much they’d spent on the tools themselves.
For consultants and agencies, this cuts both ways. It’s the thing a lot of your clients are quietly trying to get back: that scrappy, small-team feel they had before they scaled into whatever they are now. There’s a good chance the same pattern is sitting inside your own delivery teams: a couple of people pulling well ahead on AI, while the rest of the firm hasn’t moved much at all.
How small is small enough
Push Guice on numbers and his answer is smaller than most people expect: 3 to 5 people at the most, owning one real value stream from end to end. Rethinking team size alongside the org structure opens up options that just installing better tools never does. A pilot doesn’t need to succeed for something to be worth running. If it produces learnings that tell companies how a team or process needs to be shaped, then it’s not wasted effort.
What makes a team that small workable during the development phase is something Guice calls spec-driven development. This approach requires writing a clear, detailed blueprint before writing any code. It keeps everyone on the exact same page so developers don’t build the wrong thing, and it also helps AI to avoid guessing and have a clearer definition of done. He showed it using a deliberately unglamorous example: a small vet practice called Emerald Grove wants to take payments online.
A product owner takes the meeting transcript, then builds out the project outcomes and requirements needed. This is then matched against other context-rich information sources like Confluence (for knowledge base/wiki), Jira (for work tracking), and Github (for source control to build the context brief – a summary that cites its sources line by line instead of just asserting things. Throughout the entire process, AI assists in consolidating and structuring the information into something digestible for the team.
For Emerald Grove, that meant surfacing an old, shelved pull request whose review comments became the only real record of why card data can never touch the clinic’s own systems, plus a brand green that technically fails contrast rules against the sand background it’s supposed to sit on. Anyone on the team, engineer or not, can go back and check each line against where it came from.
From there she puts together what Guice calls a “cardboard-and-duct tape” prototype, rough but working, and shares it the same day. Colleagues break it within the hour: someone notices a missing itemised total, someone else points out a payment state that never gets announced to a screen reader. Each fix turns into a Gherkin scenario, precise enough that an engineer can build straight from it and a test suite can check it automatically.
Guice rebuilt this whole flow inside Miro too, using Flows and Sidekicks: dropping a knowledge base into a frame and running a single prompt to get something close to the same brief, and a Kanban card carrying its own scenarios.
The anecdote that stuck most though wasn’t really about the tooling. One of Liatrio’s clients in genetics has a non-technical product owner who felt outpaced by her engineering team – for whom the company’s AI rollout was primarily intended. She felt stuck and left behind, and asked Guice for 1:1 help. A few sessions later, she had built her own forecasting and validation dashboard from the company’s work tracking system, using AI to do the technical heavy lifting on pulling historic data together while she supplied the judgment about when important releases needed to happen. It ended up as a readout for the CTO.
That kind of safe-space support and knowledge sharing is invaluable when you’re trying to bring everyone along on the AI adoption journey – regardless of their skepticism, technical knowledge, or confidence level.
Three things worth trying from Liatrio’s field notes
Pilot a minimal team on one real value stream.
3-5 people at most, owning a single slice of work end to end rather than a committee advising on it from the outside. Pick something narrow enough that the team can actually reshape it. If a pilot fails, identify the root cause (i.e. is it structure, process, or something else) and share the learnings with your team.
Go find the business users your rollout skipped over.
Guice’s enterprise clients routinely discover their business side runs Windows while every setup guide was written for engineers on MacOS. There’s a bridge you need to build between engineers and business users. Office hours and 1:1s sound small, but they’re the fastest way to get someone from falling through the cracks to shipping work a CTO actually notices.
Treat adoption as a habit you keep reinforcing, not a rollout you finish once.
Guice’s most common failure pattern is a team that then quietly slides back to the old way of doing things within a couple of enablement efforts. Build a check-in around the eight-week mark into the plan from day one, and where compliance is the real blocker, route traffic through an AI gateway built on the cloud relationships the client already has, rather than letting the concern shut everything down.
None of this works if it stays a conversation about tools. The team, the structure holding it, and whether the new habit actually sticks are the real product here. Get those right, and the AI stops being the expense you’re still waiting to justify.
If you want to see another firm wiring up something similar- discovery notes turning into a spec without losing anything in translation – Endava’s build of an AI-native delivery workflow inside Miro is worth a look.
