Speed is critical for startups to overtake their competitors.  However, as startups grow into scale-ups, layers and processes get added to their system, slowing them down. Most startups begin as functional organizations, but as they grow, these top-down hierarchies create silos between functional teams, causing bottlenecks that hinder growth and increase the risk of failure. 

For instance, as an organization grows, the amount of collaboration required to get a single project through the common Product Management > Design > Engineering process goes up exponentially. Functional managers like VPs of Engineering and VPs of Design can no longer be effective drivers of projects, so they start hiring middle-managers, which further increases the amount of collaboration required.

I’ve seen this at dozens of companies: A change that ought to take a single engineer one day to complete takes weeks to negotiate its way through the system.

To tackle these challenges and preserve their competitive advantage (namely, speed), some forward-thinking scale-ups transition away from the commonplace functional, hierarchical org structure into a pod structure. Having seen the benefits up close, I fervently believe that more scale-ups need to shift to agile pods in order to accelerate growth and build resilience.

Even though most startup leaders I work with are excited about this change, very few have successfully made the switch. In this post, I’ll share what I’ve learned about and how a company can successfully shift to a pod-based structure.  

Understanding the Pod Structure

Most businesses are organized functionally, sub-divided into several units that are each run as functional entities. The problem is that most organizations struggle to innovate, and are slow to grow. 

Pods are the answer: They allow organizations to get bigger but preserve speed and innovation by focusing on outcomes.  

What are Pods? How Are They Different from Functional Organizations?

A pod is a small, self-governed group of people with different but complementary skill sets. Instead of having separate teams for product management, design, engineering, and marketing, you’ll instead have a handful of self-contained pods, with each pod member expected to work cross-functionally towards shared business goals. 

For instance, a Digital Experience pod could have a marketer, a PM, a developer, a designer, a branding specialist, an SEO expert, and an analyst—all of whom have come together to boost digital experiences. In the same vein, a Conversion pod could consist of an email marketer, a product manager, a product marketer, an engineer, a designer, and a data analyst, all of whom have organized around a joint mission to improve the conversion rate from Lead to Customer. 

The Benefits of a Pod Structure

The management team sets an outcome they’re looking to achieve and then unleashes the pod to run in that direction for a period of time. Because pods have cross-functional expertise, they aren’t dependent on external resources, making collaboration seamless. And since they have autonomy and aren’t directly led by the top management, decision-making is faster.

These two unique traits allow pods to quickly adapt to changes and keep running in the same direction without renegotiating with other teams every week for resources or requiring buy-in on specific projects. This, of course, is what drives speed.   

At Codecademy, I remember receiving feedback after one All Hands presentation where I talked about our revenue growth. A very senior, earnest engineer told me that he felt like the work he did had no bearing on revenue.

I was flabbergasted.

I knew that engineering was our most precious resource, and everything the growth team asked of the engineering team had a substantial revenue impact. The disconnect was that the engineer sat in engineering, and had no context around how his work impacted revenue.

When we transitioned into a pod structure, this completely changed. We’ve stopped operating in silos—it’s no longer “Marketing is asking engineering to complete a Jira ticket.” Instead, it’s “The growth pod is looking at the situation, collectively deciding on the best course of action to grow revenue, and building it together.” 

In this way, the pod structure dramatically increases the team’s level of motivation and accountability by coalescing pods around real business outcomes. 

How Can You Make the Shift from a Functional Org to a Pod Structure?

If you've read this far, it's unlikely that you’ve already made the transition to a pod structure.

Like many startups, Codecademy wanted to make the shift midflight in our scale-up journey. Drawing from my experience, here are seven key things to keep in mind while transitioning to the pod model.

1. Start with a Single Pod.

Rather than trying to reorganize the entire 120-person scale-up all at once, we chose to start with a single project. We identified our top priority, assigned our best people to it, and that became our first pod. The executive team then defined the pod’s objective and key result (a measurable KPI) before unleashing the team. Once we got the hang of it, we scaled the pod structure by creating additional pods later on in the year.

2. Pod Leads are Critical, but the Executive Team Cannot be on a Pod.

Leaders are often drawn to startups because they want the ball. It’s easy to think that things won’t get done if we don’t personally do the work.

But to successfully transition from startup to scale-up, we need to resist the urge to drive every project ourselves. Since we’re frequently context-switching between 100 things, the #1 thing will never get the focus it deserves if we’re driving it.

Instead, chose a dedicated pod leader. The pod lead might come from marketing, operations, product, or another department—it all depends on the project and type of startup. What’s critical is that they should have the necessary people and project management skills to direct their teams in the right direction.

3. The Executive Team Defines the Outcomes, Not How to Get There.

Pods require the freedom to ideate, innovate, and find the best routes to achieve their goals. The beauty of the pod is it is driven, for instance, by a young dynamo of a product manager who can devote 50 hours a week to user research, data analysis, and proposal development. Compare that to if the initiative were being led by a C-level executive: they’d likely spend less than two hours of deep focus a week on the pod’s project.

That’s why the executive team should avoid dictating the pod on exactly how to accomplish the outcome. Instead, their role will shift to defining the outcomes and acting as “functional experts” who will hover above the pod, offering feedback and asking questions to nudge the pod in the right direction. 

This will be hard for some of the executive team to grapple with, but it’s ultimately incredibly freeing. 

4. The Executive Team Must Transition into a Board of Directors and Functional Experts; Not Overworked Drivers.

So, how should leadership engage with a pod?

Executives should be super involved behind the scenes. They should leverage their hard-earned functional expertise to coach their people. For example, Codecademy's VP of Design might do numerous design critiques behind the scenes to influence a particular pod’s product in the right direction. This way, by the time the pod's design makes it to the exec team, it's been through numerous iterations.

The scariest thing about this is that people’s roles could get narrower. It might mean that, instead of being the VP of Marketing directing the most important projects, I had to be comfortable putting my best people into the key strategic pods, where sometimes the Product Manager, and not the Marketing manager on that pod, was the leader. I could influence the solution the pod came up with through critiques and good questions, but couldn’t direct them to execute a specific solution.

This was frustrating, but the trade was worth it: there’s no substitute for the intersection of cross-functional collaboration and focus. No execution plan I came up with alone ever would have rivaled what the pod put together.

Here’s how we did it:

1. I took the financial goals from the Organizational Development Workshop.

2. In the workshop, we tried to break down the top item into smaller pieces and arrived at three WIGs (Wildly Important Goals).

3. We organized a pod around each WIG. The people who can commit to spending at least 50% of their time on this WIG for at least 3 months would be removed from the pod.

4. The pod should develop a plan, get input from leadership and the task force, and present the final plan in two weeks. A pod can also present to the task force weekly on projects and results.

5. Don’t Make the Pod Too Big. Instead, Set up an Input/Output Interface between the Pod and the Stakeholders.

After I tried to introduce the pod structure to one of the companies I advise, I was alarmed to find out that the CEO had instead launched a task force that had no less than 23 members. That’s too big a group to accomplish a whole lot. Worse, when I dug in, I found that most of these 23 folks were only tangentially involved, devoting less than an hour a week to the task force’s mission. 

A pod could have a weekly input/output meeting with a broader group of stakeholders, but there needs to be a core team that has the time to focus on priority projects. The core team should be able to do daily standups and could devote hours every day to move the pod’s mission forward.

6. Make Sure the Pod Has Everyone It Needs to Be Successful. No Dependencies.

A good pod is like a Swiss Army knife: Small and cross-functional. However, most people only focus on the “small” aspect, overlooking the “cross-functional” part.

To preserve speed and innovation, a pod must have all the skillsets needed to complete a project autonomously. The second the team is missing a resource and needs to negotiate with other outside teams to complete projects, innovation drops to a standstill. 

Let’s play out an example: Let’s say our conversion pod has a marketer, a PM, and an engineer, but no designers. Every sprint, the design work gets sent over to the Head of Design, where it goes into a queue. Instead of focusing on the project, the pod leader instead has to spend time each week lobbying and negotiating with the Head of Design who is, understandably, weighing this project against other priorities.

Eventually, they agree that Jesse, a designer, has some time this week for this project. Jesse needs a week to catch up on all the context: Who the user is, the pain points to solve, etc. Jesse finally ramps up and ships a design. Hooray!

But two weeks later, the whole saga happens again. This time the Head of Design taps a different designer, Jen, to get the project done. Jen is quite talented, but she also needs a week to build up context, understand the pain points, and then develop a solution.

And just like that, innovation has slowed to a crawl.

Not every startup has a big enough team to place a dedicated designer on every pod. That’s understandable. But instead of putting design asks into a centralized queue, which, as we saw above, kills speed, a more optimal solution is to ring-fence a percentage of one designer’s time.

For instance, you could let Jen know that for the next two quarters, 50% of her time will be focused on the conversion pod. You can leave it up to the conversion pod to decide as a group how that time gets allocated. This allows Jen to focus on just two problem areas, build up a ton of context on each, and build up momentum shipping on each. Even more importantly, Jen will feel ownership over the conversion team’s mission and business outcomes. 

7. A Pod Needs a Runway to Build Up Context and Momentum.

One mistake we made at Codecademy was doing quarterly OKR planning. Just when the pod was starting to pick up momentum in Q1, we kicked them back into planning. We moved people around, changed priorities, and then, they had to start planning from scratch.

For instance, let’s say we want to double our free user to paid user conversion rate in 6 months. They give the pod enough time and buffer to accomplish the goal. However, a single quarter may be too short a duration for newly formed pods to accomplish goals. They need time to build up context, smooth out any initial friction, ideate, ship, incur delays, iterate, and ship again. To get the best results, keep pods in place for at least 6 months so it has time to pick up momentum.

Conclusion

It’s not enough to simply survive in today’s dynamic business landscape—you need to thrive and grow. 

Business agility is the secret ingredient in the biggest companies’ recipe for success. The self-governing, cross-functional pod structure will give you an edge in driving business agility, allowing you to scale with ease, win big, and unlock extraordinary value.