Remote teams can hire from anywhere, which seems like a big win, but because collaboration requires doing the work together—or at the very least, having short feedback loops between team members—it’s near impossible to collaborate with big time zone differences.
In this episode, Richard explains the distinction between collaborating and coordinating, when to do one or the other, and the implications for team structure, tools, and geography.
Learn More
The Art of Great Facilitation: Techniques for Leading Engaging and Productive Meetings (virtual, instructor-led workshop on Aug 22)
Episode Transcription
Richard Lawrence
Welcome to the Humanizing Work Show! I’m solo for this episode, as Peter is on vacation this week.
In this episode, I’m going to be introducing (or perhaps reviewing if you’ve heard us talk about this before) a concept that shapes how we recommend teams get structured, how team members work together, and what kind of relationship to have between related teams. And that’s the distinction between collaboration and coordination. I’ll explain how we use those two terms and I’ll apply them to a few common questions we hear from leaders and teams.
Before I get into that, though, a few quick reminders:
Number 1, if you have a question or challenge you’d like to hear me and Peter address on the Humanizing Work Show, send us an email at mailbag@humanizingwork.com. We read every message we get there, and they help us ensure the show talks about what you care about when it comes to your work.
Number 2, you hear this on all the shows you watch or listen to, I’m sure; but it really does matter. If you find our content useful, liking episodes, subscribing to the show, leaving a review on iTunes, sharing it with your colleagues—all those things help the right audience find and benefit from the show, and we really appreciate it.
Finally, Number 3, the show isn’t the only free weekly content we produce. We also send out a newsletter with one key idea every week. Want to get on that list? Sign up at humanizingwork.com/hwnews.
Alright, on to today’s topic: collaboration vs coordination.
When we say “collaborate,” we mean two or more people actually working together on something. It’s right there in the word: co, together; labor, work. Co-labor. Work together.
Now, that work might involve literally working on the same thing together at the same time. Yesterday, for example, one of my sons and I collaborated to assemble some furniture. We were right there side-by-side working on the same task the whole time. Similarly, I’ve done a lot of pair programming over the years. Two of us working together on the same piece of code.
But collaboration can also be a little less intensive. When Peter and I collaborate on something, it’s often more like this: We’ll both be working on, say, a new module for a course. We’ll get on a Zoom call and work closely together to figure out the module design. Then, I might focus on the workbook pages for a while, and he might focus on the Miro board. While doing that, we’re both available to review and discuss what the other person is working on. We expect that things will emerge in our task that affects the other person’s task, and vice versa. Sometimes, we even leave the Zoom call running but go on mute. We’re still working together on the same larger task at the same time, but we’re not pairing on it. That’s still collaboration as we use the term.
On the other hand, when we say “coordinate,” we’re talking about planning the work together but doing the work separately. Again, you can see this in the roots of the word itself: co, together; ordinate, put in order. What do we do together? We order the work. We make a plan.
Peter and I coordinated the work for this episode. We made a plan together: I’d script and shoot the episode while he was out on vacation, and then he’d oversee the video and audio production at the end of the week. Peter doesn’t need to be available or really even involved in my work, and I likewise don’t need to be involved in his.
So, when do you choose one mode of working vs the other? When should you collaborate, and when should you coordinate?
Well, collaboration is the right move when the work has some complexity to it, when there’s interdependence, when things can emerge, when you’re going to learn about what the work is as you do it. That emergence requires different people to work more closely together. It benefits from shorter feedback loops. And even if we made plans for that kind of work, they’d tend to get blown up pretty quickly. Coordination is the right approach when the work is predictable, especially when the relationship between my work and your work is predictable. For example, in the case of producing this episode, we know from reason and experience that the shooting comes before the editing, and we know that it’s really rare for something to happen during editing that causes us to have to change the script or to reshoot something. So, we can predict that my work will come before Peter’s. We can coordinate that.
If you’re familiar with Dave Snowden’s Cynefin sensemaking model, as many of our clients are, we could say: you collaborate in the complex domain, you coordinate in the complicated domain.
Now, this has huge implications for team structure because real teams are one of the best contexts for collaboration. When you’re on a dedicated team with a shared purpose, it’s easy to align your work around that purpose.
Collaborating across teams, though, is difficult or impossible. Because that other team is oriented towards collaborating around its own shared purpose. It’s disruptive when something from outside that team interrupts the work.
Coordination between teams works really well. “Our team is going to work on X, your team is going to do Y, here’s the relationship between those things, here’s how we’ll keep each other up to date.” And then off we go separately.
So, we strongly recommend locating complexity within the team boundary for the easiest collaboration. Let complicated things span teams. Avoid complexity spanning teams. And, by the way, if you organize teams around complexity today, a year from now the complexity may have moved, and the old team structures that worked really well may not be working anymore. People may now need to collaborate across teams. That’s a sign you need to reorganize your teams.
Most organizations that can, have moved to distributed, remote work these days.
Collaboration is most natural in-person, working in a team room. That’s why this was the original ideal for agile teams. You have high-bandwidth communication. You’re protected to some extent from distractions outside the team. You can have shared visibility into the state of the work. It’s easy to see if somebody is in a good place to get their attention or if they’re focused on something.
Remote work has its advantages—I certainly like working from home—but it requires intentionality to make collaboration happen remotely. We often have to schedule overlapping work time specifically for it. We have to have tools like Zoom, Miro, Google Docs, etc. to support interactive remote work.
The elephant in the room, though, for distributed teams is time zones. Remote teams can hire from anywhere, which seems like a big win, but because collaboration requires doing the work together—or at the very least, having short feedback loops between team members—it’s near impossible to collaborate across big time zone differences.
We were talking with a client recently who was struggling with this. This particular group had people on the west coast of the US and people over in the UK. That’s an 8-hour time difference. For them, the most obvious teams (with respect to grouping the right skills together) spanned the time zones. But those teams found it impossible to actually collaborate. The split teams ended up functioning like two partially-staffed teams coordinating with each other. It really didn’t work. So, they’re now having to figure out how to get the right collections of skills into the same time zones.
The same kind of challenge shows up when you have product management and customers in one country and development in another country 7, 8, 12 time zones away. Product and dev need to collaborate around that business complexity, but they can’t because work hours don’t overlap. So, feedback loops end up extending out to a day or more instead of near real-time.
Of course, you can’t always fix this overnight if you discover you have a team where complexity spans time zones in a big way. But once you’re aware of this dynamic, you can start setting expectations appropriately and you can start making moves towards easier collaboration.
Bottom line for all of this: Collaborate—that is, work together—on problems that have complexity, interdependence, emergence, and uncertainty. Coordinate—that is, plan together but work separately—on problems that are ordered and predictable, especially when they’re predictable at the boundaries between individuals and teams. And set up teams and tools to make collaboration easy and smooth where you need it the most.
We want to hear from you. Drop a comment on the YouTube version of this episode with something that became clearer for you about your work with this collaborate vs coordinate distinction.
As always, Please like and share this episode if you found it useful and keep the questions coming at mailbag@humanizingwork.com! See you next time!
Last updated