Distributed Teams, Part 2: Getting Everyone on the Same Page

In the initial post, we have stressed the advantages of distributed teams and described the biggest challenges. Without further ado, let’s proceed to step 2.

Takeaways:

• Make sure everyone knows what we are building
• Include all stakeholders right away!
• A great start is a foundation in building a steady relationship

What exactly are we building?

More often than not I would pick up a product specification and fifteen pages later I still can’t tell what we are building. The document goes into details of functionality and data but doesn’t provide the context of who the primary users of the software are, where they are going to use it, what are these people or algorithms trying to accomplish, and so forth.

Developers need to know the business context to the same degree as technical requirements for one counterintuitive but straightforward reason: lots of technical decisions depend on the expected use of the software. For instance, the user experience of two-factor authentication will be based on the intended geography of the end consumer. Do share these insights to save time and avoid frustrating redos. Concise presentation of the product to the target audience must lift your efforts in synchronizing the understanding of the final product.

Give everyone a taste of what’s to come

I wanted to highlight this in capital letters, but you got the idea already: include all your stakeholders on project meetings from the very beginning. When I say “all,” I literally mean every lead designer, developer, lawyer, brand manager, or growth marketer. The project will need to function well within all these dimensions.

Now, ask yourself how much more effective would your marketing campaigns have been if developers optimized their work for them? How much more confident would CIOs have been if they knew that the legal department had reviewed personal information storage practices prior to the project? Needless to say that humans are prone to make mistakes, even if they are experienced chief editors or chief marketing officers.

When we share this insight with each stakeholder, they stop worrying about the industry intricacies and tend to trust us more. This way several specialists are able to evaluate certain features critically before marking them as “done.”

To achieve this level of collaboration, you need to prepare a concise and practical overview of the project. We call it a Project Charter, and it is a great document to establish a common understanding. It’s designed to give everyone a bird’s eye view of the project: what is the need, who are the stakeholders, what are the general requirements and timelines.

We recommend adding the following points to the Project Charter:

Project Description. It is a general description of the project that we obtain from the initial conversations about the idea.

Project Requirements. This section gives a clear vision of what the customer, stakeholder or sponsor expects to achieve with the project and what the parameters of success are. It doesn’t cover the scope specifics but describes technology, integrations, UX, and other details the client may request.

Summary Milestone Schedule. This section summarizes expectations of clients or stakeholders, provides a timeline with desirable milestones and the final date of the product delivery.

Stakeholders. Who is the customer? Who are the people impacted by the project? This clarifies the customers (target audience) of your client.

Kickoff meeting

The previous steps mitigate the disparity of business, technical, and creative contexts. However, simply transferring knowledge is not enough, although critical. You need to understand the culture of your dev team and use it to your advantage. A general kickoff meeting is an excellent opportunity to achieve this. While it is always great to meet face to face, a conference video call can satisfy your goal. Revealing the faces of the project members to stakeholders encourages trust.

It should start informally, by the project manager or team lead speaking of the project anecdotally:

• who came up with the idea?
• what are the unofficial reasons to start the project?
• who will it impact and what are the hopes for the project?

Here is a brisk example: Our client, the airline, was tired with the old promotion methods. So rather than offering more perks, they decided to elevate the brand as a whole and set up a contest to get people talking about their dream destination while playing online to win free flights. We are stepping in to architect the online platform for the largest giveaway in history.

Everyone should read the project charter prior to kick-off and prepare questions based on it. Devote a portion of time for the live discussion. It is also a splendid moment to explore notable points about the project. Then, the product manager talks regarding the requirements, but without much of specifics. Pay more attention to the style of work each team embraces:

• Is it agile or waterfall?
• How often are the-stand up meetings?
• What does communication look like during the day?

Here is a quick tip: discovering the working routine of your distributed team will make it easier to pick the right tools and stick to them; if they use kanban, then adapt to this approach. It is more effective to adapt tools than forcing an organized group of people to change their professional habits. We will cover this more vividly in the communication section.

Moreover, you get to meet the humans, with unique personalities and original points of views. Accept them, learn from them, and be open to obtaining the results that will exceed your expectations. Finally, “a little party never killed nobody.” Embrace a friendly team building if it’s a live meeting, and go out with the team in the evening to talk beyond business. This small step will establish an important connection and vital trust. It will also motivate your partners to do more than expected from them.

Remember that such a powerful boost isn’t enough for the needed performance for the entire period of cooperation. Make travel visits to your distributed team a part of your routine. Before that, let’s assign the work.

Author: Yuri Kurat, CEO at New Normal. Yuri has helped businesses like Amazon, Southwest Airlines and Toyota create SaaS solutions that grow their business.