← Back to portfolio

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: A Structural Experiment in How Work Gets Organised

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.

Organisational Design Operating Model Experimentation Change Management Without Formal Authority

Animated diagram of seven subfunctions pinching off members to assemble into three pods

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

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
Four objectives inside one pilot meant no single thread got the undivided attention it might have deserved alone

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.

Three deeper threads

Six field notes follow individual threads further than a project page can: the demand and capacity mechanics, the case for seeding design expertise beyond the central team, the leadership-development experiment and its costs, one specific handover ceremony, the organisational-design thinking borrowed from Merholz, and a reflection on rank, strategy, and where DesignOps actually sits.

On demand, capacity, and the shape a pod takes in its first six months Coming soon The operational mechanics: how capability composition actually worked, what the recurring six-month formation pattern looked like across all three pilots, and what didn't scale cleanly even once the model proved itself. On seeding design DNA → A controversial idea discussed at leadership level: what if depth and stakeholder trust became a pathway out of the central design team entirely, seeding the practice's approach into business domains permanently. On growing leaders without titles Coming soon The career-development experiment inside the pilot: why the role was deliberately called a "rep" rather than a "lead," why I delegated the selection to managers rather than choosing myself, and what happened when that careful ambiguity eventually needed revisiting. The pod rep handover → One specific, difficult handover between an outgoing and incoming rep, and the small ceremony designed to make sure it didn't pass by unacknowledged. On organisational design without organisational authority → The thinking behind borrowing Merholz's framework, the year-long incubation and co-development with managers, and what it means to change how an organisation works when you have no formal power to change its structure. Strategy, rank, and where DesignOps actually sits → A more personal reflection on translating an abstract company mission without a mandate to do so, and the discomfort of not knowing whether that was overstepping.