Hours of Overlap, the First Principle of Successful Distributed Teams

Do you work in a building with other people? You might think you're part of a collocated team. Here's the test: Is everyone on the team within 30 meters (or seconds) of walking to each other? If so, yes, you are collocated. If not, no, you are part of a distributed team.

Why is 30 meters so important? If you're within a short distance (and some people claim that's as small as 8 meters), you are likely to ask someone a question or quickly work together. More than 30 meters? You are much less likely to collaborate. You don't want to interrupt yourself or the other person.

And, if your team members are on separate floors—even in the same building—you are definitely part of a distributed team.

So, assuming you have a distributed team, the first principle is to establish sufficient hours of overlap.

Here are three tips to seeing and creating your overlap:

Tip 1: Visualize Every Single Person's Hours

Mark Kilby and I wrote an article recently, Distributed Team Workspaces Start With Hours of Overlap. That article discusses a team where each person had their own working hours.(This is normal. I don't work the exact same hours every day. I bet you don't either.) If the team members had sat next to each other, it might have been okay. But, they didn't. This is their initial visualization of their hours:

You can see that while everyone was in the same timezone, they only had three hours of possible all-team overlap during the day. The yellow fills are personal-reserved time for Dave and Polly. Dave was a technical lead and Polly was the Product Owner. Both of them had knowledge the team and other people across the organization needed.
This team wanted to use an agile approach. However, they didn't have quite enough time. See how Polly's not available during a substantial part of the team's day? And, Dave used his time to chat with salespeople and potential hires. He took time in the middle of the team's day to do that.

Dave and Polly used their reserved time for important company work. And, because they took time in the middle of the day, the team had trouble collaborating.

Agile teams need substantial collaboration time—a minimum of four hours a day.

Tip 2: See if Everyone can Create More Collaboration Time

Once Dave and Polly saw how they prevented the team from more collaboration time, they decided to experiment with another way to manage their days. They created this chart:

Dave pushed some of his meetings to later in the day and Polly spread hers out. The result was they both had more time to spend with the team.

Your team members might not find a solution as quickly as Dave and Polly did. In that case, ask the question, “When can we work together?”

Tip 3: When Can We Work Together?

If your team members can't easily move meetings around, consider the options of timeshifting, timesplitting, and copilots. These options need to be a personal choice. Mandating that someone change when they work is bad management.

Some people might want to timeshift—to work earlier or later than what society accepts as a “normal” workday. I happen to be a morning person. This works well when I work with people farther east than I am. I can (and do) meet with people farther west in the evenings, although it's not my preference. I recently coached a client in Australia in my evenings. I timeshifted for that work.

Some people might want to timesplit—where a person works early in the morning, takes a break and then works late in the afternoon. As long as the person chooses this and not the manager, that can work. (I have not seen timesplitters work by choice for an extended period of time.) I don't choose to timesplit at all, but it might work for you.

You might want to experiment with copilots: one person in one site who works with a counterpart at another site. The two pilots synchronize their work every few days, but the teams don't share the hours of overlap pain. I've seen this work with product owners. One product owner for one team who collaborates with another product owner on a related set of features. The product owners need to collaborate, but they take the pain for the team.

Bonus Tip 4: Insufficient Hours of Overlap Don't Work for Collaboration

If your team needs to collaborate and they don't have sufficient hours of overlap, reorganize the teams. Find ways to create feature teams or collaborative teams where people have at least four hours a day to collaborate. Don't try to impose an agile approach for teams that can't collaborate. See Manage It! for other options for project lifecycles. Or see Create Your Successful Agile Project for more options for your agile approach.

While you might call a collection of individuals a team, if they can't collaborate, they are not.

From Chaos to Successful Distributed Agile Teams is Out!

My new book (with Mark Kilby), From Chaos to Successful Distributed Agile Teams: Collaborate to Deliver is done! If you have a distributed or dispersed team, do yourself a favor and read it. I'll continue to publish principles from the book in these newsletters.

New to the Pragmatic Manager?

Are you new to the Pragmatic Manager newsletter? See previous issues.

Here are links you might find useful:

Till next time,

Johanna

1 thought on “Hours of Overlap, the First Principle of Successful Distributed Teams”

Leave a ReplyCancel reply