With the birth of the internet, and especially since the early days of open source projects (meaning before the term "open source" was used to describe them), developers have been working together on specific projects as distributed teams of people. In some cases they formed passionate communities, all devoted to a piece of software. Years ago, one of Drupal's taglines was actually "Come for the software, stay for the community." Odd, right? Those two things don't seem to go together to me; almost like "come for the toilet paper, stay for the delicious food." Nevertheless, open source projects truly have thrived and even created communities of people that have relationships that go beyond the software they're building together. Rather amazing if you ask me!
When I joined Lullabot back in 2010, I'd never been a part of an open source project before, nor had I ever worked for a fully distributed company. The whole notion of the latter seemed novel and a bit frightening to me. Over time, I've realized that some of the basic philosophies and methods that open source projects use for communication apply directly to distributed companies. This isn't a huge surprise, especially for distributed companies that are doing software development using open source software. But what about other disciplines beyond development? Do the same rules apply, for example, for teams doing design or strategy work?
Before I tackle that question and dive into the specifics of distributed design teams (which I'll do in a follow-up article to this one), I want to first lay out the foundations for communication in distributed teams. These are the things that seem to apply across the board, regardless of discipline, and the things that have helped Lullabot foster great communication within our distributed team.
Lessons from Open Source
You might sum up the lessons you can learn from the way open source projects communicate into these three principles or rules ...
- Write liberally (asynchronous communication)
- Chat frequently (synchronous communication)
- Congregate occasionally (in-person communication)
Write liberally
People involved in open source software projects do a lot of writing. They create "issues" in written form that describe problems they want to solve, they hash out ideas in those same issue queues with groups of people, they document the work they do and the software they're creating, they write articles and blog posts about the things they're passionate about ... they do lots of writing! One thing that's worth noting about written communication is that, with the exception of the annoying tv news ticker, it's primarily an asynchronous form of communication. One individual writes something, another individual can read it at their convenience, and then write something in response if they so desire. Being a distributed team of people with members in various time zones makes it highly advantageous to find ways to leverage asynchronous communication. Distributed teams have to be more intentional about writing things down than do collocated teams, which is quite often an advantage. Having spent more of my career working with collocated teams than distributed teams, I can say from experience that collocated teams can easily take written communication for granted, and thereby suffer. The more you write, the better you get at it, and I truly believe that people who write well, think well. When teams are forced to be more intentional with describing their problems, solutions and work in written form that often leads to more thoughtful assessments, solutions and products.
"... being a good writer is about more than clear writing. Clear writing is a sign of clear thinking. Great writers know how to communicate. They make things easy to understand. They can put themselves in someone else's shoes. They know what to omit." — Jason Fried
Nevertheless, writing liberally can create problems as well as solve them. While lots of documentation can prove helpful to the newcomer in a project, as that builds up, it can go from information firehose to ocean, terrifying those newcomers floating on top. This is because written word is something to react to, rather than something to interact with. It can prove to be really efficient and invaluable for reporting, but REALLY poor for efficiency of interaction.
Chat frequently
Since asynchronous communication can be very inefficient for things like conversational problem solving, open source project teams have also been unafraid to pick-up the phone, jump on Skype or Google hangouts, or hop in a chat room. One of the biggest lessons I've learned from open source (and from working at Lullabot) about doing distributed teams well is paying attention to, and being intentional about asynchronous vs synchronous communication. While it's nice to think that everyone can get more done if we avoid calls and meetings and just keep everyone else up to speed via email, basecamp, github, or [insert your project management tool of choice here], reality is a bit different. Every person is different in the way they learn, think, process, and produce. Some are visual, some are auditory, some are kinesthetic and almost all are a mix of those in one way or another. Even visual learners often benefit greatly from simply talking things out. At times, assessing problems and reaching solutions can happen MUCH more quickly through synchronous conversation. Being intentional about synchronous communication in a distributed team means putting regular time into your team's schedule for it. You can't rely on poking your head into someone's office and getting your quick answer to keep your work moving along, you need to create those spaces.
Tip: As teams get larger, things like phone calls can be more challenging to manage. Years ago Lullabot developed a fun method for creating clarity on our larger team calls. When a team member has finished with their turn, they simply say "tada!" This lets the call leader know that they're done so that they can call on the next person, avoiding the accidental talking over people that is so common on larger calls.
Synchronous communication can also happen in the form of written word (not just spoken) via internet chat. Whether you use IRC, Slack, Google chat, AIM, or some other tool, internet chat can help create that ambient availability and accountability that exists for collocated teams. It lets you know who's "in the office" right now, and also gives you a way to quickly poke your head into someone's office to ask them a question or just say hello. Developing some ground rules and etiquette around this is key in order to protect productivity. Most designers, for example, appreciate not being stopped every 20 minutes while they're working on particular task types. Simple things like pinging someone and awaiting a pong provide people the space they need to get things done. In many ways, this sort of thoughtful approach to ambient availability could help most collocated teams. Poking your head into someone's office becomes awkward if they need ten more minutes to stay heads down in whatever they're trying to complete. There's nothing awkward about pinging someone via web chat and waiting ten minutes for them to respond.
Again, it's important to have a solid understanding of the advantages and shortcomings of each mode of communication so that you can make good choices. Brainstorming or creative collaboration, for example, requires synchronous communication, however internet chat often is not a great tool for this. When you need to think out a problem or generate energy around some ideas, setup a time to hop on the phone or some form of video conference. Also, emoticons aside, written word lacks tone of voice. For thorny conversations, use things like email and chat to schedule a call, not work through the problem.
Congregate occasionally
Even open source communities have regular or at least occasional events where most or all of the community gets together in the same location. People fly from all over the world each year to attend DrupalCon. It's worth noting that the really important work that often happens at these events is the strategic, and larger problem-solving work. Initiatives that have a clear strategy and plenty of energy can be tactically carried out by a distributed team using the means and methods described above, but there are other HUGELY important things that simply don't happen easily without people together in the same room. Some examples include ...
- Assessing and analyzing problems
- Developing strategy
- Building alignment around a singular vision
- Building relationships
- Resolving difficult conflicts
- Energizing and/or re-energizing a team
For these kinds of tasks, there are great advantages to getting people together in the same room. At Lullabot, we wind up flying groups of people to the same place quite often. Some of the examples of things that we do this for include ...
- Kicking things off (At the beginning of each project we fly the project team to the client location for about a week of workshops.)
- Working on our work (Focused teams within Lullabot like admin, managers, or design and development have annual working retreats to grease the gears, develop strategies, improve processes, and build relationships.)
- Working on our team (Once a year we fly the entire company to one place for a week to enjoy each other, work on the company as a whole, and simply have fun together.)
- Working on our business (Once a year Lullabot's top leadership get together for a week of strategic thinking, vision casting, and unity building.)
No matter how far technology takes us, humans are social animals and made to be together. Non-verbal communication is immensely important for creating and nurturing relationships. While distributed teams and companies can be extremely effective while apart much of the time, those times together in-person are invaluable!