Scaling Design Operations Through Pods

Summary

When I joined LinkedIn's Marketing Solutions team, designers were assigned to individual projects each quarter. On paper, it worked. In practice, it was breaking.

Every quarter felt like hitting the reset button. Designers would finish one project only to be rotated onto something completely new — different product area, different stakeholders, different context. They'd spend the first half of the quarter just onboarding and building relationships. By the time they had real momentum, the quarter was ending. Meanwhile, project requests far exceeded our capacity. We were sorting through 100+ requests every quarter with a team that couldn't keep up.

The project-based model created a compounding problem: it was hard to build deep expertise in any area, hard to maintain design quality, and hard to create continuity for cross-functional partners who never knew which designer they'd be working with next. Design critiques weren't productive because designers were presenting work in contexts their peers had no familiarity with. Managers were stretched thin, unable to stay close enough to craft because each of their reports was on a different project. And the constant narrative of "we don't have enough resources" — while true — was starting to become something the team fell back on rather than solved for.

Something needed to fundamentally change.

The approach

I started by looking at models that had worked for other organizations. The Spotify squad model was compelling — the idea of cross-functional teams organized around a specific product area, with supporting structures (chapters for functions, tribes for broader alignment) that maintained community across squads. We piloted it for two quarters.

The pilot surfaced immediate benefits. Designers who had been globally distributed were suddenly collaborating in focused groups with shared context. Design critiques became relevant — everyone in the room understood the problem space. Time zone-friendly meetings happened naturally because pods could organize around their own geography. Principals and managers started mentoring more effectively because they were embedded in a single area rather than spread across everything.

But the pilot also exposed friction. Cross-functional partners weren't familiar with the terminology. Some product and engineering partners were engaged at different levels. And the Spotify documentation available online was thin when it came to scaling — most of it was written for a specific company in a specific moment.

So we adapted. We moved from squads to what we called "pods" organized under "experience tracks." Pods focused on specific product areas. Experience tracks were the strategic umbrella. For design specifically, we kept the concept of "chapters" — the functional community where designers could connect across pods. This meant we only changed one layer of taxonomy while keeping what was already working.

Key design decisions in the new model:

• Pods owned product areas, not projects. Designers stayed in their pod across quarters, building deep expertise and stable partnerships with their PM and engineering counterparts across three pillars — Campaign Manager, Experience Measurement, and Relevance & Optimization. No more quarterly resets.
• Principal designers became experience owners. We redefined the principal designer role so that each principal was responsible for the vision of their pod's area — thinking long-term, coaching ICs, and ensuring the quality bar. This was a major shift. Many principals hadn't been in organizations that included them in strategy, and coaching them through that transition became one of the most rewarding parts of the work.
• Managers focused on operations and people. Managers didn't always have their direct reports in their pod — designers sometimes reported to a different manager than the one leading their pod. This was new and uncomfortable, but it freed managers to focus on stakeholder management, resourcing conversations, and escalations while principals handled craft and direction.
• Shared language with engineering. Early on, I quantified design hours in the same way engineering measured sprints. This created a common vocabulary for capacity planning and made it easier to demonstrate the gap between request volume and available resources.
• Vision narratives as a forcing function. Each pod's leadership team was tasked with building a narrative vision for their area. This gave ICs a North Star — their individual work wasn't happening in a vacuum, it laddered up to a clear story. It also created a powerful artifact when presenting to VP and C-level leadership.
• Theme-based clustering replaced project-by-project prioritization. Instead of evaluating 120 individual requests, we grouped them into roughly 10 overarching themes. This let us have strategic conversations at a leadership level and gave principals context to coach their teams.

We didn't try to roll this out all at once. We started with a pilot in one area, then expanded to a second, learned from both, and eventually scaled across the full organization. Each iteration surfaced new nuance — some pods needed more program management support, some needed different meeting cadences, some principals thrived immediately while others needed coaching on the strategic ownership piece.

Organization Design is Design. You're dealing with the same constraints — limited resources, competing priorities, imperfect information. LinkedIn — Scaling Through Pods

The approach was deliberate and iterative — build the muscle one layer at a time, prove the model, then scale. Here's what that looked like in practice.

The Impact

The pod model transformed how the design team operated at LinkedIn Marketing Solutions:

• Design critiques became productive and relevant. With everyone in the pod sharing context, feedback was specific, actionable, and tied to the product area. People who had been quiet before started contributing new ideas.
• Principals became strategic partners. They were no longer just senior ICs doing concept work on priority projects — they were setting the roadmap and vision for entire product areas, collaborating with managers at a peer level.
• Velocity increased. What had previously taken 6–9 months from concept to build was now happening within quarters. Designers weren't wasting half their time onboarding to new contexts.
• Engagement and morale improved. Survey data showed an immediate lift — more mentorship, more coaching, and more ownership at every level. People felt invested in their area because they owned it.
• The vision narrative work gave leadership a clear story. My manager could present a compelling, unified narrative at the VP and C-level that demonstrated design's strategic value — not just a list of shipped projects.
• The model became the operating system. What started as a pilot became the default way the design organization at LinkedIn Marketing Solutions worked — across a 600+ person R&D organization distributed from New York to Bangalore. It outlasted individual projects and individual people.

Reflection

Building the pod model taught me that organizational design is design. You're dealing with the same constraints — limited resources, competing priorities, imperfect information — and the same principles apply: start with a pilot, iterate based on feedback, create shared language, and optimize for the people actually doing the work. The clean and jerk metaphor from my football days kept coming back: you can't do a complex exercise on day one. You build progressively — deadlift, shrug, clean, then the full movement. Same with teams. You build the muscle for strategic vision one layer at a time, and when the moment comes to bring it all together, the team is ready.

What I underestimated was the coaching investment required when principals stepped into strategic ownership. Some thrived immediately — they'd been waiting for the opportunity. Others struggled with the ambiguity of owning a vision without a clear brief. In hindsight, I would have built a more structured onboarding path for that transition rather than expecting people to figure it out through the work. The model was right, but the support system for the people inside it needed more intentional design.