Effective Cross-Functional Team Meetings

  2025-08-21
  5 min read

TL;DR
Breakout rooms are a simple, scalable mechanism for EMs to run efficient cross-functional meetings: disciplines focus in their own rooms without distraction, yet remain within quick reach for collaboration.

The Inefficiency Loop

If you’re an Engineering Manager (EM), then you’ve had to bring the entire team together in a meeting for project kickoffs, planning sessions, and more. You and your Product Manager (PM) may lead/open the meeting with its purpose and goal, but eventually you’ll hand off to your Engineers to discuss effort and implementation details.

However, if your team is cross-functional, i.e., a team with engineers from multiple disciplines such as frontend, backend, data, and more, then in each moment during the meeting, the specific topic being discussed only concerns a few people in the meeting. Others often tune out, wasting time. Should you have a meeting with everyone in it, or separate meetings for each discipline?

Regardless of your choice, you’ve undoubtedly heard one of these (if not both) feedback before:

Meetings are inefficient because everybody is in the same meeting. We need to wait for others to finish discussing their stuff before we can discuss ours, and then it’s their turn to wait. They’re a big waste of time.

Meetings are inefficient because the right people aren’t in the meeting. Whenever we require input from absent engineers, we must leave some topics unfinished and pending for future discussions. Stuff never gets done.

Engineers resent wasted meetings. They don’t just waste time — they erode trust that leadership values engineers’ focus. Full-team meetings in engineering often get bogged down as specialized topics (e.g., frontend styling issues, backend scaling, data pipelines) don’t concern everyone. When one group dives into details, others tune out, and context switching makes meetings drag and lose focus.

However, having separate meetings is not ideal either, as these specialized topics are small interdependent parts of a whole — a new UI may require more data to be delivered from the backend; new data insights need to be reported back to the backend via specialized contracts; and so on. Decisions cannot be finalised without engineers talking to their missing counterparts, dragging timelines.

Breakout Rooms to the Rescue

Breakout rooms let each discipline meet separately, staying productive while still within quick reach for cross-skill questions. Here’s how it works.

Say you have a team of eight engineers, spread between frontend, backend, and data. You work alongside a Product Manager (PM).

When you start a new remote meeting, you are all in the same main virtual “room”. This is where you kick off the meeting.

To hand over discussions to your engineers, you now need to set up breakout rooms. Both Zoom and Google Meet support this feature. Create one room per discipline, in the simplest configuration possible, naming it clearly and allowing people to join and leave freely without pre-assignment. You then ask your engineers to join their respective rooms. You and your PM stay in the main room so the engineers know where to find you for questions.

Inside each breakout room, the participants can only see and hear themselves, enabling focused discussions. They can, however, join other rooms for further collaboration.

In a Nutshell

Breakout rooms should give you the best of both worlds, improving team morale and delivery speed. It is one of several mechanisms I’ve applied at scale, including during my time at Farfetch, to balance autonomy and alignment in cross-functional teams.

The good:

• Focus: each group addresses its own work without interruptions.
• Cross-collaboration: each group can reach out for multi-skill discussions.
• Efficiency: overall meeting time is shorter and more engaging.
• Improved retention: removed a common frustration that drives attrition.
• Better organizational scaling: this technique adapts well to any team size or number of disciplines in the team.

The bad:

• Works best with high-performance/autonomous teams where engineers can be trusted to work on effort and implementation details without your oversight. If this is not your team, you should float between rooms to observe and coach.
• Risk of silos if your engineers still need coaching on team collaboration and sharing. If required, rotate people across rooms, or bring them back together to the main room at the end, for sync points.
• Can feel artificial in very small teams where everyone overlaps. If this is your team, keep everybody in the same main room, as usual.

At scale, tools like breakout rooms are not just about meetings — they’re about reinforcing a culture of autonomy with alignment, where engineers move fast, stay aligned, and still act as one team.