When Automattic CEO Matt Mullenweg hired the company’s first five employees in 2005, they were located in cities around the world. Thus began an experiment in distributed working, one Mullenweg wasn’t sure would last. As Automattic grew, Mullenweg believed that at some point, he would have to bring everyone together to work in a traditional office.
But as time went on, Mullenweg began to view the company’s worldwide distributed workforce as a strength that decreased single points of failure. There were few events, be they political unrest or natural disasters, that could affect the company as a whole.
As Automattic hired more employees, Mullenweg worked to cultivate an environment that gave employees the space and support to grow—for instance, by training existing employees on new technologies, rather than replacing them, in order to adapt to a changing web.
Automattic’s unique way of hiring, growing, and retaining distributed global talent became something of a secret weapon for the company, enabling it to not just withstand but improve from volatile conditions in the tech industry and environment. “As long as [being a distributed company] was working from a customer and business point of view,” Mullenweg says, “I saw no reason to change the formula significantly.”
Remote work is not a new concept. In the 1970s, telecommuting seemed poised to revolutionize work, but the movement was slow to catch on. The issues facing early remote work evangelists were primarily technological, with lagging internet speeds and limited options for real-time communication marring progress. While some companies embraced remote and distributed work as technology advanced, this was not a uniform trend: Large players including IBM, Hewlett-Packard, and Yahoo abandoned remote working to return to traditional office setups, expecting it would boost company culture.
In 2020, the COVID-19 pandemic forced organizations across industries to experiment with remote work on an unprecedented scale. While many companies’ first instinct may be to retrofit existing managerial practices with remote communication tools, sustained, scalable remote work often benefits from entirely distinct practices. This might include communication strategies that allow for asynchronous and thoughtful sharing, team structures that enable members to take more autonomous ownership of their focus areas, and software development practices that encourage deliberate documentation and execution. Enabling a supportive environment in which employees can develop their skills and work with autonomy and purpose allows remote companies to thrive.
Increment spoke with three tech companies that have used a remote and distributed work model since their respective inceptions: Automattic, which has evolved its processes over the last two decades to allow for fully asynchronous work; Auth0, a distributed company that launched in 2013 and, five years later, found itself needing to evolve as it experienced explosive growth; and Basecamp, a company that created its own software methodology to suit its remote environment.
Automattic: Building a distributed company, asynchronously
Automattic has managed a globally distributed workforce since its founding. As employees in Asia are logging off for the day, those in the Americas are just starting theirs. Developing a smooth passing of the baton was critical for work to progress seamlessly, though there were some false starts. In the company’s early years, all communication happened on IRC (Internet Relay Chat), Skype, and email, until eventually Automattic launched an in-office blog. While this seemed like it would be a natural fit for a company with WordPress at its heart, the blog was largely forgotten and ignored.
Then, in 2008, Mullenweg and two colleagues developed Prologue, a blogging theme that added a posting box to its homepage and gave it a parsable news feed. Still an awkward fit for real-time conversations, the team iterated upon it and built P2. Because in-person discussions simply aren’t a possibility for teams at Automattic except during annual meetups, this replacement had to allow for robust and thoughtful communication. With threaded conversations and real-time notifications, P2—now described as the company’s “lifeblood”—became Automattic’s default asynchronous communication platform.
A recent example that demonstrates P2’s value: During a routine customer research study for Automattic’s Jetpack product, the team discovered users were particularly interested in the plug-in’s real-time backup feature. Bundled with malware scans, search, and other performance and marketing features, backup was an insurance policy for website owners. The feature was particularly attractive to e-commerce site owners, for whom the loss of a single order could deeply impact business.
As is typical of Automattic’s autonomous and transparent team ethos, the Jetpack team posted on P2 about their decision to make backup a robust standalone product, tagging in teams, such as billing, that would be directly affected by the change.
The blog-like P2 post allowed the writer to share their reasoning uninterrupted, while the nested comments below opened the floor for discussion. Unlike in a traditional co-located office meeting, this process doesn’t favor extroverts over quieter thinkers. Company-wide consensus is not the goal—teams have the leeway to make their own decisions—but the process allows for a breadth of input and expertise. The result is a slow but deliberate decision-making process.
“That’s what democracy does,” says James Grierson, Jetpack’s general manager. “It helps you see things from a lot of angles, argue them out, and figure out where you want to go.”
The post allowed colleagues across the company to share their thoughts and concerns with the Jetpack team. After deliberating, in September 2019 Jetpack formed two teams of engineers to build backup into a standalone product.
Along with P2, which was used to document product decisions, the team relied on Slack for daily stand-ups and private chats and Asana for project management. In March 2020, Jetpack Backup was released as a standalone product.
Prior to joining Automattic, Grierson was CEO of Bluehost, where he oversaw 800 employees in two adjacent buildings—a fairly traditional office setup. “In an office setting I have to wait for somebody to be in the office and not be busy to respond to me,” Grierson says. This is in sharp contrast to an asynchronous distributed model, in which documentation is accessible with a P2 search, and colleagues and HR representatives are a Slack message away. “The distributed nature allows you to get answers way faster,” Grierson says, so long as employees feel comfortable taking the initiative to learn and ask questions.
The hiring process at Automattic is designed in such a way that it screens candidates for their suitability to this environment. Initially, Automattic screened candidates based on their academic credentials and whiteboard tests, a standard industry practice. A number of issues emerged, however, including a lack of standardization between MIT and India’s IIT degrees. More broadly, the company found little correlation between a candidate’s academic credentials and their ability to perform.
Hiring now happens through an audition process that closely replicates the company’s work and environment. Interviews take the form of text-only chats on Slack, and the process culminates in a two to eight-week paid trial project in which candidates work on realistic tasks via Slack, GitHub, and P2. By the end of this process, it’s evident to both candidates and the company whether they’re suited for Automattic’s asynchronous work style.
The company so strongly emphasizes asynchronous communication that a core part of the onboarding process for hired candidates is learning to navigate P2. All new hires complete a “happiness” rotation, in which their first two weeks on the job are spent working in customer support. Learning to comb through Automattic’s internal systems to find information relevant to customer queries trains employees to effectively perform their own roles.
“You may not be hired to do a support role, but you learn how to support by training and searching,” Grierson says. “So you go through our different documentation and P2 to find answers to customer questions.”
Grierson recommends all engineers spend up to half their time on P2 to stay up to date and fill in their own documentation as a form of future-proofing: An engineer looking to understand why and how decisions are made will continue to have a written record they can rely on. The platform can also accelerate onboarding. “Usually you have to dissect the code for a few months and talk to a lot of the stakeholders who helped build it and understand their reasoning,” Grierson says. By proactively using the P2 archives, however, a recently hired engineer can start contributing immediately.
Affording employees autonomy over their work and schedule helps Automattic retain talent. (The company’s regretted attrition is under 5 percent.) This is matched with the deliberate practice of paying employees the same rate for the same work, regardless of geographical location, and ensuring they have the support and freedom they need to keep learning. An internal developer experience team is dedicated to identifying and providing opportunities for growth—for instance, Grierson’s team completed the leadership engineering program LeadDev Together earlier this year.
Mullenweg says he hires with the expectation that employees will ideally be at the company for a decade or more, which means the company has to thoughtfully implement structures that promote trust. “My father worked [as an engineer] for the same company for 27 years in Houston and was incredibly loyal,” he says. When Mullenweg was hired for his first engineering job at a comparable salary, “[my father] was simultaneously proud of me and [like], ‘What’s going on here?’ He started to look around and actually left his company and doubled or tripled his salary. That kind of broke my heart. I want someone who is loyal to Automattic to be rewarded with loyalty in return.”
Auth0: Building distributed product teams, strategically
Auth0 helps developers integrate authentication and authorization into their applications, which the company describes as “identity-as-a-service.” With CEO Eugenio Pace based in Washington state and CTO Matias Woloski based 7,000 miles away in Buenos Aires, Auth0 has been remote first since its founding in 2013.
Intent on striking product-market fit, everything ran smoothly for the first couple years: Communication was good, trust was deep, and the company’s team of 20 to 30 engineers embraced its remote work environment. Having engineers simply split into two teams—backend and frontend—provided enough definition to the product organization’s structure.
Then, in 2016, sales started to skyrocket. The sales department wanted to be co-located to improve team cohesion, and Auth0 opened an office in Bellevue, Washington, to accommodate that. The company shifted to a hybrid office and remote model, renting coworking spaces in Buenos Aires, Tokyo, London, Singapore, and Sydney. But rather than treat these as traditional offices, the product engineering department decided to use them as relationship-building hubs. Around 50 percent of product employees are based in cities with an office; these team members go in if and when they want to network with colleagues, customers, and other industry professionals. Prior to the pandemic, Woloski visited the company’s Buenos Aires hub twice a week, to “chit-chat, have lunch, and do all the things that social humans do.”
The optional, rather than operational, nature of these hubs meant that all work and documentation for product engineering had to remain reliably remote. “The important thing is that we keep [our operational] system remote. That’s nonnegotiable,” Woloski says.
With scale, Woloski says, the focus “[switched] from building the product to building the organization that builds the product.” It became critical to define team structures such that each team had full ownership over their product areas, meaningful roadmaps, and the autonomy to go ahead and work on those product areas and roadmaps independently.
Auth0 began to structure its teams based on product functionality. This model yielded five teams: protocols, API and platform, two-factor authentication, team accounts, and core infrastructure. Defining “purposeful autonomous teams that can move at their own pace and choose their own tools,” Woloski says, was particularly critical in a remote environment. “[Teams had to have] ownership of both the endpoints and the code,” he adds, to enable focused, autonomous work.
But cracks started to appear in this organizational structure too. Thus far, Auth0 could be deployed in a public cloud multi-tenant environment, with multiple customers sharing the same resource. A new premium offering was making it possible to also offer a white-glove service, guaranteeing a customer a single-tenant environment and a customized onboarding process along with it. At the same time, Auth0 signed on their largest client, Atlassian, necessitating that the product handle several orders of magnitude more logins per second than it did then. “We were ready with all our attitude,” Woloski says—but it was clear the product and structure would need to evolve.
With the product in flux and the company experiencing quick growth, teams started to see an uneven distribution of technical debt, security, and other issues—the protocol team could have thousands of issues, while the API and platform team only had a few. This imbalance proved difficult to manage. There was also the worry of issues falling across teams and between teams.
“You start having these bottlenecks in some part of the organization, and you solve those by hiring more people,” says Woloski. “That’s one of the harder things, because it’s like you’re flying the plane and replacing a wing.”
Hiring new engineers and ramping them up to start contributing took time and energy—resources the already overextended product engineering organization didn’t always have. Like Automattic, Auth0 implemented an audition process, which Woloski describes as demanding but the best way to evaluate applicants for performance and their comfort in a remote environment. Candidates are included in a Slack channel with members of the team they would work with if hired; together, they work on a technical exercise for eight to 12 hours over a week. The simulation helps assess how candidates communicate, respond to tough feedback, and structure solutions. “It’s a little dose of the person [for the company],” Woloski says, “and of the company for the person.”
Auth0 grew to nearly 100 engineers by the year’s end. While having career hierarchies may not have mattered before, Woloski felt it was important for engineers to have titles that reflected their progress. “Early on, we felt titles didn’t matter, but that gets you up to a certain point,” Woloski says. “[Thereafter] people like to have titles and managers like to have an understanding of their growth.” To match this need, Auth0 introduced a technical track and a management track for engineers, which placed staff engineers at the same level and pay grade as managers, and principal engineers at the same level as directors.
By 2018, Auth0 had 150 engineers and product engineering was reorganized again, into three clearly defined business units that could each grow on their own: identity and access management, developer experience, and service management. Each domain contains multiple product teams, with distinct roadmaps and leaders. Although Woloski likes to revisit the possibility of reorganization every six to 12 months, he warns that these are not to be taken lightly—it takes concentrated effort to build team spirit in a remote environment and people don’t like to shift teams every few months. “Youʼre shipping your organization, in a way,” Woloski says, while always ensuring teams are healthy and functioning optimally.
Cultivating trust and “sentiment” within remote teams has required intentional and thoughtful work. “We do a lot of things to keep the level of communication and serendipity high. But you have to curate it,” Woloski says. Auth0 primarily communicates through Slack, Zoom, and Confluence. It also uses the Slack app Donut to randomly select up to three people for free-form, personal calls unrelated to work. Engineers are encouraged to do code reviews asynchronously using GitHub, but pair programming happens in real time using Visual Studio Live Share or Zoom. Regular company events, like virtual designathons and hackathons, are also organized to build team spirit.
A strong, cohesive technical organization that thrives in a remote environment is the result of careful modifications made to its structure and strategy over time. While vanity metrics, such as active users, aren’t a reliable measure of the health of such a technical organization, they can be an indicator that something’s broken beneath the surface. “Engineers like to have impact. Probably the biggest motivator is that the stuff that’s built is being battle-tested and [that] it’s useful for someone else,” Woloski says. Blips in vanity metrics can signal that the right people aren’t being hired or thoughtfully onboarded, or that teams aren’t adequately supported or given substantial roadmaps to work from.
“If you expect that a remote organization just works, then you will be disappointed,” Woloski says. “It requires a lot of thinking and conscious implementation of strategies.”
Basecamp: Building enduring software, remotely
Basecamp’s mission is ambitious: to build products that remain available until the end of the internet. It started as a consultancy firm called 37signals in 1999. In 2004, it began building its own products and released the Basecamp project management and communication software for teams. In 2014, the company rebranded as Basecamp.
In its 21 years of operation, Basecamp has grown slowly—and entirely remotely—to employ a staff of 60 people. In the beginning, the company didn’t use titles or hierarchies, but as the organization has matured, that’s changed. Although Basecamp’s turnover has always been low—employees have been at the company for an average of over five years, with head of strategy Ryan Singer, at the company for 17 years and counting, an outlying example—in order to measurably support employees’ career progression within and beyond the company, Basecamp shifted to formal career ladders and titles. “There’s a fundamental human satisfaction in knowing that you are better this year than you were last year,” Basecamp CTO David Heinemeier Hansson says. “Career progression gives you a roadmap for doing that.”
When Basecamp instituted a universal salary policy five years ago, it became imperative to precisely define and match performance criteria to each rung in its hierarchy of job titles. Employees now earn the same pay for the same job at the same level of seniority, regardless of geographical location or salary negotiation skills. The career ladder, replete with matching role and level descriptions, is publicly available so it’s clear to both the employee and the company when someone is ready for a promotion. “When they are due, you get to celebrate the fact that someone has taken a monumental leap forward, and they will be recognized both in terms of title, pay, and feedback from their colleagues,” Hansson says. Promotions, which are posted on the internal Basecamp account, are cause for company-wide celebration.
For engineers, Basecamp has instituted a five-tier career track: junior, programmer, senior, lead, and principal. Employees have scheduled career progression talks twice a year with their team leads, but “those five tiers essentially [run] the entire gamut [from] someone who just got elevated from an intern to someone who’s been at Basecamp for 20 years,” Hansson says. While the company expects all engineers to progress to senior, after that, it’s up to the individual whether they want to pursue a leadership role.
“Everyone at Basecamp today, all the way up to the CEO and CTO, are practitioners. I still do programming in addition to being the CTO, Jason [Fried] still does design in addition to being the CEO, and that filters through the entire organization,” Hansson says. Uniquely, Basecamp has no formal management layer. Instead of hiring managers, the company works to develop managerial skills among its existing staff. It isn’t enough for leads to be able to clearly define project requirements and tasks. In an organization where team members work closely together for years, if not decades, “[leads] must be able to review other people’s work in a kind, confident, and useful way.”
Being a lead programmer in Basecamp’s development process means reviewing others’ work—and managing up. If a product manager—often the CEO, in Basecamp’s case—expects all aspects of a feature to be implemented at the highest quality, its team lead is responsible for communicating what can realistically be achieved within the constraints of a six-week cycle.
The company defined its own software development methodology, Shape Up, to remotely form, prioritize, and execute product ideas over the course of six-week cycles. Prior to each cycle, product managers determine which features they want to build or improve. Meetings are frowned upon; as a result, real-time calls are typically small and reserved for debating product features. Most product feature pitches and decisions take the form of detailed written posts on the product strategy message board of the company’s own Basecamp account and include rough sketches as opposed to detailed wireframes.
“The software industry lures [us] into thinking that we can decide everything up front and estimate it in minute detail, and then we can know exactly how long something is going to take,” Hansson says. “It seems like it’s one of those zombie ideas—no matter how many times that concept is killed, it keeps coming back to life.”
Indeed, software development projects rest on a pyramid of scope, resources, and time: What are you going to build, with whom, and how quickly? When you attempt to define all three in advance, however, the structure tends to crumble. Instead of using estimates and extracting commitments from its product teams, usually made up of a single designer and developer, Basecamp uses “bets” and “appetites.” For instance, if there’s a bet to implement due dates on to-do lists in an appetite of six weeks, the team gets to determine the design and decide what concessions need to be made in its implementation. Testing, with the aid of an independent internal QA team, is also wrapped up in that six-week process, so that quality remains paramount.
“By releasing the scope to the team itself, you’re empowering [them] to make the detailed decisions required to ship software,” Hansson says. “This gives them not only a sense of autonomy, which is one of the key components of motivation, [but] it also ensures that you actually end up shipping something in six weeks.”
Setting the time constraint of the six-week development cycle and the expectation that “done means deployed” also allows the team to stand its ground against any unmet expectations. As a result, the team is left to work uninterrupted for the cycle, deciding for themselves what version of the feature they are comfortable building, getting tested, and shipping within that time frame. Work progresses consistently, and if a feature requires further refinement, it can be bet on for the next six-week cycle.
Everything Basecamp has shipped in the last 21 years has used some form of this methodology. A six-week cycle is enough to support a full, or “big-batch,” feature, or two to three “small-batch” tasks grouped together. A development cycle is followed by a two-week cooldown—breathing room to deal with bugs and plan the next cycle. The goal is a calm development process and a working environment that affords employees autonomy over 40-hour workweeks and freedom from work-related stress outside of them.
While the company recommends a two to four-hour overlap between employees’ own schedules and the workday in the Central Time Zone to allow for occasional real-time collaboration, work carries on primarily asynchronously using the Basecamp software. Stand-ups are replaced by automated questions, which allow employees to quickly write down what they’re focusing on that day or week. The Basecamp software’s chat feature, used in moderation for spontaneous messaging, is not the place for substantial discussions. The company institutes the guiding principle, “If it’s important, slow down.” That is, if a topic is important, it should be separated from the chatter and spun off into its own post on the relevant message board, which can then gain traction and be given careful thought by others.
Basecamp’s largely asynchronous Shape Up process can also be modified to support greenfield development for projects like Hey, a full-service premium email provider. Hey was released in 2020 after two years of development. In the beginning, work on the project was experimental, completed by a small core group that included Fried, Hansson, and design lead Jonas Downey. Once a crystallized idea was formed however, three designer-developer pairs were moved onto the project to run through six-week cycles.
“We initially built [Hey] as though it was going to be for corporate email only. And then about five months before our launch, we totally switched the saddle and decided to build a first version of it that was going to be for individuals,” Hansson says.
The Shape Up methodology allowed for such creative flexibility, in large part because the design wasn’t finalized up front. “You can easily also get into this churning thing where you’re just a feature factory, you don’t have a product mission [or] statement,” Hansson says. It was critical to define Hey’s product statement to afford flexibility in following product opportunities that cropped up, such as the change to an email service for individuals or the introduction of a feature that allows users to screen emails from first-time senders.
“All our products and Hey [were built by] 12 to 14 programmers, and there’s not a huge accelerator management structure around that,” Hansson says. A remote environment that’s kind, calm, and efficient can be “dramatically more productive.”