Practices for effective cross-team collaboration in engineering

This interview is part of our Fieldnotes series, where we share how industry leaders are improving different dimensions of the developer experience. In this interview, Nahi Ojeil, VP of Engineering at CaptivateIQ, outlines the principles he’s established for working effectively across teams. 

‍Cross-team collaboration isn’t something leaders need to think about in the early days. It’s when you start formalizing teams around areas of ownership that this needs to be top of mind. No company can be perfectly split into silos of teams that never interact (nor would you want it that way). 

At that point, leaders will need to give people the tools they need to make good decisions at scale. They don’t necessarily need to establish process, because we want people to understand the reasons for working in specific ways and not dictate the exact solution they take. Instead they need to establish principles that teams can use to know how to work with other teams. Here are the principles I’ve used in different companies: 

1. We optimize for the same company

There are a few principles we follow in our company for cross-team collaboration, but I always start with this: everyone needs to understand that we’re optimizing for the same company. There’s a single company, with a single set of overarching priorities and goals. 

That’s an important principle to ingrain in every single person. Because when they encounter a situation where there are different priorities, there’s still an understanding that those priorities aren’t “competing.” There can be different priorities, but we can always ultimately answer which one is right for the company. 

One tactic here is to encourage internal mobility. If you’re an engineer and have moved between different teams, you’re more likely to look for dependencies, ask questions, and reach out to different teams — because your identity is not as tied to a single team. In practice, we do this by: 

1. Having internal programs that the People team runs that encourage people to apply to available roles.
2. Running employee assessment and talent mapping exercises as an engineering leadership group, and flagging people who may benefit from trying something different. That’s either because they’ve been in a role for a long time or because they’re in a role that’s not a great fit for them. 

2. We identify the core dependencies upfront

This one is a balance: it’s hard to identify every single dependency before starting a project. It can be time consuming to the point where that level of planning may be a worse option than simply finding and working through dependencies during the project. Also, as a leader, you don’t want to push a culture that’s overly focused on de-risking things. That can create an environment where there’s fear around pushing forward without getting all the answers first. 

But what we can do, within each team’s cadence of planning, is identify the biggest dependencies on other teams. 

A couple of tactics have helped us identify dependencies on other teams and better manage them: 

1. We use a template for kicking off a project, and that template explicitly asks you to assess your major dependencies. 
2. We also try to include the teams that are dependencies in that project’s kickoff. It helps those teams to feel more included in that initiative. 

3. We’re comfortable escalating issues         

Being comfortable with escalating issues and asking for help is a skillset that very few teams have. Leaders need to make sure it isn’t taboo, because these issues happen all the time: one team doesn’t prioritize a task for another team, or they’re slow to get it done, because they don’t see it as being the priority. 

There are a couple reasons teams are often not great at escalating: 

• They’re trying to be nice and collaborative. Sometimes they’re collaborative to the point where they’re unwilling to realize that the project’s not going anywhere. So the reluctance towards escalating something is coming from a place of goodwill. 
• Also, people worry that escalating is a negative thing. They worry they’re putting the other person or team in a bad position. Or it’s a sign they personally failed because the expectation is they should be able to figure things out on their own. 

Unless there’s a good understanding of the value of escalating issues and how to effectively use escalating as a tool, teams won’t do it as often as they should. 

Leaders should also be mindful to model the behavior of escalating things well. They shouldn’t act like there’s never friction between them and their peers. I’m not always on the same page as my peers, but that’s not a sign things are bad. It’s a sign that we all have our own perspectives and we need to figure out how to get to a good outcome together. So as a leader, if I can show to the team how I’m escalating things — instead of hiding it — that can go a long way to helping teams become more comfortable doing it too.  

One final note: sometimes there are communication gaps, where a team doesn’t communicate their ask in an effective way. It can go a long way to coach teams on how to communicate their priorities—for example, it’s much more effective to help the other group understand the problem instead of giving them a specific solution. 

4. We plan for unexpected things to come up

I like to make sure every team is expecting unexpected things to come up when they’ve done their planning. Someone is going to have a dependency on you for an important project, and you didn’t plan for it. If teams don’t buffer for these smaller dependencies, they’re setting themselves up for failure. 

Now, if there’s a pattern where either 1) dependencies are extreme — there are so many of them that it’s constantly hard to prioritize, or 2) one team in specific is constantly a dependency, then leaders should consider whether they have the right org design. Instead of figuring out how to improve the collaboration across teams, consider whether the strategy behind how the organization is structured is working. 

5. Every initiative has an owner that’s responsible for driving it forward

There’s always a single person that’s driving an initiative forward. Even if they aren’t currently working on the initiative, and another team is, they’re still responsible for moving it forward. That sense of ownership isn’t passed off to another team. If they get blocked, they need to resolve or escalate it. The owner must drive the project through to the end.