Step two: remote-first thinking

Remote-first thinking isn’t a way to be a distributed company. It’s a philosophy that guides how your team and clients interact that prioritizes the experience of working outside of a traditional, centralized office environment. While this philosophy works for any company—remote, blended, or office-bound—it’s absolutely essential for a fully distributed team.

Remote-first thinking was inspired by mobile-first design

Before smartphones and the mobile web had fully caught on, there was a design philosophy for making websites called graceful degradation. The idea that was that we would add redundancies and failsafes to a website’s design so that at each step down in a browser’s capability would still produce a useful and acceptable website. The most common use was building failsafes for people who disabled JavaScript in their browsers.

A few years later, as the mobile web became more common, the challenges of design compounded. We had to design for entirely new experiences, devices, and limitations. “Graceful degradation”—designing for the best experience first, then working backwards as the experienced started to break—no longer made sense. Starting with the best experience in mind—a big screen, modern browser, fast internet connection, and accurate mouse—encouraged desktop-first design.

So we rethought the process of design from the perspective of the user with the worst experience—the smallest screen, the oldest browser, the slowest connection, and the clumsiest fingers—and added functionality as the user’s capabilities grew. This was known as progressive enhancement, which laid the foundation for mobile-first design. Whereas graceful degradation focused on subtraction, progressive enhancement focuses on addition. This was a better philosophy by far. And this is the philosophy that underlies remote-first thinking.

Start with the person who isn’t there

Remote-first thinking, like mobile-first design, forces you to think about the most challenging situation first. In web design, you want someone running a dusty version of Firefox on their Windows Vista laptop to leave your site feeling just as satisfied as someone running Chrome on their MacBook Pro. The same is true for the remote members of your team. You want to create the best possible experience for the team members outside of the office space because they face the greatest number of disadvantages: they get left out of in-office jokes, they have to be the disembodied voice on speakerphone, they have to wake up two hours earlier than everyone else because they’re in San Diego while most of the team is in Austin…

The first time we tried to hire remote team members, it was a disaster.

The first time we tried to hire remote team members, it was a disaster. They couldn’t hear us on calls—assuming we even remembered to dial in. We’d ignore the lone face on the TV screen when the rest of us were sitting around the conference table. Sometimes we’d just forget about them, period, because they weren’t “here” with us. It was so bad, we eventually gave up and thought that distributed work just wasn’t for us.

But then we learned about how the fine folks at Lullabot and Palantir managed their distributed teams. The lightbulb moment for me was seeing how Palantir—a hybrid model that blended an office-based team in Chicago with a remote team scattered across the country—handled conference calls. At Palantir, if even one person had to call in for a meeting, then everyone did. The experience of the remote team member was considered first, and it set the baseline experience that was shared by the entire team.

I realized we could take this lesson and apply it to everything we did as a distributed company. We could design our workflow, our team interactions, our scrum sessions and retros—everything—with the experience of the remote team members first. Remote first.

No, we can’t just meet in the conference room

With the remote-first philosophy in place, we decided to try the distributed model one more time. Our first remote team member was Matt Grill in San Diego. Everyone in the Austin office knew that beginning on Matt’s first day—Monday, August 5, 2013—we would be a remote-first company. We would attend team meetings using Google Hangouts, from our desks. No one would use the conference room because Matt couldn’t use the conference room.

We were ready, we were committed, everyone knew what to expect come 10am. And then Matt got sick and couldn’t make the meeting. So everyone who was going to be at that meeting was in the office. Wouldn’t it be easier if we all went into the conference room? Wouldn’t it be easier to just do it the old way? The only remote team member wasn’t going to be there anyway, right?

Your remote team member’s experience has to matter, even if—especially if—they aren’t there to remind you of it.

Wrong. If we went back to the old way whenever Matt was gone, then we would make his experience secondary. His experience has to matter, even if—especially if—he isn’t there to remind us of it, because we’re all in this together. That’s what remote-first thinking is all about.

The devil in the details

When you first go distributed, the big problems are going to be obvious, and their solutions will be, too (especially if you’re reading our Distributed Focus series!). But it’s not the Big Things you need to worry about. It’s the little ones.

Remote work can be isolating, yes, but that’s not why it’s terrible. It’s terrible because somebody is using those earbuds with a mic on the cord that scratches against their shirt every time they tu\r\n \their head. It’s terrible because a 2pm meeting in Austin conflicts with 3pm school pick-up in Boston. It’s terrible because your “home office” is filled with your dirty laundry, and it feels like both your personal and professional lives are in disarray. A bad remote experience is death by a thousand cuts: many tiny, almost insignificant, annoyances and perceived slights that accumulate and fester until someone finally decides they’re not “remote material.”

Start by designing the team experience from the perspective of the person who isn’t there, and think of everything else as an addition.

When you go distributed, you must encourage people to speak freely about all the little things that bother them throughout the day. You have to encourage or require everyone to work from home a few days a week so they understand what it’s like for their remote teammates. Then, you have to document each of these tiny aggravations and address them.

• Problem: Placing a coffee cup on the conference table causes an obnoxious “thud” on the Polycom unit.
  Solution: Use soft coasters.
• Problem: Using your laptop’s microphone and speaker causes a nasty echo.
  Solution: Use a headset.
• Problem: Personal commitments (like picking up kids from schools) and timezone differences cause meetings to be rescheduled.
  Solution: Block off “unavailable” time on your calendar so people know when you’re busy.

You start by designing the team experience from the perspective of the person who isn’t there, and think of everything else as an addition—a progressive enhancement. Coming into the office and hanging around the break room is one kind of addition, and coming into your home office from the top of Cowles Mountain is another. Remote-first thinking doesn’t mean that everyone has the same experience, but that the baseline company experience doesn’t treat the remote experience as degraded.

When you become a distributed team, you have to start by considering what works for the remote team members and go from there. You have to be Remote First.