Like any new employee, Scott Berkun had the jitters on his first day at Automattic. He was a little older than most of the people at the company, having spent the previous nine years at Microsoft. Although he witnessed firsthand the excitement of the tech giant’s glory days, office life was still rather conventional.
Now, in 2010, Scott was joining a young company with no offices, and — prior to his hiring — no managers. Before Scott joined, everyone in the company reported more or less directly to Automattic’s founder Matt Mullenweg and then-CEO Toni Schneider. Scott had been hired based on his own advice as an Automattic consultant. He had observed that the company had grown too large to operate efficiently with a flat structure. Scott suggested a turn toward a more conventional approach — the company needed hierarchy.
Scott would become the first “Team Lead,” the company’s term for those with an org-chart position between Mullenweg and the rest of the company. He worried that his experience, which would have served him well at almost any tech job, had not prepared him for the loose and unstructured nature of Automattic’s distributed teams. The stakes were high: if these new teams worked, it would prove that Scott was right about the need for some hierarchy. But if they made things worse, there would be no one to blame but himself.
Scott had developed a reputation as a management expert, having published several books on project management. Scott and Matt defined his employment as an experiment: Can an “old school” manager thrive and bring value to a young, unconventional company? Could he bring some order to the company’s loose configuration without stifling the creativity and flexibility that the flat, distributed model encouraged? To make the experiment even more interesting, Scott and Matt agreed that the journey could form the basis of Scott’s next book.
Scott describes his first-day anxiety and how it was quickly put to rest in the book that resulted from his time at Automattic, The Year Without Pants. He loved the friendly, informal chats that his coworkers — also known as “Automatticians” — carried out throughout the workday. People eschewed jargon and talked like humans. In the book he writes:
To work at a remote company demanded great communication skills, and everyone had them. It was one of the great initial delights. Every corporation has the same platitudes for the importance of clear communication, yet utterly fails to practice it. There was little jargon at Automattic. No “deprioritized action items” or “catalyzing of crossfunctional objectives.” People wrote plainly, without pretense and with great charm.
On top of that, everyone seemed to like one another, and projects moved quickly. There were no checklists or forms to fill out — even on Day One. Everything was informal, but somehow it just worked. (As the company grew tenfold over the next few years, new policies and structures evolved to allow a distributed model to scale with it.) People were honest and open about taking time off throughout the day to walk their dogs or eat lunch with their families. Yes, they were coworkers, but they saw each other as real people with lives outside of work, too.
Scott started off his training with several weeks of customer service, an Automattic policy that enables new employees, regardless of their expertise, to get a ground-level view of the types of problems the company’s customers are facing (the policy stands to this day). Scott learned how to resolve problems as he experimented with the product, perused support documentation, and asked for help from other Automatticians via IRC — Slack wouldn’t appear on the scene for another three years. Whether it was aiding a frantic customer with an urgent, complex issue, or recovering a user’s password, Scott was absorbing institutional knowledge much more quickly than he would have if he’d been instructed to skim an employee handbook. By the time he completed this hands-on training, he felt newly equipped to join and lead his new team.
Building Trust When You Can’t See Each Other
One of the biggest challenges for managers who work with distributed teams is building and sustaining mutual trust. When a manager can’t see their employees on a day-to-day basis, and doesn’t have visual confirmation that they’re hard at work throughout the day, mutual trust is indispensable. Work can break down in countless ways when trust is lacking because humans are emotion-driven creatures. We want the people around us to believe we’re working hard, trying our best, or at the very least acting in good faith. At the same time, we sometimes doubt that others share our integrity.
Scott frames his goals as a manager with the perspective of his own past experience as an employee:
I thought that I was a good team manager in that I remembered all of my bad experiences as an employee, and I tried to work really hard not to repeat those mistakes. And I gave a lot of autonomy to employees because I was one of those employees who liked a lot of control. Once I’ve earned some trust I wanted to be able to run and go at full speed. And the best managers I had are [the] ones who are comfortable giving me that much control. And I tried to rely on that as a strength coming to Automattic because everyone was already independent. I have to start out by saying I may not actually add any value at all. I need to observe first to see how things are going before I have any reason to change anything.
In order to earn trust, explains Scott, you have to give trust freely, a trick he learned from a marriage counselor. But this advice comes with a caveat: “The only way to do that is to give them something that you’re entirely sure you should trust them with.” Then, once trust is established on a basic level, you should feel more confident about putting something more complex, difficult, or important in their hands. This incremental trust-giving lays the groundwork for a work relationship that can thrive when constant monitoring is neither desirable nor practical. Even when managers can tightly monitor their teams visually, they can’t always ensure that people are actually being productive.
Another crucial element of trust-building is a sense of camaraderie among team members. Many distributed companies host team and company-wide meetups to help their employees bond with one another, but these can’t entirely substitute for the day-to-day “water cooler” connections that we associate with colocated office environments. This intangible component of work leads to one of the most common sources of skepticism around the distributed model: How can people generate the serendipitous conversations that happen in an office? Scott argues that you can replicate this phenomenon over chat, and that it happens organically:
All the claims people make about serendipity, [like] “You’ll lose all the serendipity of meeting people in the hallway.” You can replicate all that. That’s what the group chat rooms are for, where you jump in and you’re bored and you see all the other people who are procrastinating on something. You don’t see them but you can chat with them. There’s randomness and surprise that can happen in any group situation.
Scott’s book quotes chat dialogues where people talk about their families, their pets, and their hangovers. Employees can’t only socialize around work-related matters; teams tend to operate more efficiently when team members genuinely like one another. This kind of chatter is an indispensable release valve during the workday, and it boosts productivity by bringing teams closer together.
Respect is another element of trust-building, and Scott argues that this is especially crucial for teams of distributed professionals. One practical approach is to establish policies that allow employees to set reasonable work/life boundaries within the context of time zone differences: for example, normalizing asynchronous communication and budgeting enough time for team members spread across the globe to respond to questions. Another is to give people the support and tools they need to produce their best work:
Autonomy is really important to creative people and not in a superficial way. I think that their tools are so important. A big corporation that hires programmers and tells them “You have to use this old computer,” or something — that’s a lack of respect for what you hired them to do.
If you believe that your work is important, and you trust someone else enough to invite them to join you in that work, it’s important to pay them an amount of respect proportional to that trust.
Remote relationships built on trust and respect can be just as, if not more meaningful and productive than ones mediated in a traditional office setting. Any relationship that only works when one party can constantly surveil the other is bound to generate anxiety and resentment on both sides.
Choosing the right tool
Trust and respect serve to catalyze a strong working relationship, but clear and frequent communication is required to sustain it. At first Scott was skeptical: could digital communication tools approximate the fidelity of face-to-face conversations? Over the course of his time at Automattic, he came to believe that good remote communication was simply a matter of choosing the right tool:
Every communication tool is good for some things and bad for others. And text has the advantage that you have time to think but the downside is that written language takes away a lot of data. You can’t hear someone’s inflection in their voice, or pick up on how loud or quiet they are. There’s a lot of data that you lose. And having a moment every week where we were on audio, even if it was just for five minutes or ten minutes, emotionally, in terms of your relationship, in terms of understanding people’s nuances and sense of humor, their sarcasm — you could only get that through audio.
Scott explains that teams don’t really need hours of audio or visual communication in order to work together effectively. He suggests that even a 10-minute group call once a week, when everyone can at least hear everyone else’s voice, can do the trick. In fact, shorter meetings are better for everyone. Participants feel like their time was well spent after a short meeting because they feel equipped with the knowledge they need to move forward with their projects, but they don’t veer into tangential conversations that don’t apply to the entire group. Those can happen in follow-up text chat or one-on-one video calls.
Sometimes resolving an issue with a colleague was as simple as picking up the phone (or launching a Zoom call).
If I can get them on the phone and they hear my voice, and I can offer them my true empathy for — “I want you to do well, my job is to see you do well.” They get that empathy. Our brains respond to that more directly through voice and eye contact and facial expression.
In situations like this, Scott’s teammates were likely to share more about the issues they were experiencing because they were able to recognize the empathy in Scott’s demeanor. It became easier for Scott to determine what was really going on. Sometimes what seemed to be major issues turned out, after a quick call, to have simple solutions — like tweaking the way he assigned tasks and projects.
Don’t Surveil, Observe
Scott doesn’t suggest that managers unconditionally trust their remote employees to manage their time and projects in good faith. This trust should be reinforced by frequent check-ins that feel helpful rather than authoritarian, in addition to show-your-work processes that foster transparency.
When checking in, Scott recommends asking questions before a problem arises: “Do we have the same expectation and view of the world?” If that is the case, the manager can check in again a few days later to make sure everyone remains aligned. If not:
Ninety percent of the time, there is a reason. “Oh, this other issue came up that was more important, I forgot to mention it to you.” I’m like, “OK, great, now I understand, I can recalibrate.” But someone has to be that check-in maintainer that is driven by whoever is in the leadership role.
Transparent processes that run in the background enable managers to assess their direct reports’ performance and assist them between check-ins. This might entail working in Google Docs so that revision histories are accessible, or asking developers to submit code commits in a team channel, to keep everyone on the team up-to-date on what everyone else is doing. The goal is not to surveil, but to observe, so that every team member’s needs — professional and emotional — can be met.
Digital communications are great for conveying information, but they also excel at storing data that might otherwise be lost forever. Automattic developed a tool called P2, which was originally conceived for real-time communications, but evolved into an internal space for announcements and project documentation. Everything Automatticians post on a P2 is archived, so every conversation happening on the platform is both accessible and searchable.
Some teams also save video recordings of meetings, so that anyone who misses the conversation can watch them asynchronously at their convenience. This level of conversational transparency makes it easier to manage distributed teams. Everyone knows what everyone else on their team is working on, and the presence of shared, saved, and searchable communications creates a kind of accountability that you wouldn’t find in a conventional office.
‘All work is remote work’
As more companies recognize these advantages, distributed work will become more common. Scott helps to normalize distributed work by reminding people that a lot of us are already remote workers and don’t even realize it.
Remote is such a part of our culture now. Anytime you’re on your phone, interacting with another person through a screen — and it could be an iPad or a laptop — you’re doing remote work. People do remote work at their non-remote jobs all the time and in some cases it’s 50 or 60 percent of their time at work.
He further suggests that those who remain skeptical about remote work may have experienced a lack of shared trust, a problem that we encounter among distributed and colocated teams alike.
I don’t think your problem with remote work is about the remoteness of it. Your problem with remote work is probably you don’t trust your team, your boss is a micromanager, you don’t have clear roles, you don’t have a good way to define who does what projects or to track them. And that’s got nothing to do with remoteness, that’s just basic competence as a team.
Because there weren’t any managers at Automattic when Scott joined the company, it was up to him to define what that role would look like. He uses the metaphor of a coxswain yelling out the rhythm for a rowing team.
They’re taking up weight on the boat simply to be the person who’s controlling the rhythm. And any team, even if people are working individually… someone has to be setting the rhythm for the week, the rhythm for the month, and to help people set their own rhythm for the day. And that’s what I thought my job was.
Ultimately, one of the advantages of distributed work is that it encourages managers to let go, trust their team members, and focus more of their efforts on empowering them and aligning their goals. Instead of focusing on how much time a colleague is spending to complete a given task, the distributed model forces managers to focus on output and results. This makes for a healthier work environment for everyone.
