Tech companies are known for inventing new ways of team organization. Companies like Spotify, Airbnb, and others have grown very fast from small startups to huge companies, and strive to keep the same level of freedom, creativity, and flexibility that they had at earlier stages.
An example of a company with hundreds of employees may not be very relevant for smaller teams, but there are some curious stories that you can learn from. Seeing successful companies breaking the common rules encourages to think outside the box and experiment. We’ll start with general types of team structures and then see some real-life examples.
Challenging hierarchy
A pyramid is what a typical team structure looks like. This structure is much older than project management and might be even older than Egyptian pyramids. There isn’t much to explain: we’re all familiar with it and it comes to mind right when we think of a corporate organization.
Even though the hierarchy pyramid is universal and centuries-proven, people always try to invent something new. Naturally, people from such an innovative industry as tech, try to reinvent team structure to reach new opportunities. The main objectives that drive these experiments are:
- Flexibility
- Productivity
- Empowerment
So, how can teams be structured differently? Experiments with team structure should be managed carefully. It’s like inventing new materials for building a foundation: you may want to get creative, but you won’t lay jelly for foundation. Here are some of the classical and proven team structures that are used by product development teams:
- Matrix. Team members report to more than one lead. Power is redistributed.
- Network. Separate smaller teams connected through hubs.
- Divisional structure. A big company is divided into numerous teams based on geography, market segments, products, or features.
To make things easier to understand, let’s take a look at some cases.
Amazon’s two pizzas
Amazon is one of the biggest companies in the world, and it seems to work quite efficiently. Their secret is splitting all company employees into smaller teams. In Amazon, each team should be small enough to be fed with two pizzas (now it’s known as the Two Pizzas Rule). This team size is optimal to be dynamic and respond to requests quickly, saving time on huge meetings and never-ending reporting.
Ok, but how do teams connect with each other? Naturally, such a big number of teams needs to be structured firmly. The information from one department to another should be presented in an automatic way, not in the old ask-answer way. The report of sales in a particular month from a particular region should be available in a place where everybody else in the company can access the information without bothering other employees when needed. Amazon has dedicated a lot to build a functional system that later evolved into AWS, Amazon Web Services.
Seems like perfect management, right? Well, Amazon is an example of how we should follow the methods of successful companies with caution. With all the efficient internal structure, the company has extra high turnover and complaints from workers at all levels. So, before adopting other companies’ methods, analyze all the factors and choose the things that can work for you.
Spotify squads/tribes/guilds/chapters/witches
The structure of the Spotify team seems to be a bit more complex than two-pizzas (and no, there are no witches, unfortunately). It was established in 2012, when Spotify invented this system after the initial stage of fast growth, and has been changing and evolving since then (that’s a true startup mode). In 2012, there was a highly detailed analysis of the Spotify team structure published, and here we’ll make a quick recap of it. Luckily, product team structures don’t get outdated as fast as products themselves.
Ok, let’s analyze the structure. Squads consist of a few people that represent different skills, working on the same project. Basically, each squad is seen as a “mini-startup”, a self-sufficient team. Tribes consist of a few squads that work in one space and can socialize with each other easily. The number of members in each tribe should be less than 100 (according to Dunbar’s number rule, people can maintain social relationships with no more than 100 persons).
A chapter is a group of people with the same expertise within one tribe (UX chapter, back end chapter). Guilds are groups of people of the same expertise in the whole company, such as designers guild, or web developers guild. If you are familiar with medieval guilds, you get the idea. We’ll get back to designers' guilds later.
Airbnb. Stakeholder-based product team
If you’ve read our blog a bit, you might already know that we love using Airbnb as an example. We bring in Airbnb when talking about human-centered design, value proposition, blue ocean strategy, and design thinking. The reason behind this is simple: a company founded by designers tends to go for creative solutions. Regarding product development team structure, Airbnb is also worth a mention.
Airbnb has gone through a long evolution — from functional teams to matrix, then divisional and sub-divisional, and finally they came to integrated structure. What is different from other companies is that the teams are grouped around stakeholders and the customer journey map (we had brought up famous Airbnb storyboards as an example of a customer journey map previously).
If you’re purely functional, you don’t have any ownership of a stakeholder, so the stakeholders can be left behind. — says Brian Chesky, co-founder and CEO of Airbnb.
There are teams focused on host experience, guest experience, investor experience, experience of communities, internal culture team… The HR team is called “employee experience”. At Eleken, we also don’t like to think of employees as resources — our HR manager calls herself “people manager”.
Challenges of alternative team structures
Decentralized teams are not a magic pill for all the product development issues. There are many things to be considered on the engineer’s side, but as a design agency, we’ll focus on the designer's perspective.
Small teams would often have designers in total minority, thus diminishing the leverage they have on product decisions. The second problem is that separate teams may produce designs that are not completely consistent along the product as a whole. And on top of that, designers risk being cut off from their fellows and thus become stuck with the same solutions. This is a paradox: while working along with great professionals in big companies, people constantly contact the same team fellows and are left to the same resources.
Let’s see how successful companies address these problems.
GLUEing it all together
Self-explanatory abbreviation GLUE stands for Global Language for a Unified Experience, a design system built by Spotify. This design system is more than just a set of guides: there is a team of designers that are working on GLUE, and all the rest belong to different small teams working on different projects.
That’s how designers throughout the whole company manage to synchronize and get necessary guidance or advice. They all can refer to the GLUE team, working both ways: design system establishing the rules, and designers giving feedback and suggestions that help shape the system.
A defined and working design system also helps designers to explain their decisions. In small teams where there might be just one designer, certain things are not as “clear” as they are among a group of peer designers. Developers evaluate products differently, and when they are the majority, their point of view prevails. That is where values defined by GLUE come in handy. To back up their solution, designers can refer to the values and not just their inner feelings.
In 2020, Spotify has reviewed their design values set in 2013, and fit all of it into three words:
- Relevant
- Human
- Unified
If it sounds like a generic T-shirt text to you, take a look at this image that gives guides on giving feedback based on these values (and read Spotify’s blog).
Slack. Don’t leave a designer alone
How do we make sure that designers in small teams don’t feel lonely and separated from their peers? Just give them a partner, said Slack. And since then, all the designers there work in pairs, one of them being the lead. That way, a designer constantly gets feedback and benefits from the creative collaboration process.
Eleken. Collective design wisdom
As a product design agency, we have been working with teams that have very different organizational structures. How do we manage to fit into any team? We have some rules for that.
First of all, we always insist on direct communication. We have no product managers standing between our designers and the client’s team. Eleken designers communicate with product owners, CTOs, and developers. That way we integrate into the product team and our work doesn’t get detached from the product.
Oftentimes there is just one or two designers working on the project. How do we make sure they’re not stuck with their own problems? At Eleken, designers not only become part of the client’s team, but they are also a part of a big community of colleagues working on other projects. At weekly meetings, they meet and discuss their projects, thus always being able to tap into collective knowledge and find the best solution. For any doubts, there is a UX design lead whose job is to guide and navigate designers in their day-to-day work.
To sum up. Which structure works best for you?
All in all, there is no such thing as a “correct” team organization system. Some are common, some are original and unique. What we can learn from examples above is that experimenting with product team structure is possible. When something is not going well in your product team, maybe it’s not a lack of employees’ personal communication skills, but the structure of your team that lacks space for communication?
After all the great examples explained in this article, there’s one thing I’d like to warn you from doing: don’t copy the team structures of successful companies just because they work for them. Look at the long way that Airbnb has made to get where they are. Be ready to experiment and adjust your team structure on the way. And if you feel like you’re lacking someone in your team… We can help extend it!
