Working in an organisation across multiple continents, roles and functions requires exceptional ways of working together that take into account completely different viewpoints and domain-specific knowledge. Depending on the cultural context, people are more or less keen to speak up, be the centre of attention or criticise, which means that special ways of working together are required to overcome these differences.
This approach, while it can be applied to any process, is one I have been fine-tuning over the years to work specifically with engineering teams, but it can also be applied to a group of designers, researchers or others. The whole point is not only to “hand over” work, for example, from design to engineering and then to QA, but to build in touch points where work is being reviewed and adjusted together, taking into account all viewpoints. That doesn’t mean we are looking for consensus at all points, but opinions are being heard and fed into the final design.
Working with cross-functional collaboration is particularly useful for team leads and engineering managers, who are responsible for scoping and planning work, but don't have direct authority over every domain involved. Sometimes, even after a planning session, you have the feeling that something important is missing, because a risk was not named early on. Working together closely can help to understand that instinct.
When I'm scoping an MVP with a product team, I, as an engineering manager, am not the one who oversees the complexity of everything we build, but I need to work closely with designers, engineers, QA or community specialists, etc., to get the full picture. People from all roles have relevant input from each of their functions with their own domain-specific knowledge. My job as a leader is to create the conditions where that knowledge can surface before it becomes a risk no one flagged, or a deployment that has to be rolled back later.
This is what cross-functional collaboration means to me in practice: inviting people to the table and truly codesigning a product together.
The problem with most planning sessions
Most cross-functional meetings have a challenge that needs to be addressed. The loudest voices drive the conversation. The people who want to think before they speak, often your most careful, most experienced engineers, hold back. And consequently, during a collaboration session the consensus on a plan is shaped by whoever was most comfortable talking fast. And that is not because quieter people don't have something to say, but because the format of the meeting didn't give them a way to say it.
Designing the workshop differently
When I'm running a cross-functional scoping session, I think about it in three phases.
Session-prep:I share the agenda and key questions in advance with an invitation to prepare. What are the riskiest assumptions in this project? What would make this harder than we expect? What's the simplest version of this that would still be meaningful?
When people know what's coming, they arrive with something to contribute and they know if the session is for them. The session is a way to bring together prepared thoughts, not an improvised brainstorm where confidence counts more than insight.
During the session:
The session has two distinct phases, and I keep them separate intentionally.
First, we diverge. Everyone writes on virtual sticky notes (even async if the team is very distributed), a shared doc, a whiteboard, the medium matters less than the principle: ideas get written down filtering, without debate, without one person's framing dominating. The object here is that the writing creates a brief but important equality. No one's voice is louder than anyone else's on a sticky note.
This phase is especially important for people who are less inclined to speak up in group settings. The writing gives them a vehicle.
Then we converge. We read through what's there, we group ideas, upvote, discuss and talk. Now the conversation has something to work with, a visible, shared surface of ideas rather than reconstructing whatever the most vocal people said. We sort by what's most relevant to our context, surface the risks worth discussing, and move toward a shared understanding of scope.
Session outcome:
What comes out of this kind of session is genuinely different from a meeting that wasn't designed this way. The engineers who know what the edge cases are have contributed them and will allow us to adjust technical design and specifications. A quiet team member might be aware of a dependency no one else noticed.
This approach doesn't always run smoothly. In highly distributed teams, the async diverge phase can stall when people don't feel psychologically safe enough to write down half-formed ideas, especially if there's a culture of experts taking the lead, where people only want to contribute when they're certain. I've also run sessions where the convergence phase collapsed into the same dynamic I was trying to avoid: a few confident voices pulling the group toward their framing before quieter contributions had been properly surfaced. What I've learned is that the method only works if I, as a facilitator, actively protect the process, i.e. slowing down convergence, naming contributions from people who haven't spoken, and being willing to say "we're not ready to decide yet."
Why this matters beyond the MVP
The way a team member plans its work has an impact on how they implement it. Coming together to plan the work can provide a sense of ownership and predict future challenges. When people know their input was actually part of the decision, they look at the work differently. They understand the tradeoffs and trust the scope more.
Cross-functional collaboration has actually been proven to lead to more innovative solutions. And like most technical design problems, the answer should start with: who are we designing this for, and what problems does it solve?
These are the questions I keep coming back to every time I prepare a workshop, a process, or a team.
