Building Products Across Multiple Teams

Unless you work on a very small Product team—anything less than 10 people—you’ve experienced the need for cross-team collaboration. Here at HubSpot, our Product team is growing rapidly. This growth provides an immeasurable amount of benefits, but as these hundreds of small autonomous teams (2-10 people) build software, a challenge is introduced: how can we collaborate effectively across teams? 

This post is designed to present a simple framework to help people work better together. By implementing some of the tactics mentioned here and keeping an eye on cross-team collaboration, we believe that organizations can be more effective.

First, let’s talk about single-team projects and what makes them relatively simple. In single team projects, there is one owner, the team is familiar with one another, priorities are clear, and projects are relatively easy to technically scope. Single-team projects are almost “automatic” to well-functioning product teams and are some of the simplest to execute on.

As an organization’s product grows, though, the balance starts to shift from mostly single-team projects to almost exclusively cross-team projects. Teams become more interconnected and depend on one another to succeed. As the HubSpot Product team has grown, this has certainly been the case. 

What makes cross-team projects challenging are, not coincidentally, the same things that make single-team projects simple. Teams have less rapport with one another than they do within their own team, which can cause a lack of trust and overall effectiveness. Multiple owners are introduced, each with unique expectations of how they want the project to succeed. Finally, priorities outside of the cross-team project can be unclear. 

We’ve found that in order to make a cross-team project successful, you need:

• Basic trust between the teams involved
• Clearly articulated project management roles
• Clearly articulated priorities and timeline upfront for all parties involved

Download: Cross-Team Alignment Kickoff One-Pager

Earning trust

More than anything, trust is the foundation of the kind of partnerships that are required for cross-team collaboration. Each participating team needs to believe that the others are approaching the project with goodwill and a shared understanding of how success benefits the customer. However, many people misunderstand trust. Here’s what we’ve realized when it comes to building trust across teams: 

• Confrontation is good! It’s better to understand a mismatch in urgency (for example) upfront and use prioritization tools or a creative engineering solution to resolve it, rather than stumbling upon it when both participants have different expectations. In order to earn this trust early, it’s important that both teams are asking the hard questions, diving headfirst into potential areas of conflict, and even mapping out how and where the project has the potential to fail. 
• Come prepared. As best you can, answer pre-meeting questions and come with clear answers. You’ll save both sides time. This isn’t just for the team initiating the project, it’s for the collaborator as well! For the initiator of a cross-team project, it’s critical to identify exactly what type of preparation you expect from the other team before the kickoff meeting. And, for the collaborating team, it’s up to you to deliver on these asks and come prepared. If there isn’t enough lead time to prepare before a kick-off meeting, ask for it to be moved so that you can arrive with exactly what is needed to succeed. 
• If possible, invest in a relationship. This becomes harder as teams grow in size, grow across time zones, or work in multiple locations. But, if at all possible, start a major cross- team project with a social event, not a planning meeting. Make sure the social event is at an equal scale to the project being delivered. If you’re working together on something for a full year, host an offsite. For a full quarter, host an after-work event. For two weeks, have lunch together. All of these events will provide team members an opportunity to get to know one another, which will lubricate cross-team interactions for the entirety of the project. 

Understanding roles 

Finally, the project needs a "lead team" and a "follow team". If there are five teams involved, there needs to be one "lead team" and four "follow teams". 

Usually in a cross-team project, there are usually two groups of people: (1) the group that initiates the conversation and the idea and (2) another team whose collaboration is required. If we want to set the project up for success, there are a number of questions that need to be answered and roles that need to be filled.

The initiating team is the ultimate decision maker and should control speed, scoping, and own the release. For what it's worth, we have seen a "follow team" effectively take over as the lead mid-project. It works. It just needs to be communicated clearly and understood by everyone involved. 

Between the lead and follow teams, make sure the following roles are filled by at least one directly responsible individual (DRI): 

• The Project Manager: Who’s responsible for making sure that the work continues to move along and manages any inevitable shake ups?
• The Researcher: Who provides answers to questions that arise throughout the process? 
• The Communicator: Who is responsible for communicating changes or new features to customers? If the project touches even more teams, who is responsible for communicating with those teams?
  
• Specific Project DRIs: Each discrete aspect of a project should have a single dedicated DRI. This individual is responsible for the overall delivery of that piece of work from beginning to end. Oftentimes, these are the technical owners but can also be the design or product team members in certain cases.

Understanding priorities

No team works within a vacuum. There are constantly things that arise that can delay or potentially even enhance the delivery of a project.

It’s critical for each team, whether they are the initiator or the collaborator(s), to understand their own priorities/roadmap clearly. Without a clear understanding of priorities, teams can unintentionally over-commit, avoid any type of commitment, or develop resentment if they don’t understand how a cross-functional project fits into their overall mission. 

One of the best ways to communicate priorities is to carve out a meeting early on—it can be short (20 - 30 minutes)—for each team to share their roadmap at a high level. Think months and quarters, rather than weeks or sprints. It may not seem important to inform the other team about the work you are taking on outside of the project at hand, but it is. Understanding the context that others teams are working in helps each team involved empathize when something is taking longer than expected, when teams may seem distracted from the cross-team project at hand, or when there’s a mismatch of urgency.

Having shared team priorities, it’s important for the initiators to make sure that everyone is on the same page about two major questions: 

1. Does each team clearly understand the scope, impact, and value of the project?

The onus is on the initiator to help the collaborators make sure that everyone involved in the project has the basic information they need to prioritize their contributions and communicate to their other stakeholders why participating in this project fits within their larger vision/mission. It may seem redundant, but many projects fall apart because of simple miscommunications at the earliest stages of the project.

2. Does each team actually want to collaborate actively on the project?

In the same vein as the previous question, just because a kickoff has gone well doesn’t necessarily mean that each team is whole-heartedly committed. It’s up to the initiators to make sure that collaborators are actively bought in, rather than just assuming that because another team likes the idea that they are on board with the entire project plan. More than likely, they aren’t! And that’s ok. Uncovering mismatched expectations, unbalanced priorities, or disagreements/confusion around implementation upfront is common and healthy.

Conclusion

Cross-team projects aren’t easy, and as organizations scale they grow even more complex. In order to set up a project for success, it’s paramount to dedicate focus and energy on the process even more than the project. Trust, a unified understanding of roles within the project, and a shared empathy for priorities will help make these tricky projects easier to execute.