It’s been a few years since the “Spotify Model” became the latest trend for structuring an engineering team. But, like its predecessors, the model based on tribes and squads has some pitfalls. How to structure an engineering team is a question that’s been covered at length, from the strengths and weaknesses of common team structures to a matrix of organization based on risk and scale to why you should choose your own model.
The main goal of an engineering team structure is (or should be) to balance trade-offs to maximize effectiveness. (See sliders graphic below.) For instance, technology teams might be organized around front-end or mobile development specialists, matrix teams are cross-functional but report to different managers, and product teams are cross-functional teams who report to the same manager.
But knowing when and how to change from one setup to another is complicated, and engineering leaders are compelled to evaluate their team structures regularly. To get at the crux of all this forming, storming, and norming, we reached out to these engineering pros: Asanka Jayasuriya, SVP of engineering at Invision; Steven Chen, Engineering Director, Platform Ecosystem at Slack; Tina Schuchman, Director of Product and Engineering for Ecosystem at Dropbox; Karl Mendes, former CTO of Darbysmart; and our very own Stephen Deasy, Atlassian’s Head of Engineering, All Teams and Platform.
If you’re struggling to decide if you need a change, or which engineering team structure to organize for successful execution of your strategy, consider these questions, trade-offs, and best practices before making the next move.
Tweaking the “triad”
All the leaders we reached out to use some form of structure that unites three core competencies. Atlassian and Invision have teams which consist of a representative from design, engineering, and product. Asanka Jayasuriya from Invision describes it this way: “It’s three legs of a stool: product, engineering, design. In ‘Trios,’ every piece should be involved. It scales up through product, and has peers in every branch.” In many orgs, design often isn’t given equal weight. “Since design is at the core of what we do,” he says, “we feel design needs an equal seat at the table.” A common challenge in this traditional “three-legged” setup, however, is decision-making.
At Dropbox, the competencies are the “3Cs” – Content, Coordination, and Communication. And Slack uses a mix of small team triads who work together with other teams within their organization. “At a high-level, ours is a ‘business unit’ setup,” says Steven Chen. “The base unit is triad, and we have pseudo tribes, and guilds. But we don’t necessarily call it that.”
All these teams follow some version of the “basic” structures, but they’ve experimented and tinkered and iterated a lot to find a system or model that works for them.
In other words, though the triad model works well for these organizations, generally speaking, all continue to iterate to balance trade-offs around speed, scale, autonomy, and people.
Team structure to execute at scale
If there’s one driver of team structure, it’s executing at scale. With any small company or small team, at first you’re just that: the team. Your goals, needs, and problems – and personnel to match – are right in front of you, literally and figuratively. But what happens when you scale from ten people to 50, 150, 300, and more? When you grow, team organization suddenly becomes paramount. How do you prioritize? How do you test and measure? Now, you’ve got teams of engineers and designers, not just one team. Dunbar’s Number explains that there are turning points at each organization size, and at approximately 150 people, most organizations feel strong growing pains.
Atlassian’s Stephen Deasy talks about a common mindset shift. “When the team has 15 people, the manager can probably physically see everyone. They can look over their monitor to talk to people and they generally know what each person is working on. At 40 people, team members are sitting on a different floor or in another building. You might have a bi-weekly sync to talk about big milestones. But when you get to 150 people, teams interact on a more transactional basis on projects, and the overall group starts to feel less like a coherent team with a shared mission.”
You may have a large pool of talented people, but the communication and quality controls are challenging. Thus, the need to evaluate, and reevaluate, the team structure and adapt as needed.
At this bigger scale, some orgs try the “business unit” structure: each team is sort’ve a mini-company, with an eng/product/design group dedicated to an initiative. This can create more focus, but with the higher level of autonomy, there’s less control. Then there’s the “Spotify” (or matrix) model, which alters roles for leads and managers, who become people managers and not product leaders. These teams set goals and pursue them on their own. Leaders are coaches to that team, but don’t sit within the team. But, executives can get uncomfortable because they sometimes don’t know what’s getting built, they only know what problems need to be solved. It requires a lot of communication and managing up to be successful.
“Organizational changes will never be perfect,” says Dropbox’s Tina Schuchman. “It’s always a tradeoff. It’s a balance among aligning product goals, coding efficiency, and morale.”
“You can have all these ‘names,’ but every org is unique,” adds Steven Chen. “Your business is unique. Every concept is unique. Everyone says they’re agile, but no one’s ‘Agile.’ Buzzwordy and strict ‘agile’ is great, but not easily adaptable to everyone. You’re going to know best what your team needs.”
Before you reorg iterate on your team’s structure…
“As an org grows,” says Karl Mendes, “it needs to grow and adapt. Many stick to the old way too long.”
Before structuring (and restructuring) your team, keep some basic principles close to heart. You’ll have a much higher success rate, and you won’t go blindly and change for change’s sake.
As Steven Chen says, “We do a mini-reorg every year. Almost on schedule, but not on purpose. We’ve done it because priorities change, depending on what we’ve built and get the right people on the right problem.” He emphasizes the inevitability of change – and the need to embrace it. “Teams that are flexible can do different things,” he says. “They’re very responsive and flexible. If you keep doing the change, people get used to it. Because, think of it: add one new person? That’s a new team. Change is always happening.” Teams are too often considered static things and should be more dynamic.
“There are two competing philosophies around reorgs,” says Tina Schuchman. “The first is that they revolve around people – identify the leaders in the org first, and then build teams around them. The other way is to start with product goals, and then slot in people. Obviously there’s a bit of push and pull, and you need to make sure you design an organization that has clear goals for each product area as well as the right leaders to lead these areas. My personal approach is to start with product goals, then align this to the people I have on the team. I can make small adjustments if they make a big impact to key people. However, if I start with people, I tend to find a suboptimal solution for the business.”
Atlassian’s Stephen Deasy always goes back to first principles. That is, strategy, structure, people. “Structure around strategy first,” he says. “What are you trying to accomplish? Then solve for the organization: how will you execute? Then take a look at the people you have. They have different skills and experience, and moving people around might have unintended consequences. For example, if a leadership role opens up, do you move someone into that role that might be lacking some experience, but allow them to stretch, or do you hire someone from the outside? But if you bring in another person, have you blocked the growth for your current employee? These are all trade-offs you have to think about when moving people into different teams.”
6 tips to consider before changing your team’s structure
- Understand the problem. You must diagnose the problem before you can solve it. In other words, if you can’t name the problem, you can’t solve it. Is it a communication problem? A collaboration problem? A lack of direction? Achieving clarity here and really understanding what you’re trying to solve is more than half the battle. Stephen Deasy advises looking for patterns in your retrospectives, running regular health monitors and plays (like roles and responsibilities), and to consider bigger shifts that show up in annual or bi-annual vital signs surveys that look across the company.
- Who’s the audience? Always center decisions on your end users, your customers. Involve your leadership team, but also a wide variety of people in the organization to gather ideas and co-create a picture of the desired future state. It’s better to focus everyone on the long-term mission of what you want to build, rather than shuffling to the latest management trend or cool new project.
- Don’t make change a big deal. If you create an expectation that change only happens once every two years, it emphasizes the severe impact. But if you make smaller iterations, you’ll probably find better designs and people will be more comfortable with change. Instead, team structure updates should be driven by changes in organizational size due to growth and hiring, and updates to strategy (at Atlassian, reorgs usually happen just after annual planning, because we’ve nailed the strategy, now we need to execute by putting together the right teams). New team formations are hard, but it’s helpful to get different expertise. Steven Chen says, “If you embrace change, you become a better collaborator, better engineer. We deal with change all the time. PTO. Deadlines. Don’t focus on the “change” necessarily, because you get caught up in it. Change is growth. View it as a positive. It’s an opportunity.”
- Decide who decides. Equal seats at the table sounds great on paper, but … who decides? “Be really really clear about who owns each responsibility and who contributes,” says Asanka. “Who decides if a thing is good enough?” Those subtleties become harder and harder at scale, so make sure roles and responsibilities are crystal clear. Make them very specific.
- Create room for experimentation. There tends to be a lot of creativity in products, but teams are more afraid to experiment in organizations. “We can’t be afraid to make changes,” says Karl Mendes. “We need to iterate on it, like we iterate on a product.”
- Over-communicate. There’s a human cost in these changes so, especially as leaders, knowing priorities and communicating – even over-communicating – is critical. Make sure you understand the why and be very clear that it’s the right thing to do. “They’re (changes) not free,” says Asanka. “They have costs, so make sure you understand what it’s going to cost. The biggest heartburn is changing managers, which after a few times in quick succession leads to attrition. It can erode trust, because managers are responsible for career paths, compensation, and how you’re presented up the chain.” The best solution is to communicate frequently and openly about all aspects and consequences of changes.
The case for continuous improvement
Change is constant, and never easy. As teams form, and reform, it’s really important to know why you’ve decided to try a certain team structure. Most team structures have basic commonalities and, like anything, it’s helpful to know the rules before you consider breaking them. That is, being familiar with the setups of other engineering orgs gives you more reference points, and can only help you select what’s best for your team.
But boil everything down, and you arrive at this: find your own “organization-context fit.”
No team works the same way, or needs the same things. By nature, a team – a good team – understands that it should do things for the benefit of the team, not strictly to adhere to some “organizational model.” The goal should be to develop a culture of high trust and a willingness to iterate and make adjustments. This means Open cultures of trust, radical candor, and the growth mindset. Combined, these touchstones propel teams into more fertile territory.
To enable agility in an organization, empower your leaders and teams, and leave top-down management for the history books. No pre-existing model that you copy will fix all problems. First, know your team. Then know your problem. Only then can you make needed adjustments based on established models, you, and your team’s dynamics and goals.