This work is protected
This case study contains confidential details. Enter the password to continue, or email me at evontay.home@gmail.com for access.
2023–2024 | Role: DesignOps Lead
Designing Pods: An experiment on how we organised work
I saw four distinct problems the design organisation was facing, and a hypothesis that one structural change—how people were grouped around work—could address all of them at once. That hypothesis became a pod-based operating model, tested through experimentation rather than mandate, since I had no authority to redesign the org chart directly.
Four problems, one structural root
- Design was being consumed as mechanical demand fulfilment. Work arrived as discrete requests, dispatched one at a time. We suspected this transactional relationship capped the practice well below its real potential for the business.
- The org chart created silos. Structure organised around individual competencies made holistic collaboration—research, design, and business thinking integrated around one part of the business—difficult by default.
- Senior ICs had nowhere to grow. Practitioners excellent at their craft hit a ceiling where the only next step was people management.
- Nothing translated the north star into practice. "Raise the company's design maturity" was rightly abstract, as a mission should be—but no mechanism existed to turn that into something specific for a dozen business areas starting from very different places.
Strategic Frame
Treating these as four separate problems would have meant four separate initiatives competing for the same scarce attention. Treating them as expressions of one structural issue meant a single experiment could move all four at once.
The experiment
I adapted Peter Merholz's concept of "centralised partnership" from Org Design for Design Orgs—a design function keeping a central home for craft while embedding more deeply into the business it serves. The structure was borrowed. The concrete unit was mine to design: a pod, a small multidisciplinary team embedded in one business area for a sustained period, staffed once rather than request by request, autonomous in its domain while staying connected to the central practice.
The name was deliberate. "Team" was too generic; "squad" carried agile baggage this model didn't share. I wanted the image of peas in a pod—small, complete, distinct, part of something larger.
How each element addressed more than one problem at once:
- A maturity assessment run at each pod's formation turned the abstract north star into a specific answer for that business area, while also calibrating what the pod could realistically deliver
- A pod "rep" role (deliberately named to avoid a status fight among peers of equal rank) gave senior ICs real leadership exposure, with candidates identified by their own managers
- Piloting under the banner of "demand management," an already-acknowledged problem, gave the larger structural ambition room to prove itself before it had to be defended on its own terms
- A year of quiet conversation with managers, before any pilot launched, meant the idea had genuine distributed ownership rather than being mine alone to sell
- A separate, centralised process kept handling ad hoc, unaffiliated requests throughout—pods were only formed where a business area had already built a sustained collaboration history through that process, with a willing sponsor in place. Pods weren't offered speculatively; they were earned
Strategic Insight
Without authority to mandate a new structure, the strongest argument was evidence of behaviour already happening, patiently gathered—not a proposal. This also meant accepting a much longer timeline than a mandate would have required.
What happened
Three pods launched simultaneously as a pilot.
What worked:
- How work entered each pod, and how it got prioritised, genuinely decentralised—no two pods handled intake the same way
- Several senior ICs got real, visible leadership exposure they wouldn't otherwise have had
- A recurring six-month formation pattern emerged independently across all three pods, suggesting the model captured something structural about how trust gets built, not a coincidence
What didn't scale cleanly:
- The model assumed a baseline of organisational maturity not every business area had
- The deliberately soft "rep" title, useful early on, became a real constraint for individuals who outgrew the ambiguity it was designed to protect them from
- Success created its own bottleneck. Once other parts of the business heard about the pilot's results, interest in getting a pod of their own outpaced our actual capacity to form and staff new ones responsibly
This particular limit was never solved within the model itself. It was eventually overtaken by a much larger organisational shift, unrelated to anything designed here. That's a different story.
Strategic takeaways
1. One structural change can address several distinct problems, if they share a common root.
Four competing initiatives would have fought for the same scarce attention; one experiment addressing a shared cause moved all four.
2. Borrowed frameworks still need local translation.
Merholz's concept gave rationale; the actual shape of a pod, and its name, had to be designed for this context.
3. Influence without authority runs on patience and evidence, not persuasion.
The idea needed roughly a year of quiet co-development before it was ready to pilot.
4. A familiar name can be legitimate cover for a new idea.
Introducing this as demand management wasn't the substance of the work, but it bought the real experiment time to prove itself.
Go deeper
The posts below follow threads that this whole initiative on pods raised.
This work involved close collaboration with practitioners, stakeholders, and business leadership. Details have been generalised to protect confidential and proprietary information.