Distributed Teams, Part 3: Assigning the Work

It seems so obvious! And yet, you waste a lot of time to articulate your tasks in a comprehensive manner. What’s wrong?

Takeaways:

• Include remote teams in the roadmap planning
• Delegate responsibilities to other teams
• Leverage time zones
• Make your distributed team an equal partner

Remote teams can often feel like the main office dumps on them the work no one else wanted to do. To avoid this and illuminate trust instead, assign meaningful chunks of the project and permit full freedom in planning this work. Articulate clearly the responsibility behind their contribution to the end product and let them decide upon the definitions of compatible technology, approaches and methods they are going to use. These steps will eliminate the demoralization of the remote crew.

Don’t make the mistake of ignoring warnings that come from satellite offices; those are easy to look over, but often they are valid. Beware the master-slave relationships. Buffer can teach us what a truly distributed group looks like with 79 members scattered around the globe, but you can do well with one or two extended offices that deliver separate parts of work.

Cultivate autonomy and result-oriented culture

To achieve the above points, include remote teams in the roadmap planning. It’s important to give each group a chance to speak up and choose an appropriate pace. It would be rather naive to expect them to move at the same speed. Therefore, each sprint (every 2-4 weeks) needs to be a joint planning session, where each crew takes on a piece of work and presents its own timeline to complete.

Generally, priorities must come from the project lead, but the execution needs to be delegated to each team. An alternative is to play a game called “planning poker,” which can be used to find the optimal approach to solving a given problem and informing realistic completion timelines.

Reminder: Results, not the effort is what matters in teamwork, especially distributed teams. Foster a culture that values finding a resolution, even if it comes in a different way than planned originally.

For instance, if we cannot get the data we need from one API, try integrating with something else or try to piece together the data from different sources. Notably, each engineer needs to know that the organization is depending on him/her to deliver their piece of the puzzle for the entire product to work, and ultimately deliver value.

In this regard, every office needs to be self-sufficient; otherwise, the dependency of tasks will block the work. For instance, if a project manager were to speed up a feature, he could instruct several groups to work on the same piece simultaneously. Such flawed thinking results in blocking dependencies between various parts of the system. Therefore, it’s better to separate the work between the teams in a way that doesn’t intersect until a certain point.

For example, Google’s foreign offices only work on the Single Sign-On service: it’s a standalone piece of the system that ties into the rest of Google’s offerings through a predefined interface. As a result, the local crew can make their own decisions and add value while remaining independent from decisions and work of other offices.

Know the product owner

While it’s important to develop a collaborative spirit, there is a need for a clearly defined and well-communicated hierarchy. Such structural clarity will optimize communication channels and speed up decision-making process. All teams involved need to know who the product owner is: someone they can discuss ideas with and someone who will be the source of truth and ultimate authority on decision along with the documentation.

A short example: Charlie may have an excellent idea of texting a confirmation link to the user instead of a code, so he shares this insight with the product owner, Jen. But Jen is going to reject the idea since she holds the context of the project: most of the users will use the service at their desk and registering on their phone will diminish the overall experience.

Charlie can have the freedom to work and implement best solutions in his domain, but he needs to check with Jen on making changes to the overall functionality to ensure that the project still provides a consistent experience to the end user. It’s great to debate and try to persuade the product owner of your opinion, but everyone eventually accepts the decisions they make.

Speaking of communication: can you ensure that the workflow is smooth and, sometimes, non-stop? Well, with the distributed teams it is a real advantage. As a manager in Seattle, you can make a follow up on the work done by your team in Eastern Europe and prepare a new batch of tasks for the Asian division. It is especially handy towards the end of the project, where multiple loose ends need to be tied up or a quick A/B test is crucial to decide upon an ultimate solution. You can structure the work in a way, where the team that starts to work earlier will cue up all the necessary inputs for the team starting later in the day. Then, instead of blocking each other (as you would sometimes have in the same time zone), teams can set each other up for faster deliverables.

Conclusion

As each team takes ownership over a piece of the project, they then make a coordinated merge between their work which requires a lot of communication between the two. Undoubtedly, the interfaces and formats of the documentation need to be agreed upon before starting on the work. In the next post, we are going to present a vivid list of exceptional tools that will be optimal for such challenges and ensure proper communication with your distributed team.