Running a Distributed Team

I’ve worked with distributed teams with my last three startups. I find that with the right practices distributed teams can be more efficient and effective, so long as you over-invest in certain things to make up for distance.

To share best practices, I’d like to begin by exploring how time and space relates to designing and managing distributed teams. Then, the role of knowledge stocks and flows, how you have to over-invest in communication, remote and f2f meetings. First, some context on the structure of the teams I worked with:

Background on 3 Teams

Socialtext was entirely distributed until we reached about 15 people, and then we got an office so people could meet with us. Management, sales (except foreign field) and marketing in the office; Dev, QA and Support distributed from their homes across the US, Canada, two in Europe and one in Taiwan. I was the CEO up until we were 65 people, half remote. Since we made social enterprise collaboration software, we pushed a lot of the state of the art.

I joined into SlideShare which had five that grew into 15 in SF, and about 35 in a New Dehli office. Almost everyone was in a product or engineering role. CEO & CTO co-founders in the US drove the interaction with the New Dehli office and its GM co-founder. Toolset was less social with Gmail and Google Office, audio and video conferencing.

Pingpad is still a tiny team, remotely distributed in the Bay Area. My house in downtown Palo Alto has the HQ we work out of at least one day a week. Making enterprise collaboration software on top of Slack, a pivot from making consumer mobile collaboration.

Time and Space

Find the boundaries that make up your organization. Sometimes these will be boundary conditions that limit what is possible and have to be addressed explicitly. Sometimes these are structural holes, that when filled unlock collaboration.

A distributed team is more defined by time than place. It is a huge advantage to have most people in or around the same time zone. When work generally starts and ends for everyone at the same time, it’s easier to set standards for availability and handoffs are less of an issue. When the team isn’t in or around the same time zone, you can orchestrate with waves of work, even in a 24 hour cycle.

When I was a teenager testing video games at Activision, we’d run our tests in a long day, and handoff results to developers in Japan for their long day. I think both sides were sleeping on cots when nearing a Nintendo release. With SlideShare, most of the team was in India, which meant regular calls that could go through the middle of the night in SF. The founders did this for years with admirable stamina. One convention that helped is every team member wrote an End of Day (EoD) note describing what they did, what was next and what help they needed.

This little bit status reporting is essential overhead, to overcome time because of distance. It isn’t enough to have chat sessions from when people were doing work be discoverable, or work outputs. You need people to take a moment to be reflective and share towards collaborative goals.

Now people rightly hate status reporting, and ideally you have as little of it as a side activity as possible. Ideally the status of projects, workflows, goal tracking and more should be available through your toolset and part of your process. But remember when you are adding this kind of structure how easily it ossifies and the really juicy stuff isn’t going to show up in a dashboard. The upside these days is with social collaboration and productivity tools, more work is shared. The flow of work is more flexible, and more discoverable.

Knowledge Stocks and Flows

Be conscious that knowledge comes in both stocks and flows. A flow can be a communication channel with very flexible sharing and the availability of expertise. In the past this was hard to establish, and now we’ve reached and extreme case of it working well with many Slack teams. Slack is so real-time, so chatty, that in fact people find themselves glued to it with less direct purpose than with prior modalities. Like any social tool it is the practices of how to use it that makes it efficient and effective. Many workplaces worry about employee engagement. With Slack you get it, in an extreme way, and engagement may not be best directed, but it’s better than the absence and most alternatives to it. A stock, like a wiki, becomes essential for capturing knowledge. It is a pool people can draw from to act with the insight of the organization. And it becomes more essential the more distributed the team is by time zone.

Over-invest in communication

I’ve found distributed teams can have more focused productivity and enable people to have happy, balanced lives. They have recruiting and cost benefits. But they require an over-investment in some areas to work.

You have to over-invest in communication and connecting people. Not just from the role of Chief Storyteller and management. Everyone needs to understand part of their contract with coworkers is to be communicative. The communication isn’t just to talk about your work, but collaborate with people towards goals. Remote work is best when there is upfront agreement about the who, what, when, where and why of work to be done.

Meeting Creep

Distributed meeting culture is critical, for example:

  • All meetings must have shared meeting notes
  • Encourage creating agendas and preparing information to be read in advance of meetings, so there is less reporting and more sense and decision making
  • Company all-hands meetings weekly
  • Smaller group meetings like daily dev standup, weekly design review, weekly product strategy, and other weekly team meetings
  • The leadership team needs to deeply synch at least weekly
  • 1on1s with managers
  • Paired work like pair programming is really effective remotely
  • All meetings should result in assigned action items

But remember, meetings are autopoetic. The worst and most likely thing that can happen as the outcome of a meeting is the creation of another meeting. Try limiting meetings to 30 minutes instead of the calendar default, and avoid meeting-creep.

F2F

Pete Kaminski once said that time spent face-to-face is too valuable for work. You have to over-invest in f2f time to make up for the lack of it. Fly the entire company in at least once a quarter, and make a primary goal of meeting for people to develop social connections. The most effective off-sites I’ve had haven’t come from rigid agendas, but having a couple sessions where management communicates and takes questions to quickly having a Barcamp-style open space methodology where anyone can organize a session. Bring things back into plenary often to share results from the sessions and you’ll find your team can accomplish planning goals in a less planned, innovative and more social way.

Consider having travel budget so teams can meet once a quarter on their own. Let them rotate where they meet besides just where the HQ is, and instead around where different people live. Consider hiring people in clusters (same metro areas) and they’ll meet on their own socially. And one day those clusters could have offices if you need them.

People and Balance

People who work productively, engaged and happily in their pajamas are special. They are at the same time alone, connected with coworkers, the fridge in reach. They spend more time with the people they call home, yet the space and time they call home is less protected from work. For some, this means people have less personal space, for some this means they have so much more they can feel depressingly isolated. Some even can and choose to roam, to live in many places or work while traveling.

Hiring these pajama people means looking for different attributes. I find it isn’t the best first job for people. They may need the F2F handholding and peer interaction to learn and perform, and want a social environment at work that has them go out together afterwards. Like they had in college. Mid-level people may be your most junior.

I’ve found people who have been active in communities outside of work to be very effective in distributed teams. Especially developers who have been active with open source. But also people who seek work-life balance with the fulcrum of a third place.

Leading is more important than managing a distributed team. Missions needs to be internalize. People need to be empowered to align on goals, have productive conflict and make good decisions. And throughout this, the leader’s job is encourage the team to have fun. It can be a little nerdy to do this with chat, writing, voice and video. Embrace this :-).

Ross Mayfield