Who doesn’t like the Avengers, right? The first movie was awesome. The second one was…still fun. And the Avengers are heroes. They saved the world.

As startups scale they go through a few phases of team building. Where companies end up varies, I’ve been a part of a few different structures and spoken with many other people as well, but there seems to be a natural evolution that takes place.

When a startup is first kicking off it’s small. There are only a handful of people, so each person is doing multiple jobs. As the startup starts to add more people, they specialize, and often this falls into functional groups. So the iOS developers hang out, the Android team is formed, the QA team organize as a functional group to counterbalance the multiple functional developer teams, and so on. This seems like a reasonable structure at first, but it tends to break down.

Functional groups are too isolated. Sure the functional skills and specialties matter, but you don’t win by focusing on these functions. You win by focusing on what matters–delivering the right product to the right people at the right time.

Some startups will put product managers or project managers in place to try and bridge the gaps between functional groups. It may work for awhile but it’s a stopgap measure. Functional groups don’t scale.

The next step in this team structure process is what I call “Assembling the Avengers” — otherwise known as project-based teams. A scaling startup realizes that it needs to align around core problems; so it identifies a few core problems and then assembles cross-functional teams to solve them. They grab a mixed bag of people from different functions, lock them in a room (I mean, gently nudge) and say, “Go solve this problem for us.”

This structure works better than functional groups because you now have more diversity and you can better debate and align each person’s interests and expertise. But here’s the problem with the Avengers–they get together when the world needs them, land in New York, tear it to fucking shreds and then walk away. No one really wants to watch a movie about the aftermath of cleaning up the mess, rebuilding stuff, etc. That’s the boring part. That’s the clean up!

Project-based teams help in a lot of ways (including improved communication across an organization), but when the project is over…who’s responsible? The team disassembles and people move onto new projects. When there’s an issue, a bug, an enhancement or just some understanding of what was done, it’s hard to re-assemble the team or even capture the core information. It’s pretty easy for people to throw up their hands and say, “I’m on this new project now, I can’t go back to that other project.” And New York is left for someone else to clean up while Captain America goes off for his solo movie project…

After experiencing project-based teams, scaling startups look for a way to maintain the same level of cross-communication, but with more consistency. And this is where cross-functional teams emerge. These cross-functional teams have the same group of people as the project-based teams, but they stick together for much longer and own something inside the project/company that’s more substantial. A few years ago, Spotify shared some awesome information about how they do this in a 14-page PDF, Scaling Agile @ Spotify. They also put together a 2-part video series (Part 1 | Part 2.)

The goal at this point for a scaling startup is to give each team ownership and responsibility. Companies do this in different ways. At VarageSale we structured each team around a portion of the user’s lifecycle with VarageSale, leveraging Dave McClure’s Pirate Metrics. So we had 4 product teams: Acquisition, Activation, Retention & Revenue/Referral. Each team had a couple of key metrics they were responsible for. The Activation team owned Day 1 to Day 7 Retention; the basic idea was that Team Acquisition got them to the door and signed up, and Activation needed to keep them for 7 days, taking key actions that we knew drove retention. The Retention team would then take over and try to keep the person active for 30 days (they owned D30 Retention).

We decided not to have teams own specific areas of the product, although some companies do take this approach. For us we found that there was too much overlap in key areas. The feed is a great example (VarageSale’s feed is a key aspect of the shopping experience.) Who owns the feed? You could argue that the Activation Team should, since members will interact with it almost immediately after signing up, but you can see how the Retention Team would also want to experiment with the feed. For some companies, the features are easier to divvy up, and you can definitely have feature-based, cross-functional teams.

At VarageSale we also had Guilds (like Spotify), which were organized across functional lines. So there was an iOS guild, Android guild, etc. These guilds also had Guild Leaders. The guilds provided a few things of value. For starters, each guild would meet to review everything that each team was building. This was helpful for improving estimates and assigning code reviews (which went across the teams). Guilds also kept up-to-date with the latest standards, best practices and code quality guidelines.

Ultimately, this felt like a good structure. (And if you’re interested I’m happy to share more information about how this worked, what went well, what didn’t, the challenges with the transition, etc.) Each team knew what they were responsible for in terms of the user experience through the product and a few key metrics. Product-wise, there were some features that were wholly owned by a specific team, but others were shared, which was fine.

The other advantage of this structure (like Spotify’s) is that it’s much easier to scale. As you grow you can build new teams and assign them new responsibilities. There’s plenty of cross-communication and collaboration, but you’re also building functional expertise within the guilds.

It’s important to note that evolving your company’s structure is not easy. There’s no question that as you scale (read: add people) efficiency drops. It seems counter-intuitive, but that’s what happens. You start to hit a certain size and the cracks start showing. And then you realize you need to reorganize and that’s a big challenge. People’s mindsets need to change. They’re working with new people, in a different way, on different teams. It’s a painful, but necessary process. If you don’t reorganize as you grow, you’ll die under the weight of a structure that simply cannot scale. So you need to look for alternatives–be it project-based, cross-functional, or something else that you think might work in your particular case.

I don’t think there’s such thing as a perfect structure. What we were doing at VarageSale was working, but there were issues too. Nevertheless, the key is to get your startup to a point where teams are efficient, understand what they own, and the company (overall) can scale effectively. And it seems like many startups go through a natural evolution from functional groups to assembling the Avengers to cross-functional teams. You don’t need to get to the “end state” too quickly, after all it is dependent (in part) on how many people you have, but you should keep a keen eye on your company’s organizational structure and scalability as you grow.

Image from PACrankyDM.