We’ve Changed Our Product Team Structure 4 Times: Here’s Where We Are Today

Hi there! This is an older post that we’ve kept around for transparency but that means that sometimes the information is no longer accurate. Head to our homepage to view our most recent posts.

How do people work best together?

It’s fun to think about. You may know some things about your own work style and productivity preferences—for example, do you prefer solo or team projects? Being in the middle of many tasks or finishing one before going on to the next?

Now, take all those unique factors about how you work and multiply them by 50, 100 or 1,000. Figuring out how to get teams working together optimally is an insanely big job.

It’s one we’ve been working on recently at Buffer as we’ve grown quite a bit larger and faster than ever before.

Here’s a look at how we’re evolving one of our teams—Buffer’s product team—and creating a blueprint for the future of teams at Buffer.

The evolution of our product team

Buffer is a product company at its heart, so it feels fitting to tell the story of Buffer’s team structure evolution through the product team.

Version 1: One team for everything

Not too long ago, there was only “the product team.”

They did everything: Every Buffer plan, every Buffer platform, all the extensions, apps and extras. They had no choice but to move fast, and there were few enough team members that there was plenty of room to maneuver.

“It’s been quite fragmented in the past,” said Joel. “We spent a lot of time putting out fires and keeping things from falling through the cracks.”

As we’ve grown larger and started exploring different types of management structures, we’ve been able to experiment with various team styles.

Version 2: Decision maker model

Based on the decision maker structure, we first created holistic teams (made up of many different members of Buffer from various areas and specialties) that looked like this:

This version of team organization was promising! Asking for advice kept the teams’ members in communication, and distinct areas of development and responsibilities began to take shape.

As we began to journey deeper into self management, though, we wanted to move toward an emphasis on opening up any area to any teammate and being less prescriptive about what roles might belong to whom. (You can read lots more about what we learned from this experiment.)

Version 3: Fluid task forces

As a result, we next experimented with task forces. These were fluid, dynamic teams formed for a specific purpose (for instance, developing Buffer for Video)that could be proposed or joined by anyone at Buffer, regardless of role.

For example, someone could be an engineer in a few product development task forces, but could equally be part of a customer service task force or a hiring task force. Here’s a list of some task forces that were on our list during the time these were our organizational default:

Over time, we began to crave a more sustainable way to work—one that would allow us to focus in an area and become specialists, with ownership and accountability.

“Especially as a distributed team, we have to be a lot more disciplined that other companies,” Joel said.

How we work today: squads and chapters

Meanwhile, Joel had discovered the innovative way that Spotify organizes its teams—with autonomous, collaborative squads, each aligned with a unique purpose.

What we had naturally building toward had a track record, and a name! This concept has proved to be the winning way to look at things for our journey so far.

Version 4: Goal-focused squads

Today we have a variety of small teams with many different priorities within the Buffer product. Here’s a look at all the different areas in which we’re working in, each of which has its own devoted team:

Each team generally comprises 1-2 engineers, a product specialist, a designer, a customer development teammate, and oftentimes a growth analyst.

The teams are organized according to the squad model, as explained by Hudl in a super handy post:

Together, this group has its own syncs at least once or several times a week.

And for a bit of a different looking squad, here’s the happiness version:

On the product side, this new structure has allowed each squad to move quickly and produce lots of cool new features in a relatively short amount of time.

“It’s been fun because we’re doing better in each area and moving things faster,” Joel said. “It’s better for discipline and focus. We’re learning it’s better for each part to move quickly.”

Plus role-based chapters

Defining each squad’s makeup so specifically has also allowed us to dive deeper not just into Buffer’s various pieces but also each role’s speciality. Designers get together, engineers sync up and learn from one another across their squads. Hudl calls these groups “chapters.”

If squads are about goals, chapters are about roles. Cross-squad chapters can go deeper into their specific area and keep learning.

“Sometimes I drop into the design circle and it’s crazy to hear the specifics of what they’re talking about,” Joel said. “What should the color of the primary button be, spacing between the elements. It feels great to form a design culture.”

(When we get a bit bigger, we might see tribes and guilds also. Exciting!)

Evolving the rest of the team

Not only does this arrangement help us create specialists with great ownership of the challenges they’re working on, it also shows us exactly where we need to grow the team in order to be at our most effective.

We feel really good about this team framework for the future of Buffer, and we’re slowly building toward this type of squad-chapter makeup across the rest of the Buffer team.

It’s a more modular way to build teams, and it’s been really instructive as we figure out what the future of Buffer looks like—and how big it might become.

Here’s a look, for example, at a snippet of how this structure might look in the Happiness area in the future, from our in-progress hiring blueprint.

A journey in progress, not a journey completed

Could things change again as we grow? Yup, it’s pretty likely! We’re constantly learning more and evolving. As Spotify puts it, this is a journey in progress, not a journey completed.

“There was a point where I thought, ‘We just need to grow so fast,'” Joel said. “But you can’t switch to the perfect setup in one day. It’s just part of a process.”

It’s exciting to keep going with the process and discover where it might lead us.

How do you work best in a team? Would you prefer to be involved in lots of projects or know one area very deeply? What do you think of the squads and chapters model? We’d love to hear from you in the comments!