Guide for Leads of Distributed Teams

About This Guide

Pictured above is Ron Herman running a “How to Manage Remote Teams” workshop for 16 engineering leads and managers.

Managing distributed developers is different than managing a co-located team. Recognizing this is the first step towards making the enterprise successful. At TeamFound we’ve worked with many software development teams, often teams who venture to work with remote engineers for the first time.  This guide summarizes some key points in running distributed teams successfully.

If you’re a manager or team lead, and you want to better prepare for expanding your team with remote developers, or if you want to improve your current distributed operations, this guide is for you.

Table of Contents

Software development processes are your foundations
Setting roles and expectations
Develop a culture of accountability
Encourage truth and problem solving in stand-ups
Ownership is not easily measured, but more valuable
Take opportunities to foster a collaborative atmosphere
Characteristics of an effective team leader
Conduct one-on-one’s
Attention is your greatest asset
Emails are lost to the team
For Pete’s sake, turn on your web cam!
Great performing teams are built on trust
Tell the story. Rally them behind a common goal

Software development processes are your foundations

Process is usually not a top-priority when a team is co-located. Teams that reside in one office, often get by with little to no process or standardized workflows or structured communications. If co-located teams take-on remote team members, and do not develop good processes, they will experience many frustrations and loss of performance. This alone may cause them to consider the collaboration a failure.

Therefore, one of the most important planning initiatives for organizations preparing to work with remote teams is designing robust processes, workflows, and structured communications – all of which I refer to as “process”.

Process is simply put a structure for working. When team members are dispersed, using a common process is essential to knowing how to work together: expectations of team members, when to perform key activities, and overall how to achieve good team performance.

Fostering good team collaboration begins with designing processes and workflows that encourage collaboration. Especially in a distributed team model, good collaboration needs to be “engineered” into the engineering process, and the day-to-day workflows of the team.

Software engineering and testing teams have significant advantages with distributed members, because for decades engineering teams became accustomed to process as a means of facilitating good software engineering. Today many teams use Scrum, a framework for managing agile processes. Scrum has gained so much favor in the software development world, that most engineers today have either worked in a Scrum process or can freely explain the key elements to Scrum.

The main advantages of Scrum from the perspective of managing remote or distributed teams are:

  1. Engineers can on-board quickly since they understand the general underpinnings of how to work in an Agile team.
  2. Managers can track and assess the performance of the team through the activities of the process, and by using metrics that are associated with an Agile process, without the need to “see” developers at their desks.

As far as process is concerned, the main difference between an agile co-located team and an agile distributed team, is how well the process it’s defined. With a distributed team, processes should be well documented and easily accessible for the team to read and follow and collaboratively adjust. A simple wiki serves this purpose. For example, one team we worked with who were implementing weekly sprints even posted a day-of-week schedule for the team to follow: activities for Monday, Tuesday, etc.

Processes should include communication protocols: team member contacts and their roles, when meetings occur, who is responsible to attend those meetings, and what tools are used. Protocols should also define off-hour or emergency communication procedures and phone numbers.

Think of workflows as more detailed expressions of your processes, similar to logical decision-making trees. In Git For Teams (O’Reilly), the author presents examples of very well defined workflows and processes using Git for Agile Scrum teams. The published chapter Workflows that Work is a great introduction. Use them as examples of how detailed and well-define your workflows can be.  Written workflows help team members place their task or problem in the right context, and understand what their options are for handling them.

Far beyond resolving loss of performance, robust processes can enable distributed teams to actually outperform collocated teams.  In a 2009 article titled How to Manage Virtual Teams, published by MIT Sloan Management Review, the authors write:

“Virtual teams that had processes that increased the levels of mutual support, member effort, work coordination, balance of member contributions and task-related communications consistently outperformed other teams with lower levels. Moreover, dispersed teams that had high levels of task-related processes were notably able to outperform co-located teams with similar levels of those same processes despite the physical separation of their members.”

I suggest making a best effort to design your processes up-front collaboratively among your team members, internal and remote.  Working together, your team will feel more ownership of the process, and it’s a good team building exercise.  It doesn’t need to be perfect. Refinements can be made iteratively.

Setting roles and expectations

Team members are more willing to trust and cooperate with other team members when they know what to expect from each other, especially in distributed teams where personal contact is limited.  Each team member should not only understand his or her role and responsibilities, but also that of their teammates.  By reducing the ambiguity of people’s roles, and sharing this information across the team, members gain confidence in communicating with each other and working together.

Roles are typically set from the start of the project. Expectations are determined mainly via the processes and workflows.  If you have no documented roles and expectations, consider assembling your team in a meeting where teammates list all critical decisions and activities that they anticipate or for which they are already accountable.  It’s easier, of course, when the team can reference a well defined process. These are then discussed and agreement is reached on who has which role and what is expected of them.  While this activity can take place over the course of the team’s collaboration, determining roles early in the team’s life cycle helps accelerate productivity.

Lastly, it’s incumbent upon leads to regularly who reinforce roles and expectations, as well as adjust them to meet the demands of projects.

Our research shows that… Collaboration improves when the roles of individual team members are clearly defined and well understood…”  Eight Ways to Build Collaborative Teams, Harvard Business Review, Nov. 2007

If you’d like to take inspiration from leading experts in setting goals, I recommend:

Develop a culture of accountability

Wade Foster, co-founder of Zapier, a company of 36 fully distributed members, in his Ultimate Guide to Remote Working said that running a fully remote team forces you to build more systems and processes, to grow up more quickly, to be more disciplined. One of these disciplines is evaluating performance. In distributed teams the “noise” of seeing co-workers show up to work, personality biases, etc. do not exist. Performance evaluations need to be based on metrics.

For example:

  • number of commits, pull requests
  • # bugs
  • # tickets/issues handled (with perhaps a weighting involved)
  • contribution to sprint reviews
  • participation in written forums

Managers worry: “if I let my team work remotely, how do I know they’re working?”  The answer is to setup reporting mechanisms. Then you know. When you assign work, that work needs to have a reporting mechanism attached to it, so you know it was done.

Developing a culture of accountability begins with processes. For example, Wade Foster explains that in Zapier, they have “Friday Updates”, where every person on the team posts an update about what they shipped. The idea is adapted from Scrum Sprint Reviews. In Agile, teams aim for a shippable product at the end of each sprint.

Encourage truth and problem solving in stand-ups

With remote teams, stand-ups may be the best opportunity for leads and members to understand potential technical or product conflicts, what is not headed in the right direction, challenges that need to be addressed. This often takes more than a quick 10 minute stand-up! Don’t fly through stand-ups like a process that you need to check-off.  Everyone’s busy and no one wants to waste time, but it’s better to assure development is headed in the right direction, than to write wrong code.

The key skill in stand-ups is attentiveness. This may sound simple, but remember, you’re inputs are fewer when communicating through voice or webcam. If you are attentive, you know when you have to intervene and ask more questions. Dig in. Doing so with the whole team helps you surface issues that the everyone can learn from. In remote teams this is especially needed because it gives team members the opportunity to reinforce their understanding and thinking processes, even to challenge their biases, and to learn from other teammates.

Chris Lema in Building & Managing Virtual Teams, warns you to be careful not to encourage responses from your team that they believe you want to hear. Instead, push for honest answers with all the bad news that may be hidden in there.

So how do you encourage truth? Simple. The next time you hear bad news, instead of getting upset, dig into it so you understand it. And then embrace it. Ask what alternatives have been considered and if it sounds like everyone is thinking about things correctly, adjust expectations and plan for the new reality that takes into account the bad news. Don’t lose your cool.

It’s not that anyone wants to lie. But the reality is that most cultural dynamics in teams land closer to telling each other what they want to hear instead of what they need to hear.

Ownership is not easily measured, but more valuable

Metrics that look good in a report may still leave stakeholders frustrated. Accountability refers to responsibility for a task. Ownership refers to responsibility for end-to-end delivery, which translates to a satisfied customer.

Chris Lema writes a humorous analogy: Have you heard the joke about the chicken and the pig? When it comes to a ham and egg breakfast, only one is committed, while the other is just involved. It’s the same distinction when it comes to accountability and ownership.

The challenge for managers is how to take someone who is accountable, and foster them to graduate to ownership. This begins by learning to delegate your “ownership” responsibilities, elements of your job that you think only you can or should do.

Gradually, give your most responsible teammates more to own. Help them by giving them a bigger stake, a bigger role, a bigger reason and need to be committed (rather than involved). Give them greater ownership over the whole, instead of just the parts.

Zapier sought-out a way to ground engineers in the needs of customers.  They want to assure feature building isn’t done in a vacuum. They do this by rotating engineers into bug fixing and customer support. This advances a culture where each person is not only accountable for his or her work, but also takes ownership for delivery and satisfied customers.

Take opportunities to foster a collaborative atmosphere

We’ve already discussed designing processes and workflows that encourage collaboration. It also helps to identify special opportunities that arise day-to-day to further foster collaboration.

For example, when a developer or tester is having difficulty in accomplishing a task, ask the team for a volunteer to assist him or her.  Solving problems collaboratively and voluntarily is a great way to strengthen the team.

Similarly, when research is needed into a particular technology, assign the task to more than one person. This not only encourages collaboration, but often results in better research.

What’s more, good collaboration involves healthy working relationships. Leads should ease into group meetings by taking a few minutes to ask members how they are doing, how their weekend was, for example. This “humanizes” what can otherwise be a task-based operation devoid of team atmosphere.

Characteristics of an effective team leader

In our experience, the following traits contribute to successfully managing remote teams. Team leadership can be a shared responsibility across different roles:

  • Can manage transitions in the objectives, people, and focus of the team.
  • Fosters an atmosphere of collaboration among team members
  • Clearly communicates team goals, and how they align with the broader organizational strategy
  • Has strong interpersonal communication skills
  • Enables members to feel engaged in the project.
  • Delegates responsibility effectively
  • Encourages team members to come up with creative ideas
  • Has the autonomy to iteratively evolve processes, workflows, and collaboration methods as needed, based upon project demands.

It takes strong communication skills by team leads to make sure people have the information they need to do their jobs, and to ensure team members feel “plugged-in” and engaged. Those who are naturally extroverts tend to more easily succeed in team leadership. However, even others with fewer “people skills” can learn.

  • It’s better to over-communicate than under-communicate
  • Be responsive. Follow-up promptly to requests from your team.
  • Encourage dialogue so members feel comfortable speaking their mind
  • Remember that a voice only discussion does not provide important visual cues. Learn to compensate by asking for clarity anytime an issue is not well understood.

Conduct one-on-one’s

Conduct one-on-one’s with all team members at least once per month.

Keeps the manager and team members on the same page, and great for informally letting team members know where they stand, and receiving feedback that they would otherwise not give. At Zapier, managers ask 4 questions: “what’s one thing you’re excited about, what’s one thing you’re worried about, what’s one thing I can do better to help you with your job, and what’s one thing you can do better to improve at your job.”

Attention is your greatest asset

You can’t know what the best course of action is, if you don’t know what’s really happening.

Everything that is normally communicated through speech, sight, whiteboards, hand gestures, body language, facial expressions must now fit into a pipe called “Skype” (or tools of choice). Your most valuable asset is your attention.

You have to work harder than before, because before you could afford to miss something, a gesture, a signal, a phrase. Not any more. Communication (hearing, seeing) is minimal, and you have to pay attention to every word, to read between the lines, to sense the signals that would otherwise be obvious to you. During your calls with remote members, attempt to reduce all potential distractions.

Emails are lost to the team

Email from one person to another is a private discussion, potentially about a component or business logic that other team members can benefit from understanding. It takes valuable time to write these emails. So why is the content lost in email?  Even in shared emails, the content is lost to future team members.

When migrating from co-located to remote or distributed teams, it’s not necessary to devote lots of time building new documentation. So much documentation is already being written every day in emails.  Shift that effort from email, to a repository available for the whole team to see.

Shift to transparent discussions visible to the whole team.

Successful remote teams all acknowledged that sharing information across teams is a huge element of their success. Visibility is key. Slack is a good solution.

For Pete’s sake, turn on your web cam!

Whatever your reason for keeping it off: bags under your eyes, bad hair day, etc,  pales in comparison to the good reasons for turning it on.  Seeing our colleagues face-to-face is critical to the psychological drivers of healthy team work. Every experienced lead or manager knows the importance of looking someone in the eye.

Even though your team members may be thousands of miles away, a web cam enables you to see them as though they were right there next to you.  No, it’s not the same, but it does go a long way towards building camaraderie, getting to know your co-workers, and improving the working relationship of the team.

Buying webcams for your team is a very small price to pay for the overwhelming benefits.  Not every conversation needs video.  I recommend using video at least twice each week.

http://zoom.us is an advanced team video collaboration tool. Skype is okay. Best are tools that your team can spontaneously use, without the need for an organizer. Think of it like walking over to your buddy’s desk.

Great performing teams are built on trust

It’s more difficult to establish trust when you’re working with a team member remotely, especially one whom you’ve never met. But teammates have to trust each other.

The most efficient approach to building trust is to bring teammates together in-person. There is no faster, more impactful way to build relationships, to get to know each other, than to meet face-to-face. Studies have shown that if a team meets in-person during the first 90 days of the collaboration, the project has a much better chance to succeed.

If your budget allows an early in-person visit, great. If not, consider scheduling an annual in-person meeting, rotating team members, one or two members at a time to visit the home office.

A more continuous approach that is also effective is scheduling weekly or bi-weekly hangouts to enable teams to virtually get together, and do lighting talks, demos, and otherwise share experiences.

Tell the story. Rally them behind a common goal

Team leads are responsible for rallying their team behind a common goal.  Spend time discussing the “why” of the project, providing context beyond the technical requirements. Remind the team periodically how the project, and specifically their efforts, impact the company’s business and its customers.  Furthermore, a consistent effort to communicate team goals and relay “the story” behind the project breaks many long-distance barriers.  Being rooted in a clear understanding of the big-picture objectives, a team member is likely to make better decisions and stay motivated when working alone.

Daniel Pink writes: “It’s often difficult to do something well if we don’t know the reasons we’re doing it to begin with. People at work are thirsting for context, yearning to know that their efforts contribute to a larger whole. And a powerful way to provide that context is to spend a little less time monitoring who, what, where, when and how – and little more time considering why.

More on story telling: https://hbr.org/2007/12/the-four-truths-of-the-storyteller

Leave a Comment