Collaboration Sessions: How Remote Teams Replicate the Best Practices of Co-Location
The best teams sit at the same table. When your team is remote, you build that table yourself - every day.
The most effective teams I have worked with share a characteristic that has nothing to do with talent, tools, or methodology. They collaborate daily. Not in a status meeting where each person reads from a list. Not in a Slack channel where updates scroll past unread. They sit together - physically or virtually - and work on the most important thing in front of them as a team.
Co-located teams get this for free. When everyone sits at the same table, collaboration is the default. Questions get answered in real time. Context is ambient. A designer overhears an engineer discussing a constraint and adjusts the design before it becomes a problem. A marketer watches a product demo and starts drafting the messaging. The feedback loop is immediate because the distance between disciplines is zero.
Remote teams do not get this for free. Without intentional structure, remote work drifts toward silos. Each person works in their own context, on their own timeline, with their own interpretation of what matters most. The collaboration session is how remote teams reclaim what co-location provides naturally.
The core insight
Why Co-Location Works (and What Remote Teams Need to Replicate)
Skelton and Pais describe this in Team Topologies: effective teams need high-bandwidth communication to reduce the cost of coordination. Co-located teams achieve this through physical proximity. Every conversation is high-bandwidth by default - body language, whiteboard sketches, overheard context, and the ability to tap someone on the shoulder and get an answer in seconds.
Remote teams need to engineer this bandwidth deliberately. The collaboration session is the primary mechanism. It creates a scheduled window where the team operates as if they are co-located: same room, same context, same priorities, same clock.
| What Co-Location Provides | How Collaboration Sessions Replicate It |
|---|---|
| Ambient awareness of what the team is working on | Each team shares progress, blockers, and current experiments |
| Immediate cross-discipline feedback | All disciplines are in the session - feedback happens live |
| Shared context on priorities and constraints | OKR review and metrics check-in anchor every session |
| Low-friction coordination between people | Blockers surface immediately; breakout pairing happens after |
| Energy and momentum from working together | The session is a collaboration, not a report - the team works together |
The Ideal: One Cross-Functional Team, One Session
In the ideal environment, a collaboration session involves one cross-functional team - a stream-aligned team that has all the disciplines it needs to accomplish its objectives. Engineering, design, product, marketing, analytics - all in the same session, working on the same problem.
The team opens by reviewing their current Objective and Key Results (OKRs). Where do the key metrics stand? What moved since yesterday? What customer feedback came in? This grounds the session in outcomes, not tasks. Then they assess: what is the highest-impact thing we can do today to move the needle?
What happens in an ideal session
- Review the OKR. Check the latest metrics and key performance indicators. Where does the team stand against the key result?
- Surface blockers. Anything preventing progress gets addressed first. Blockers compound - every hour the team is stuck is an hour lost.
- Assess recent feedback. Customer feedback, bug reports, and experiment results inform what to prioritize.
- Prioritize the highest-impact work. The team identifies what experiment or update will move the key result most effectively and works on it together.
- Execute as a team. This is the part most standups skip. The team does not just talk about work - they do the work, together, in the session.
Every second counts
When team members pair on work outside the session, they bring those updates back to the group. This keeps all disciplines in the loop and prevents the dropped balls and broken arrows that come from people working in isolation without visibility into what others are doing.
The Reality: Multi-Team Collaboration Sessions
Teams that are transitioning to the Team Topologies methodology, or teams experiencing rapid growth, often find themselves in a non-ideal environment where the collaboration session includes multiple teams. A stream-aligned team and several complicated subsystem teams that serve it may share a session because the subsystems are not yet mature enough to support an X-as-a-Service interface.
This is normal and expected. Skelton and Pais describe this as the collaboration interaction mode - a high-bandwidth, high-cost interface between teams that is appropriate when both teams need to work closely together to discover or deliver something new. The collaboration session is how you operationalize this interface in a remote environment.
The table analogy
Think of it like a physical office. The stream team and the subsystem teams sit at the same table for a portion of the day. They share what they are working on, surface blockers, identify dependencies, and align on priorities. Then they break out to their specific subsystem or stream to execute with their core team. The session is the table. The breakout is the desk.
The key difference from the single-team session: there is less time spent working on a single item as a unified group and more time spent on visibility. The goal shifts from "let's solve this together right now" to "let's make sure every team knows what every other team is doing, then break out to execute."
| Aspect | Single-Team Session | Multi-Team Session |
|---|---|---|
| Primary goal | Work together on the highest-impact item | Synchronize across teams, then break out to execute |
| Time spent on updates | Minimal - the team has shared context | Significant - each team needs to share state |
| Time spent working together | Majority of the session | After breakout, within core teams |
| When to use | Mature team with full autonomy | Transitioning teams, heavy collaboration interface phase |
Evolving from Collaboration to X-as-a-Service
The multi-team session is not the destination. It is a phase. Team Topologies describes three interaction modes between teams: collaboration, X-as-a-Service, and facilitating. The collaboration mode is the highest-bandwidth and the highest-cost. It requires the most coordination overhead. As subsystem teams mature, they should evolve toward an X-as-a-Service interface where the stream team consumes their capabilities without needing daily synchronization.
Signs a subsystem is ready to reduce collaboration overhead
- The subsystem has well-defined APIs or interfaces that the stream team can consume without asking questions.
- The subsystem team has its own OKRs and can prioritize independently based on its own metrics.
- Cross-team blockers are rare - the subsystem consistently delivers what the stream team needs without daily coordination.
- The subsystem team proactively communicates changes through documentation or release notes rather than live meetings.
Until these conditions are met, the heavy collaboration interface is the right choice. Reducing collaboration overhead prematurely creates the dropped balls and misalignment that the session exists to prevent.
Running an Effective Session
Whether you are running a single-team or multi-team session, the principles are the same. The format changes, but the intent does not.
1. Start with blockers
Blockers come first because they compound. A team that is stuck at 9 AM and does not surface it until 4 PM has lost an entire day. Surfacing blockers at the start of the session means the team can resolve them immediately or assign someone to resolve them while the rest of the team continues.
2. Ground the session in objectives
Before discussing what to work on, review where you stand. What does the OKR dashboard say? What moved? What did not? This prevents the session from drifting into task-driven work that does not connect to outcomes. Every experiment the team discusses should tie back to a key result.
3. Prioritize impact, not volume
The question is not "what is on the backlog?" It is "what will move the needle most?" Sometimes that means working on one thing all day as a team. Sometimes it means identifying that no existing experiment is working and pivoting to design a new one. The session is where this judgment call happens.
4. Ship the minimal viable value
If the team is starting a new experiment, the goal is to get the minimal viable value out as fast as possible. Not the perfect solution. Not the comprehensive feature. The smallest thing that lets you start learning from real feedback. The faster you ship, the faster you learn, and the faster you can iterate.
The feedback loop trap
5. Share what happened outside the session
When team members pair on work between sessions - a designer and engineer prototyping a feature, or two engineers debugging an issue - they share what they did at the next session. This is not about accountability. It is about visibility. Every discipline needs to know what shipped and what changed so they can provide their perspective and catch issues early.
What a Collaboration Session is Not
The biggest risk is that the collaboration session degrades into a status meeting. This happens gradually and is hard to detect from the inside.
Signs your session has become a status meeting
- ✗People read from a list. If team members are reporting what they did yesterday and what they will do today, that is a standup, not a collaboration. The session should focus on what the team will do together, not what individuals did alone.
- ✗No one works during the session. If the session ends and everyone goes back to their desk to start working, the session was a coordination meeting, not a collaboration. In a single-team session, the team should be actively working together during the session itself.
- ✗Feedback comes days later. If a designer shares a mockup in the session and does not get feedback until the next session, the team is not collaborating - they are presenting. Feedback should happen live, in the session.
- ✗The session could have been an async update. If nothing in the session required synchronous communication - real-time questions, live feedback, collaborative problem-solving - then it did not need to be a meeting.
- ✗Only one discipline talks. If the session is primarily engineers giving technical updates, the cross-functional purpose is lost. Every discipline should be actively contributing.
| Status Meeting | Collaboration Session |
|---|---|
| Each person reports what they did | The team assesses what to do next together |
| Work happens after the meeting | Work happens during the session |
| Task-oriented: what is on the backlog? | Outcome-oriented: what moves the key result? |
| Individuals report to a leader | The team collaborates as peers |
| Could be replaced by a Slack message | Requires live, high-bandwidth interaction |
A Practical Agenda for Multi-Team Sessions
When a stream team is running a collaboration session with multiple subsystem teams, the agenda shifts toward synchronization. Here is a format that works for a 60-minute session with 5-7 subsystem teams.
Blockers and Bug Reports
Surface anything preventing a team from making progress. Critical bugs from users or internal testing. Cross-team dependencies that need resolution today. Assign owners and timelines before moving on.
Subsystem Team Updates
Each team shares three things: key result progress toward their objective, their current experiment or release and what they learned, and what they need from other teams. Keep each team to their timebox. If a discussion goes deep, schedule a breakout.
Upcoming Events and Journey Check-in
Any launches, demos, or deadlines that affect priorities. How is the primary user journey performing? Are current experiments targeting the right part of the journey? Connect every experiment back to adoption, engagement, or retention.
Open Floor
Cross-team pairing updates, new experiments identified during discussion, and anything that does not fit the sections above. This is where organic collaboration happens - the stream team and subsystems connecting dots that were not on the agenda.
After the session, teams break out to their core groups to execute. The synchronization window is over. Now the subsystem teams work on their priorities with the context they gained from the session, and the stream team can proceed knowing what each subsystem is delivering.
The Facilitator Role
Someone needs to run the session. In a single-team session, this can rotate among team members. In a multi-team session, it is typically someone from the stream team who has visibility across all the subsystems.
What the facilitator does
- Keeps time. When seven teams each need four minutes, letting one team run long steals time from another. Use a visible timer.
- Connects dots. When Team A mentions a blocker that Team B could resolve, the facilitator makes the connection explicit.
- Guards against status reporting. If someone starts reading a list of completed tasks, redirect: "What is the most important thing your team is working on right now, and what do you need from others?"
- Captures action items. Blockers need owners and deadlines. Decisions need to be documented. The facilitator makes sure nothing said in the session evaporates after the call.
- Asks the hard question. "How does this move adoption, engagement, or retention?" If a team cannot answer, the work needs to be reconsidered.
The Principles Behind the Practice
Collaboration sessions are not a standalone practice. They are the operational expression of several interconnected principles.
Cross-Functional Teams
The session only works if the team includes all the disciplines it needs. A session with only engineers is not a collaboration - it is a technical sync. Include design, product, marketing, analytics. See Why Cross-Functional Teams Win.
Objectives and Key Results
Without clear objectives, the session has no compass. The team drifts into task work without connecting it to outcomes. OKRs provide the "why" that makes prioritization possible. See You're Measuring Velocity Wrong.
Remote First
The collaboration session is remote-first by design. It does not advantage people in an office over people at home. The best talent is not always in your city - the session brings the table to wherever the team is.
Team Topologies
The session format maps directly to the interaction modes: heavy collaboration for transitioning teams, lighter synchronization as subsystems mature toward X-as-a-Service. The framework tells you when to evolve the format.
Getting Started
You do not need to restructure your organization to start running collaboration sessions. Start with one team and iterate.
This week
- Pick one cross-functional team. Get them into a daily virtual session - video on, shared screen, working together.
- Open every session by reviewing the team's OKR. If the team does not have one, that is the first problem to solve.
- End each session with a clear answer to: "What is the highest-impact thing we will work on together today?"
This month
- Assess whether the session is a collaboration or a status meeting. Use the comparison table above to diagnose.
- If you have multiple teams in a session, define the agenda and timeboxes so each team gets structured visibility.
- Identify which subsystem teams are ready to reduce collaboration overhead and move toward X-as-a-Service.
This quarter
- Measure outcomes. Are the teams running collaboration sessions shipping faster? Are key results improving?
- Evolve the format. As subsystems mature, reduce the multi-team session and increase independent execution time.
- Train facilitators. The session should not depend on one person to run it effectively.
Co-located teams collaborate naturally because proximity eliminates friction. Remote teams need to create that proximity deliberately. The collaboration session is the mechanism - a daily window where the team operates at the bandwidth of co-location, grounded in objectives, working together on the highest-impact problem they can find. The format evolves as the team matures, from heavy multi-team synchronization to independent stream execution. But the principle stays the same: the team that collaborates daily, ships outcomes.
Build the table. Sit together. Do the work.
Building a collaboration practice?
I've coached teams through the transition from status meetings to real collaboration sessions. Let's talk about your team's structure and how to make daily collaboration work.