▲ All teams past a certain size become distributed, whether across rooms, floors, buildings, cities, or continents. But tech is only starting to explore and invest in remote workplaces, which means that, as an industry, we don’t really know what success looks like.

Ultimately an effective distributed team is an effective team. Evaluate your distributed organization the same way you would if everyone were in the same place. Are you accomplishing your goals and moving forward? Do you have a plan, and do all team members understand it? Do you dedicate most of your working time to your team goals? Are team discussions (and disagreements) constructive? Does everyone feel safe giving and receiving mindful peer feedback in product, engineering, and design spaces?

What makes distributed teams different is intention and advanced planning. Remote teamwork doesn’t happen by accident, but through deliberate systems and practices around communication, coordination, collaboration, organization, operations, and culture.

■ Communication doesn’t just happen on its own. On remote teams, the default state is, instead, miscommunication. But with deliberate and explicit communication channels in place, your teams will be more productive, easier to manage, and better able to grow.

When you’re running a distributed organization, assume that someone missed the email, message, announcement, or meeting. It’s hard to gain context when you don’t see someone day-to-day and when you can’t rely on hallway chatter to spread a message or passively keep people on the same page. It’s your responsibility, therefore, to get your team on the same page: Get used to repeating yourself, and drop the passive-aggressive “as I said last week” and “per my last email.” Research shows that neutral tones come across as negative, and positive tones as neutral. Overcorrect with emoji, GIFs, and explicit communication. Sarcasm and irony are big gambles—our advice is to skip them. Your team should feel like, and be, a safe place to ask any kind of question.

One of the biggest questions distributed teams face is synchronous versus asynchronous communication. Synchronous communication happens in real time: back-and-forth group chats, video calls, and meetings. Asynchronous communication has a lapse between sending the message and receiving the response: recorded video messages, task-tracking software, collaborative documents, forums, and email. Both types of communication are important for healthy distributed teams, and getting the balance right has a massive impact on productivity.

When the real-time exchange of ideas is crucial, choose synchronous communication channels. Combing through an email backlog or discussing strategy on a forum is time-consuming and ultimately ineffective. Synchronous communication bonds teams and is vital for creative ideation. It’s also much easier to spot looming problems and dysfunctions in a synchronous environment because it offers more behavioral data. That being said, don’t let synchronous communication be ad hoc. Get your teams on a cadence so they can block times on their calendars and be present. This is especially important if you’re spread across time zones.

Asynchronous communication, on the other hand, allows people to engage when it best suits them, reducing unnecessary meetings and nonstop chatter. People can get deep work done and take time to formulate responses. Making written communication channels the default makes information distribution clear and reliable. It also means that the direction individuals get from you is consistent. When communication practices are standardized, events like adding new members to the team are less taxing on the group—which sets your team up for fast growth. The same practices that work for adding one member work for many more. Written best practices evolve and scale better than oral tradition.

Healthy distributed teams blend synchronous and asynchronous styles. Because what doesn’t have to be synchronous is better done asynchronously, default to asynchronous communication for nonblocking items and help team members review them on a cadence. Thanks to the internet, written communications are accessible and aren’t subject to the limitations of physical presence, serendipitous encounters by the seltzer machine, or inconvenient taps on the shoulder. When making a decision, ask yourself: Do I truly need a real-time back-and-forth on this?

■ Crucial to coordinating a team is time, which impacts everything from communication to collaboration, culture to hiring. It’s harder for a distributed team to react quickly, but you can mitigate slower reaction times by building predictability everywhere in your organization. Establish a tempo. When the CEO asks, “When does our next iteration start?” you should know the answer. This is the beat that everyone else can predict and build upon.

Maintaining the tempo can become tricky as you build cross-functional units made up of several teams. There will come a point when keeping all teams in sync will have more value to the organization than it will to individual team members. Customized cycles are worth exploring, especially when teams are spread across time zones.

▲ Because Splice is a hybrid organization (some teams are remote, others are co-located), my distributed engineering teams collaborate with design, product management, and business development teams co-located in NYC. Instead of building a globally distributed team, I made the decision early on to hire within a constrained range of time zones, aligning with U.S. Eastern through U.S. Pacific time.

● At Buffer, our total time-zone spread is 15 hours, with team members in Europe, the U.S., Asia, and Australia. Within product engineering teams, we try to keep the time-zone spread to eight hours or less, depending on how willing team members are to shift their workdays to accommodate meetings. We have synchronous meetings over video to plan and break down large features, and to brainstorm with PMs and designers on upcoming work. We also record all team video calls for those in distant time zones.

The time-zone spread means that Buffer engineers routinely “pass the baton,” where two or more engineers working on one feature hand over work at the end of a European workday to a U.S.-based teammate. (Often in this overlap period, two or three engineers will jump on a call, pair a bit, or screen share, sometimes even link terminal sessions with tmux.) This style of teamwork avoids knowledge silos, keeps morale high, and ensures continuous input from others.

▲ The greater the time-zone spread, the less easy it is for teams to schedule meetings or react in real time. It also increases the likelihood that someone’s lunch (or other meal) will be affected by standups, planning sessions, or retrospectives. And if the spread is large enough, people will inevitably be left out—or be asked to accommodate their life to work. And when you ask team members to adjust their hours, you’re asking for time that belongs to the employee.

● For instance, in the case of working parents, they may be faced with a meeting time that’s either 7 a.m. in Vancouver and 4 p.m. in Croatia, or 9 a.m. in Vancouver and 6 p.m. in Croatia. Consider that 7 a.m. isn’t an easy time for a business meeting when you’re getting little ones to school. On the other hand, 6 p.m. is tough on dinner, bath, and bedtime. On individual teams, a time-zone overlap of at least two hours during “regular” working time is essential. Often, someone still needs to compromise.

▲ In hybrid organizations, like Splice, active management keeps co-located teams from dominating scheduling preferences to the detriment of remote workers. With a wholly distributed company, like Buffer, your organization is time zone–aware and async-friendly by default. While fully distributed teams can more easily transcend time zones than hybrid organizations, predictability is vital across the board.

▲ Distributed teams aren’t better than co-located ones, but they are different. For me, the differences make my job as an engineering executive easier. Being physically constrained means that strategic direction changes need to cross a slightly higher value threshold to be acted upon. I used to see this as a limitation to collaboration, but then I realized that hundreds of OSS projects have been successful with this constraint and chilled out.

Glue work is “whatever it takes to make an organization successful,” including strategy, meetings, project management, design review, mentoring, and coaching.

■ Both of us have worked with our organizations to develop promotion processes that explicitly reward collaborative behaviors like mentorship and glue work. In both Buffer and Splice’s career matrices, we explicitly require a certain standard of mentorship and collaboration to be promoted to the next level. Rewarding collaboration is also an important part of reducing a gender wage gap on your team, as research published in the Harvard Business Review suggests that in collaborative cultures, women disproportionately carry the burden.

● Real-world face time still plays a critical role—it’s impossible and unwise to try to eliminate this entirely. Invest in getting your distributed team together at least every six months. (This can be an entire company, divisions, or even just the teams that work closely together.) Remote whiteboarding is possible, and not as hard as you might think, but there’s no substitute for the camaraderie and serendipity of time spent together in person.

▲ Teams should meet in person as often as possible without making travel a burden. (Six months seems to work well for teams I’ve run.) But for anyone, more than two days together is overwhelming. Curate talks, workshop and coworking time, and social activities. Bring in people from other departments for information-sharing and exposure. Not everyone does well in social activities, so make them optional and don’t judge absences. In-person gatherings should be almost like mini-conferences. Consider forming a committee with interested team members to help plan it.

To pay for in-person meetings, create a recurring line item in your budget and protect it. It’s important that the business understands this operational expense is as critical as paying rent. Be frugal, but not cheap. Use your company resources responsibly, but understand that a five-stop flight will deliver you an exhausted, rather than energized, team member. As your team grows, frequent gatherings may yield diminishing returns. If that happens, reduce their frequency. Aligning onsites with strategic planning periods can also work very well. But it’s more important—and ultimately more effective—to spend time together than to get work done.

● Collaboration is both an art and a science. Observe carefully what works and what doesn’t. No two teams are exactly the same, and team needs change with structure and product life cycle. As a manager looking to promote collaboration, ask yourself: What is most effective right now? Be ready to adjust and to change your mind.

● Brook’s law states that “adding [developers] to a late software project makes it later.” With distributed organizations, it goes into effect even earlier. As teams that work closely together grow, so does the volume of written information they generate. Eventually, information becomes hard to find and knowledge silos develop. Explicit, asynchronous communication puts a strain on collaboration in big groups, too, as every single person provides a detailed comment to every other thoughtful comment, resulting in long-running threads thousands of words long. But organizational structures can counteract these effects.

Also in this issue

The process: How Twilio scaled its engineering structure

A focus on small teams anchored the organization’s growth from three to 2,300.

The easiest way to get around the scaling law is to keep your teams small. In product engineering, think about the number of engineers working with a single product manager. In a distributed team, three to four engineers to one product manager works very well, whereas more than six or seven becomes actively difficult.

Reduce interdependencies by ensuring that a single team owns a customer-facing outcome (whether an end-user experience or an internal customer) and has the full complement of engineering, design, and product skills they need to successfully deliver that outcome.

Instead of having backend and frontend teams, for example, cross-functional teams allow decisions to be made close to the problem at hand. Most importantly, everyone involved is responsible for how the whole product fits together.

● Resist the temptation, however, to add every function that could in any way affect the experience, or you’ll run into scaling challenges. Rather, embed functions like mobile, product marketing, data, QA, and support by having representatives attend important kickoff meetings, share summaries, and recorded video calls as needed, and help your team understand when they need to seek out specialized input.

However, with a cross-functional approach, domain expertise and standardization is lost. Small product-focused teams risk constantly reinventing the wheel. Pain points that moderately affect every team don’t float to the top of any team’s priority list, even though the organizational gain of solving them is huge.

To counteract this, use working groups organized by function. Depending on needs, these can be informal discussion groups focused on sharing knowledge, connecting people, and advocating for solutions, or they can be more formalized structures with a specific task, like implementing a system of frontend components.

▲ In organizations of more than 30 people, I’ve also had very positive results tasking a single team with the customer-facing outcome of “delivering software.” They are responsible for clearing road-blocks in the delivery pipeline. This doesn’t mean they do everyone’s work, but rather that they support getting other teams’ work out the door. At Splice, this is our production engineering team, comprised of site reliability engineers (SREs), frontend reliability engineers (FREs), quality reliability engineers (QREs), and security. In the past few quarters, they’ve been responsible for stabilizing and reducing cycle time.

● Embrace the overlap between roles. Sharp, territorial boundaries in distributed teams mean that important things fall through the cracks and hard conversations are easily avoided. Encourage your team to develop the necessary experience and expertise to offer constructive feedback on other teammates’ work. Instead of worrying about who is accountable for the design and the code, encourage the messy middle. Both teams will better succeed when helped by the other.

▲ Effective operations bridge strategy with execution, and help companies learn faster than the market—all before they run out of money.

Equipment and environment are essential components of this: Distributed workplaces can be a cure for the proliferation of open-office colosseums where productivity goes to die. ● The minimum an engineer needs is a laptop, headphones, and decent internet. At Buffer, we reimburse these basics, plus fast home internet (fiber is best) or a coworking space. We give folks new laptops when they join, and replace laptops after three years, or sooner if needed. ▲ Splice also offers a home-office improvement stipend that can be used for peripherals, accessories, or anything that improves your work space, like plants. We ship you a monitor and laptop of your preference, and give you an office-chair stipend.

● When you’re hiring remotely, hire remotely: Have your process mirror how you’ll work. Interview folks over video call, rather than in person. Pay attention to the clarity of written communication during hiring emails and how responsive your candidate is. Do they arrive to the video call on time? Do they send back your take-home on time? If not, are they communicative about needing more time? A candidate who’s hard to connect with during hiring isn’t likely to be a great remote worker.

During interviews, ask about experiences the candidate has had around independent work, initiative, having a growth mindset, and being able to “get on with things” and unblock themselves reasonably well in an imperfect environment with some level of ambiguity. Also ask about times they’ve been frustrated at work. Do those frustrations sound like your team’s day-to-day? These are better predictors of remote success than just asking whether they’ve worked remotely before. ▲ Technical exercises should have clear rubrics that make your process repeatable, and should not only look to evaluate candidates’ technical knowledge or expertise but also whether they are mindful in their communication. Try a code review using Amy Ciavolino’s “Guide to Mindful Communication in Code Reviews” to define your rubrics.

■ However well you hire, your new team member will flounder without clear, organized onboarding. Worse still, new people band together to support each other and answer questions, leading to misinformation and culture fragmentation. Develop detailed 30-, 60-, and 90-day onboarding plans and check in at each 30-day mark. Give new hires buddies who introduce them to your operations and values. This culture scaffolding helps people integrate fully into the team more quickly.

▲ It can be beneficial for your team to adopt a process for distributed decision-making similar to opensource projects such as Rust or Ember. Requests for Comments (RFCs) have become one of my favorite tools for this operational need. They allow everyone to provide input into decisions other teams are making, potentially on behalf of others. And you get a historical record as a bonus. RFCs work best if used as a space for proposals, and cause friction if they are used to seek consensus.

▲ Trying to fulfill utopian expectations for workplaces sets you up to fail. There will always be differences in the team members’ experiences: People in HQ get snacks, but remote folks don’t have to deal with commutes or pants. (But please wear pants!) You can try to level the playing field with good A/V equipment, spaces, headphones, stipends, and meeting etiquette, but the experiences will still be different. And that’s okay.

■ Moreover, not everyone thrives in remote environments. You’ll have to adapt your support mechanisms for people as they transition into this mode of work, and set mutual expectations about how to signal when it’s not working. Extroverted folks can feel lonely, isolated, and disengaged. Anxiety and depression are also more common with remote work, where flexibility can translate into a total loss of structure and routine, and freedom can feel like abandonment.

● You also can’t see how people are doing in a remote team—if they’re tired, stressed, down, or jubilant. To counteract this, we talk about “traffic light” color check-ins a lot. We start and end most meetings with a color check-in. It’s typical to see messages in group chat like, “Hey everyone! I’m signing off for today, feeling :green_heart:” or, “Hey team going off for today feeling yellow.” It’s quick and easy, and it helps remind us that we’re all humans. Knowing if someone is red, yellow, or green gives team members a chance to support each other, and managers a chance to reach out and offer help.

At fully distributed organizations, you need to reinforce your culture constantly or you’ll end up as a network of freelancers rather than a gelled team. If you don’t have stated company values, figure them out—you can’t rely on the office vibe without an office. ▲ If you work in a hybrid organization, the distributed portion of your team will mostly live the company as if it were a TV show, witnessing only meetings they’re invited to or large town hall–type events, piecing together little by little how things work in HQ. Leaders in HQ should get in the habit of working remotely every so often, so they can experience the environment and build empathy for remote work.

● With the various cultures at play in globally distributed teams this is critical work when it comes to inclusivity. For instance, stating collaboration as a value means that it will be easier to help create an environment where everyone takes turns speaking. A global company culture can transcend local norms in cases where they may be in conflict.

Be lavish in your praise of any and all behaviors that are in line with those values, and swift and firm in discouraging behaviors that are not. Praise should be public and far-reaching: People will emulate behavior they see rewarded. In a distributed team, that reward needs to be explicit.

Be aware that remote employees work from home and live at work. Studies show that remote workers work longer hours on average—sometimes, a full extra day per week. As a manager, knowing if people are working is not your main concern. The real issue is knowing if they ever stop. Model healthy boundaries, turn off chat apps, and take your vacation time truly offline. Don’t let your remote team develop an “always-on” norm: It’s easier, and more destructive, than you’d think.

▲ Distributed teams enable me to distribute opportunity: I get to share the experience of building an impactful product with talented folks around the world. I also love working with people from different cultures, places, and lifestyles—it enriches my life. The autonomy and flexibility appeal to me. And I can scale teams much faster, which costs less in the long run. The downside? Not being able to spend more IRL time with the people I work with.

● My favorite thing about remote work is popping my own bubble. I almost never think of my network in a geographic sense: We’re all just people on the internet, trying to make things better. Like Juan, I enjoy being a free agent—having autonomy over my time and my environment. The hardest part is my hobbit-like tendency to not leave my apartment. I now schedule “out-of-home” activities each day to avoid a serious hermit relapse. Oh, and my massive FOMO that all the office workers are hanging out together on patios.

▲ No matter what constraints you choose to lean into or away from, be explicit about them and what the trade-offs mean for your team. As you build a distributed organization, these decisions are yours to make. As your team grows, they’ll live these choices, and hopefully the organization will evolve into something that continues to work better for everyone.

Further reading

• “Why We Need Best Friends at Work” by Annamarie Mann
• “Guidelines for Effective Collaboration” by Juan Pablo Buriticá
• “Increasing Engineering Tempo at Splice” by Juan Pablo Buriticá