Today I received an email from a recruiter, reading:

Client seeking Project Manager to be the main liaison between the Technology group in the US and Offshore teams in India.

More and more, part of our job as project managers is not just herding sheep, but herding sheep located on farms located across the globe.

I once had a team that was literally spread across half the planet:

• Firmware developers in Ukraine
• Stakeholders and management in California
• Stakeholders, firmware developers, and testing in Washington State
• Semiconductor packaging management in Oregon
• Semiconductor packaging factory in the Philippines
• Semiconductor manufacturing in China

Other than the people in Washington (where I was based), I never met anyone on this team face-to-face.

Finding a time for phone conversations was onerous. Even if you got everyone on a conference call, you had to deal with poor sound quality, accents, and that half the team was speaking in a second language (if they knew English at all).

So how does one manage a project where you can’t walk up to the desk of your team members and understand what they have to offer, as well as their challenges?

Break It Down

Break down your problem into components and understand what communication is needed between the different components. For instance, the packaging (putting the semiconductor die into a plastic package) team doesn’t need to talk to the firmware developers, but the testing group does.

Organize your communication around issues, not around locations or teams. Issues will vary by project, but they should be as small as possible. Putting the requirements together might be too big, but physical requirements (driven by stakeholder and packaging) and functional requirements (driven by stakeholders, firmware, and testing) might be okay.  Your communications should include everyone that needs to be part of that chain, but no one who doesn’t.

A standard management structure is also critical. There were eight Ukrainian developers on the project, but only two were part of the communication effort. Those two were responsible for representing their entire team, simplifying communication and giving the developers more bandwidth to write code.

Put Everything in Writing

“Precise questions and precise answers” was part of the company culture. You should ask questions that can be answered in one of three ways: yes, no, I don’t know.

This made conversations with the executives like talking with a teenager:

“Is the project going well?”

“Yes.”

“Will it be delivered on time?”

“I don’t know.”

These questions are great for email, and if every inquiry can be answered in this way, a disperse team isn’t burdensome.

But some questions are explorations.

“How do we address 85 lines with limited memory stretched across two dies?” was the fundamental question of this project. The answer “I don’t know” is accurate, but not helpful. Addressing this challenge requires brainstorming, testing of ideas, and a thoughtful exchange of ideas.

A common way to approach working together on this type of effort is over conference calls: long, inconveniently scheduled, hard to follow, conference calls. Some participants might be in a car or bus heading to or from the office. Many will be operating in their second language or on a low-quality VOIP line. My experience is these calls are expensive and ineffective.

Structured written communication is always a good thing, but in a dispersed project, it’s critical. For people working in their second language, it’s easier to take the time to craft an email than to explain their thoughts over the phone. Everyone has the chance to think about their response, to gather data, to mull it over with their local team, before they respond.

Decisions will take longer because you may only get one call-and-response sequence a day. But it’s more likely to be well-informed, and you’ll have a trail not only of what was decided, but why.

Make sure you account for this extra time when putting together your project plan. And sometimes, a conference call will make sense, if you need to quickly go through many cycles of give and take.

A few things can make the written communication a bit easier:

• New questions should be broken off into a new chain to reduce confusion. Ever see an email chain go on so long that the subject line doesn’t match the conversation?
• Emails are not structured communication. They have their place, but you might consider a more modern tool like Slack or LiquidPlanner. Long discussions with multiple people chiming in can be confusing on email, but Slack brings a modicum of order to rambling discussions. LiquidPlanner is nice because you can attach the conversation to a deliverable or task, making it easier to find what you’re looking for weeks or months later.
• Everyone needs to respond as quickly as possible. It’s bad enough when you have to wait until the next day for an answer. Things quickly grind to a halt if you need to wait several days. I’ve been on projects where the 7 p.m. phone call happens just because the remote team just isn’t answering emails.
• Sometimes the geography can work to your advantage. For instance, at the end of the day the software team releases code for test to a team that’s just showing up for work. When the software team shows up in the morning they can review the results of that testing.
• Build your plan and share it. As the PM, the schedule is your responsibility. But, if everyone on the team doesn’t know what’s expected of them, the perfectly lovely .mpp file on your computer doesn’t do much good. I prefer a web-based PM tool (like LiquidPlanner), so that everyone can interact with the plan and understand the importance of their contribution.

Set High Expectations for Communication

I’m one of those people that sends an email to someone in the same room if it’s a precise question, because it’s less disruptive than interrupting the person and it creates a paper trail.

But that only works if everyone reads and responds to their email. For a collocated team, it’s easy to just walk over to someone’s desk if I don’t have an answer after a while. But what to do if they’re in a different country?

It’s critical that there’s a culture throughout the company of engaged communication: reading all your email, responding quickly to requests, and providing information needed without being asked.

I once worked at a small company with one person who worked remotely. He would engage directly with our clients without letting anyone else know the outcome of the discussion.

He ignored email requests for information. He wouldn’t even fill-in his timesheet. When I spoke to his manager, the response I got was,“Yeah, that’s how he’s always been.”

There was no expectation from his manager or the CEO that he keep the team appraised of what he was doing. He was a talented engineer, but his inability to communicate coupled with the distance made him a net drain on any but the simplest of projects. I made it known that he was not to be assigned to any project I managed.

Things Won’t Always Go Smoothly

Running a team that’s spread across the time zones with people who speak multiple languages is inherently hard and is unlikely to go without a hitch.

If you and your team do a great job communicating, you’ll only occasionally find bumps in the road due to misunderstandings. When that happens, learn from what went wrong and move forward. Unfortunately, you won’t be able to all go for a beer as a team building exercise and celebrate your victories or lament your mishaps.

But you can raise a glass together at a video conference, but for some it might be a morning cup of tea.