6 key tips for more effective cross-pillar collaborations

Anyone who has worked on a multi-team collaboration knows that even under the best circumstances, things can get pretty tense.

Each team brings different constraints, priorities, and personalities to the table. Undoubtedly, these differences can clash if not addressed properly at the beginning of any cross-pillar collaboration.

Laying a few central ground rules at the onset might seem like straightforward common sense. However, this step is far too often overlooked or minimized – a mistake that can swiftly derail a project and demoralize team members.

In an effort to avoid such pitfalls, we decided to take a closer look at how we can make our cross-pillar collaborations at Productboard even more effective.

A group of senior engineers on the Fusion Core team conducted a thorough investigation – and we are ready to share what we’ve learned. Our findings might sound a little vague and general, but that’s because they are by design. 

They can definitely be applied to a lot of practices that are happening in a single-team context. More importantly, however, what we discovered over the last several months was that if you don’t follow certain protocols during team collaborations, you could quickly run into challenges.

Below is a roundup of our key takeaways for streamlining cross-pillar collaborations at your company:  

Direct communication

We found it very beneficial when you empower the ICs to do the collaboration themselves. It is important for ICs to discuss potential timelines, roadblocks, and design-appropriate solutions with each other instead of through intermediaries, and then clearly report their progress to the EMs.  

EMs should not be facilitating or driving the collaboration but rather, should try to help ICs clear any obstacles along the way and bring more context to the discussion. 

Single initiative engineer per party

You should appoint a single person to keep track of all the project’s technical details. They will know all the dependencies that might come up in any change management, because there will be changes. You are not able to anticipate every little thing that will come later on. 

When changes occur, you want to have that one person who can actually encompass all of those dependencies, and accommodate that change in the current context. This person should be an IC – not an EM. 

Reserved capacity up front

Blocking your capacity to support other parties during both discovery and delivery is helpful. You will likely encounter obstacles along the way that are hard to anticipate.  

If you don’t do this, it can really lead to a lot of missed deadlines, a degrading atmosphere, and in the worst-case scenario, finger-pointing, which is a lot easier to do when it’s between teams than in a single team.

Sit together

Async co-creation doesn’t work. The creative process must be synchronous. RFCs proposals and drafts are great tools to prepare asynchronously, but there’s no avoiding the synchronous creation process. 

Sit together in the same room – or on Zoom. It’s important to keep that mental presence in a sprint. 

Align your priorities

This might seem very general, but it’s very important when collaborating with multiple teams. You will probably never align your priorities between teams completely. There will always be some differences. But if those differences are quite vast, you’re going to experience a lot of friction that can lead to wasted resources.

For co-creation you need every party to be present during the design phase, so they can bring their constraints and requirements to the table. This allows catching as many future surprises as possible.

If one team is not prioritizing the shared outcome as they should, in a particular sprint, this will not work. And you’re basically back to an asynchronous co-creation.

Turn off the defense mode

This is the most transformative thing you can do while collaborating with other teams. When you’re doing cross team collaboration, it is usually a large project that is heavily affecting multiple teams. There is likely some sort of shared outcome, but each team will have their own vision for the future and want to defend their goals.

However, you have to be willing to sacrifice some of those constraints and requirements in order to move forward in a collaborative way. If you don’t tone down your defense, it can – and probably will – lead to segregation, and that is the opposite of what you want to achieve. Lead by example and solve the other party’s concerns as if they’re your own. It will ripple out and set the tone for much-needed compromises you’ll need to make along the way.

You might also like

Productboard expanding San Francisco engineering presence
Life at Productboard

Productboard expanding San Francisco engineering presence

Jiri Necas
Jiri Necas
Refactoring Productboard’s design system to the next level
Life at Productboard

Refactoring Productboard’s design system to the next level

Jonathan Atkins
Jonathan Atkins
The Role of Growth Engineering at Productboard: Significance, key skills, and responsibilities
Life at Productboard

The Role of Growth Engineering at Productboard: Significance, key skills, and responsibilities

Stuart Cavill
Stuart Cavill