Growth Teams: To Centralize or Decentralize?
Evaluating the pros and cons of each approach and a framework for decision-making—with examples from Lyft, Patreon and Imperfect Foods
Hi there, it’s Adam. 🤗 Welcome to my weekly newsletter. I started this newsletter to provide a no-bullshit, guided approach to solving some of the hardest problems for people and companies. That includes Growth, Product, company building and parenting while working. Subscribe and never miss an issue. I’ve got a podcast on fatherhood and startups - check out Startup Dad here. Questions? Ask them here.
Q: What’s the right team structure for success? Do I have a standalone Growth team or is growth a cross-functional effort?
To centralize or not centralize (aka decentralize); that is the question. Is it wiser to consolidate power and control for the sake of efficiency and speed, or to distribute authority and decision-making widely to foster innovation and resilience? (Thank you Shakespeare).
This question is so prevalent that in the Reforge Growth Leadership program, created by me and 👑🐐Elena Verna, we have an entire module to help you answer this question.
I wanted to create a short-hand resource for that decision and take you through some more org structure examples.
In this article you’ll learn:
Benefits and drawbacks of centralized and decentralized structures
A framework for deciding which model is best for your situation
How other companies have handled this decision over time
What do we mean by Centralized and Decentralized structures?
A lot of leaders make hires to staff up for Growth (a topic I’ve covered in other newsletter articles) and haven’t thought through how they plan to structure the team. Based on the number of times I get asked this question most don’t know, but this gap in knowledge can be problematic for the success of the team.
A centralized Growth team is an independent, standalone entity within your company that typically reports up to a single leader such as a Head of Growth or VP of Growth. A decentralized Growth team is a set of pods that are composed of cross-functional team members who also report to different cross-functional leaders.
There is no right or wrong structure – there is only the right or wrong structure for what your organization needs at a moment in time. There are tradeoffs between these two models.
Benefits and drawbacks of each structure
A Growth team should ship rapidly and maximize learning that can be distributed across the organization. In this article I’ll refer to this as “velocity” and “growth culture.”
Velocity
When we think about velocity the question is: what is the speed at which a growth team learns. Learning requires hypothesis development, experiment design, release and evaluation of results.
When you have a centralized team with a single leader you will see higher velocity. You’ll have fewer people involved and a narrower management chain so teams can make decisions more quickly. Resources are focused and everyone on the team shares the same goals. Because you’re making faster decisions you will learn faster which leads to that higher velocity.
In a decentralized team you’ll experience lower velocity. Decision making can be hampered by the larger number of people involved and a wider management chain. Additionally your resources will have other goals beyond growth. There’s no way around it. And if they have other goals they will only spend part of their time testing growth hypotheses. As a result, learning is slower and velocity is lower.
Growth Culture
As mentioned above, when I refer to growth culture I am referring to the extent to which all parts of the organization think about growth. This means that they’re thinking and developing hypotheses about acquisition, retention and monetization. The better every team is at operating with a hypothesis-driven approach the higher the Growth Culture in the company.
A centralized Growth team leads to a lower growth culture. Centralization creates a silos and even if the growth team works very hard at distributing knowledge you will still have other functions that are too busy to notice and internalize the lessons. They just won’t be exposed to it enough.
A decentralized Growth team leads to a high growth culture. In this team structure everyone has some ownership and responsibility for growth. This forces the iterative, hypothesis-driven approach to feature development.
As a personal example, I was once an eCommerce Marketing Manager at a ~150 person startup about ~17-18 years ago. This was before the growth role existed, hence the title. With two other people, my job was to develop hypotheses to improve our acquisition and monetization, build experiments to test those hypotheses, analyze the results, and iterate. At the time, tools like Offermatica ruled the day. I was so siloed that in Q4 they moved my desk (and a few others) to the other side of the building and we sat there, by ourselves, working on experiments all day. Our efforts were successful, but I still felt like Milton from Office Space. Other than turning my former desk into a makeshift memorial, complete with foam tombstone and photos, the rest of the company kept operating like it was business as usual. I was so busy and isolated that I didn’t have time to help them internalize the lessons I was learning.
Contrast that with my time at Patreon where we had PMs, engineers, product marketers, analysts, designers and even account managers (from sales) embedded on a set of cross-functional growth teams. Each function on the team reported up into their own, distinct organization and could share learnings widely within their core teams. After some initial wins and corresponding information sharing we started to see more hypothesis-driven experimentation happening across the company.
Velocity vs. Growth Culture is a tradeoff that depends on team structure and it’s incumbent on growth leaders to regularly evaluate which of these structures is the right one.
A framework for deciding on your team structure
There are a set of signals that you can use to evaluate whether your current team structure is working.
Most teams will start with a centralized structure because they’re optimizing for velocity and success and they want to maintain a small organizational footprint.
You’ll know it’s time to re-think this when you start to observe a few problems – accountability and velocity.
Accountability
If there is a dearth of accountability and growth culture across the company you’ll notice that all teams are not evaluated equally. For example, the growth team might be measured much differently than the broader product, marketing, engineering, and other teams are measured.
Nowhere is this more apparent than my newsletter on motion vs. progress. If we’re celebrating a product team for a new release or a marketing team for shipping a new campaign while asking the growth team to be accountable to revenue then we have a very large inconsistency in accountability. If your growth teams are the only ones setting financial forecasts and being held responsible for them then it’s time for some organizational change.
Velocity (again)
Remember that a primary to have a centralized growth team is velocity of learning and experimentation. When this starts to slow it’s time for an organizational change.
But Adam, why would this structure cause a slow down? I thought centralization = speed?!?
This is where the idea of accountability comes into play again. If the growth team is the only team accountable for experimentation this can lead to over indexing on the resources of that team and a bottleneck problem. Like in chemistry, your growth team has become the limiting reagent.
Lest you think that centralized structures should have all the fun, velocity is also the key indicator of an underperforming decentralized team structure.
Usually the culprit here is that your dedicated, cross-functional growth practitioners aren’t all that dedicated to growth goals. They’ll start getting pulled into core feature development, scaling work or maybe even product/market fit expansion. This can be hidden at first because that work won’t necessarily show up in standups or in everyone’s favorite tool, JIRA. It will slowly manifest in fewer experiments being run and fewer learnings delivered across the organization.
If you find your growth team consistently hamstrung by cross-team dependencies then it’s probably time to consolidate and centralize.
How have companies handled this decision over time?
In the Growth Leadership program Elena and I provide a series of examples from some of the companies where we’ve worked.
Here are a few more examples from my own experience:
Lyft
The org design has changed several times over the course of Lyft’s existence. I was the Head of Growth from the start of Lyft (Zimride before then) and through the first few years.
The team was centralized with marketers, designers and technical resources under one org structure and reporting up to me. We were able to move from hypothesis to experiment very rapidly. We scaled the company to 70+ cities and millions of rides in a span of ~2 years,
In late 2014 I left and the team was folded into other parts of the organization such as marketing, product, engineering and sales. The focus on growth along with speed of iteration evaporated. Since no one was accountable to the growth engine it sputtered.
Then they hired Ran Makavy in early 2016, restarted the growth team and centralized it under him. Later they brought on a Head of Growth Marketing also as part of this organization. These two moves re-created the centralized structure and got the team operating again.
Now Lyft’s size and product surface area means a centralized organization for Growth doesn’t make as much sense. They still have a Growth Marketing team focused on managing ad spend. A rider group optimizes the booking funnel and a marketplace team is in charge of incentives and the underlying ad tech systems.
Patreon
As I wrote about a few weeks ago in Building Growth Strategy at least 25% of Patreon’s open hires are currently for growth roles.
From 2016 through 2020 we operated as a decentralized organization. The product managers reported to me and engineering, design, data science, marketing and sales team members reported to their respective organizations. We had a great growth culture and knowledge sharing across the entire company.
One of the key risks of decentralization is a slowdown in velocity. We didn’t have a problem with this because priorities were clear and the focus of the decentralized team members was on growth goals.
But we did experience a few times when cross-functional resources were pulled to work on different projects – mostly core product or infrastructure. This happened around our pricing changes and platform changes. A centralized structure would have made this less likely to happen, but company strategy dictated otherwise.
Imperfect Foods
As Chief Product and Growth Officer I had all product, design and marketing resources all reporting into me. This was not the case before I arrived and there was consistent and recurring conflict amongst cross-functional teams.
When I joined I re-organized the teams into a centralized group with pairs of pods. There was an acquisition marketing team paired with a new customer experience product pod and a lifecycle marketing team paired with an engagement product pod.
One mistake I made was letting the site merchandising team be separate from the shopping experience product team. Ideally, this should have been centralized as well but sometimes executive egos trump organizational efficiency!
Conclusion
There are many ways to structure growth teams but the most common are centralized or decentralized structures. A centralized team will have a single leader and all people reporting up to them whereas a decentralized team will have different reporting structures usually along functional lines.
Centralization brings the benefits of velocity, fewer decision makers, and is great for getting started. Decentralization improves growth culture, better distributes knowledge, and teaches everyone how to experiment and iterate.
Each structure has its drawbacks though. Operating in a silo and becoming a bottleneck are the downfalls of the centralized structure whereas slowness and lack of accountability can be challenging with a decentralized structure.
I’m hopeful this newsletter has shown you that there isn’t a best and worst organizational structure for growth—there is only what’s right for the moment you’re in.
Tell me about your organizational structure in the comments on this newsletter!