How to avoid the messy middle of cross-team projects

Product is hard. 


Every piece of work has two phases. First there’s an uphill phase where you figure out your approach. You have a basic idea about the task, but you haven’t figured out what the solution is going to look like or how to solve all the unknowns. Then after you’ve explored what works and what doesn’t, you reach a point where there aren’t any unsolved problems anymore. That’s like standing at the top of the hill. You can see clearly all the way down the other side. Then the downhill phase is just about execution.

This is what a typical project lifecycle (from Work is Like a Hill) looks like:

Cross-team collaboration on product is 10x harder. Especially when you’re collaborating across the Atlantic ocean. This is what a typical x-team project lifecycle looks like:


This x-team project lifecycle was very much so my recent experience working on a project with teams between Boston and Dublin.


So we ran a retro and noted our learnings below. 

1. Co-create solutions

Throughout the project, we noticed that we often went back and forth on the same questions, encountered skepticism with certain design decisions, and generally lacked a feeling of co-ownership. 


If we had started the project with a x-team brainstorm session prior to kicking off work and finalizing mocks, I think we could’ve: 

  • Reached alignment on general context around the problem we were trying to solve earlier

  • Potentially arrived at a better solution, together

  • Maintained a mutual understanding of the UX and expected behavior throughout the project


2. Kickoff the project with everyone involved, set clear DRIs and timelines

We had a project kickoff with both triads, but we failed to loop in our ICs. 


After finalizing designs and implementation, we should’ve formally kicked off the project with ICs involved AND set some ground rules and governance for the project like…

  • How to communicate: when to zoom, slack, workshop

  • DRIs: whose the core team, which ICs are working on what

  • Timelines


3. Beware of others joining the project midway & bring them up to speed


We had a number of team/IC changes throughout the project that led to context slipping through the cracks and it generally taking long for folks to ramp up on development. 


We should be cognizant of new team members joining and set up formal handoffs with ICs and product/design to ensure all new members have a positive experience and the same level of context going into projects. Keeping consistent documentation on the project plan should help with this too!


4. Put regular, bi-weekly meetings in the calendar


Transatlantic comms can be tricky. We should try whenever possible to set up semi-regular checkin meetings for important projects. We might not end up needing them, but it does provide a low-friction forum for us to jump on a Zoom and quickly work through problems vs feeling reluctant to schedule ad hoc meetings until they become necessary. 


I think this will also generally help cultivate a feeling of “co-ownership” as well. 


5. Spin up a project channel


We had a dedicated Slack channel for this project which worked really well! We should continue utilizing that to post regular updates, share feedback and meeting notes, regular status updates on how we're progressing against timelines, etc. 


6. Lean into bug bashes


We had two bug bashes prior to launching the feature which worked really well. There were clear action items for both teams, and everyone knew what we needed to get done prior to rollout. This definitely helped contribute to our smooth rollout!


Any other tips for working on x-team projects? Comment below!

85 views0 comments