Launching the Distributed podcast has given me space to reflect on the last 14 years at Automattic. In 2019, distributed work has spread throughout the Bay Area and beyond, but when we were getting started, having no corporate headquarters was seen as quirky. Our distributed status has come to define our company, but we didn’t set out to be distributed. It was common in open source projects and our initial team was spread around the world. But over time it became who we are.
I’m originally from Houston, Texas. In 2003, web developer Mike Little and I, along with a few other online friends, developed a web publishing tool called WordPress. It quickly became popular, but we had no inkling that it could ever be a revenue-generating project. We just wanted to make better publishing tools so that non-engineers could express themselves online with their own blogs. For me, it was satisfying simply to hang out on IRC (an early chatroom protocol) with smart, curious people working on an interesting collaboration. I was spending all my free time online, hanging out and coding with people all over the world, having an absolute blast.
WordPress made a big enough splash that some important people in San Francisco’s tech scene took notice. An early tech media site called CNET began to use WordPress, and they offered me a role as a product manager in 2004. I dropped out of college and my mom and I drove from Texas to San Francisco. I was now in the epicenter of the Web 2.0 social media boom, and blogging was already an important part of that scene.
Working for CNET was pretty cool. They were one of the first companies to actually set up their headquarters in San Francisco, as opposed to down in Mountain View, Cupertino, or San Jose. They set me up in an opulent corner office at first, but I was later demoted to an interior, windowless office during a restructuring. Then I was further banished into the basement when another department took over the floor. In my tiny, underground bunker, I began to think that maybe office life was not for me.
The Blogging Wars
At the time, CNET owned thousands of domains from various acquisitions, such as “com.com” and “download.com.” I found a list of these domains and pinpointed “online.com,” which I thought could be repurposed into a new home for WordPress. I pitched some senior folks at CNET on a version of WordPress that would be even more accessible to a mass audience. Instead of having to know PHP, FTP, and how to configure a database, users could start up a blog in a few clicks, no coding required. My vision for the domain was a personalized network that would host blogs such as “matt.online.com.” This would be your online home, with a blog and a profile, and maybe some customizable widgets created by the community.
As is often the case with bold ideas, the commercial environment wasn’t ready. There was a colossal battle going on between blogs and traditional publications in those days. Large media sites saw the writing on the wall, and were thus experimenting with blogs using different publishing platforms. Yahoo had one called 360. AOL had Journals, Microsoft had Live Spaces, and Google had (and still has) Blogger. This made for a seemingly crowded space that CNET felt would be difficult to enter, and like many media companies at the time, they believed that bloggers were going to be relegated to the fringe. Bloggers were perceived as passionate geeks talking about their niche interests or as loud cranks who would never be hired at a magazine or newspaper. In other words, there was blogging, and there was serious journalism, and CNET bet on the latter.
This attitude shifted over the next few years. Gawker and Weblogs Inc. established scrappy blog networks which would one day challenge powerful media incumbents and change the face of journalism forever by publishing faster (and sometimes smarter) content than well-funded media companies with hundreds of employees.
But in 2004, those large media companies were still feeling comfortable, with publication models that were still largely based on a lucrative online replication of print-media assets. CNET was one of the more forward-thinking media companies on the web, but I knew that if I wanted to see blogging opened up to the masses, it probably wasn’t going to happen inside a large media company that was invested in protecting the status quo.
I parted ways with CNET amicably after finishing up a few projects, and the company very graciously invested in my venture, which came to be known as Automattic. I began trying to convince my developer friends that had worked with me on WordPress to leave their jobs so they could do it full time.
Stumbling Toward a Distributed Future
Our beginnings were humble. With no money, I was paying the early employees out of my dwindling CNET salary savings, and racking up credit card debt to keep the servers running. Our distributed origins arose out of this lack. We simply couldn’t afford to have everyone move to San Francisco, and we couldn’t justify the expense of office space.
What would have been the point? We were already working well together, and in fact we’d developed a productive rhythm, where I’d work long, 10-to-16-hour days on Pacific Standard Time, and then a colleague in another time zone would begin their day as I was going to sleep. I’d wake up in the morning to see a whole cycle of updates made to the software, and would once again grab the baton for another long day of work. This format allowed us to iterate quickly and reinforced in my mind the benefits of asynchronous collaboration.
So our distributed roots did not come from some grand vision, but instead emerged from cold realities. Colocation (being in the same place, at the same time) is expensive!
At the time we were communicating through AOL’s Instant Messenger software, then called AIM. We also used IRC and a collaborative coding platform called Trac. Even though the tools have evolved, the user experience with collaboration tools like these hasn’t changed much. We’re still using a chatroom, even if it’s called Slack instead of IRC.
We used Skype for voice calls, but those were only happening a few times a year. From the beginning, Automattic had a written communication style. Engineers tend to be introverted, and thus often prefer written communication. So this format fit our needs for a long time.
We held the first WordPress meetup at an Indian place called Chaat Cafe on Third Street in San Francisco (it’s still there!). Most of those people went on to do some incredible things. There was Chris Messina, who at the time was involved with the Drupal Project, and who would later go on to invent the hashtag. Scott Beale represented Laughing Squid, an amazing blog and web host, the host now focused mainly on WordPress. Om Malik, a journalist at Business 2.0, later started GigaOm and became one of the earliest WordPress users. I met my colleague Ryan Boren for the first time at this meetup. At the time he had not yet quit his day job as an engineer at Cisco, but he was one of the first major contributors to WordPress core.
We developed a business model in those early days that generated enough money to keep us working on making steady improvements to the product. We sold add-ons and custom design options, domain names, and the like. We developed partnerships with hosting companies that would pay us for new customers whose WordPress blogs they’d then host. Today’s WordPress monetization strategies aren’t all that different from what we were doing back then.
A few of us were working on WordPress full time at that point, which made us feel like we had achieved the dream. Our goal was to sustain a base level of comfort so that we could spend our days building open source tools that we thought were exciting and important.
I was 21 at that point. In those pre-Zuckerberg days, when investors gave a bunch of money to a promising startup, they typically brought in “adult supervision.” Young founders were often subordinated to a new CEO who had deep experience working in a related industry. They were happy to give millions of dollars to an enterprising youngster, but on the condition that a seasoned industry vet had final decision-making power. I wasn’t particularly interested in such an outcome, so I didn’t pursue investment vigorously.
My outlook changed when Om Malik introduced me to a Yahoo executive named Toni Schneider. He’d gone to Stanford and had a few startups under his belt as well as a successful exit to Yahoo. I felt that if this guy, who struck me as an amazing individual, was the adult supervision, it could work — we had an instant rapport, he was my “business soulmate.” I learned a lot from Toni, and he helped us raise about $1.1 million from folks who we still work with today, like Phil Black at True Ventures, and Doug Mackenzie and Kevin Compton at Radar. Toni continued as CEO for many years and stayed on at the company when I took the CEO reins in 2014.
At this point, we knew that we needed to have a place for face-to-face meetings, and that usually means that it’s time to rent office space. We managed to resist this pressure, meeting up in coffee shops and occasionally at the offices of one of our investors in the Presidio. Later on that investor, which became True Ventures, moved to a space on Pier 38, and they allowed a bunch of their startups to have tables there. GigaOm claimed one table, and upstairs was Burbn, which later became Instagram. A few of us worked there with some regularity, but it made no sense to try to move the whole company there. These early Automatticians were perfectly happy where they were.
Many investors told us that while this distributed model was working with 10 or 15 people, at some point we’d need to bring everyone to one place. We kept that advice in the back of our minds. While we did end up moving to a larger space on Pier 38 across the hall from True Ventures, it was never an official headquarters where a majority of employees gathered. As we grew, the ratio of employees coming into this office stayed at about 10-15 percent.
San Francisco parking and traffic got steadily worse over the years, so even the Bay Area employees that liked to come into the office were less inclined to do so. On top of that, our team was already geographically dispersed, with employees across the U.S. and in Ireland, Australia, Bulgaria and elsewhere. Meanwhile, remote communication and collaboration tools were improving, so the argument for colocation diminished over time. Whatever tools we needed but couldn’t find, we built ourselves.
Building Our Own
Despite the proliferation of digital communications tools, we knew that occasionally meeting up face-to-face was going to be crucial to our group cohesion. One of the first meetups we held was just north of San Francisco at Stinson Beach. We rented a couple of houses but we hadn’t devoted a lot of time to define the goals of this meetup. We ended up spending our time having day-long meetings and debates about the direction of various projects. Some of these discussions got heated. We realized that we weren’t really making good use of this rare face time; it was not the rich exchange of ideas we had hoped for. We decided to make these meetups more structured, with one big meetup per year, and a number of smaller, project-based meetups that were focused on quickly hacking together a new product or update. This intense collaboration was difficult to replicate with the digital tools of the day.
But one of these meetups yielded a new tool that would make our digital communications better than ever. It would be called P2, and it’d become Automattic’s foundational communications tool to this day.
We still had a flat hierarchy at that point with no teams and no managers. We organized organically around projects and code, and for the most part, everyone knew what was going on across the company. Information was shared openly, and there was a collective intelligence at work, where everyone pitched in on every project. But as we grew, we knew that we needed stronger communication tools.
All of us were already using WordPress, which gave every employee a good ground-level view of the product. We had real-time user testing happening in the background all the time, which sped up the iteration cycle and led to some very usable products, even in early iterations.
We had an internal blog in IRC which we used much like people use Twitter, which was still in its infancy at the time. This was a place to let everyone know what you were up to. The idea of real-time status updates was just starting to bubble up on services like Facebook, Twitter, and Tumblr. Eventually we realized that this could be a powerful tool for a distributed company, and we started building updates like comments and threaded discussions. In addition to real-time communications, we recognized that it could serve as a repository of company data. Brainstorms, important discussions, and institutional knowledge were being lost to the void across the various media we were using, especially email, and we felt that this would be a way to keep conversations stored in one universally-accessible, searchable place.
We dubbed this tool Prologue, and a later iteration (also born at a meetup) became P2. This update made Prologue work in real time, so that posts could be made visible to everyone without them having to refresh the page. There are now hundreds of P2s across the company, all of which are completely searchable.
At the same time, our support requests were all coming in via email, which everyone in the company would receive. Whoever replied first would claim that email and was expected to resolve the issue. So P2 became a way for us to field these support requests while building a knowledge base. This development enabled us to initiate a collaborative approach to support, and even more transformatively, put us on the road to eliminating email completely.
At 50 employees, it became obvious that some hierarchy would be necessary. In 2010 we hired our first mid-level manager, Scott Berkun, (stay tuned — we will be speaking with Scott in an upcoming podcast episode). Since then, our hierarchies have grown vertically and our org chart has grown deeper. We are still committed to the distributed model, so accountability and lines of responsibility are more crucial than ever.
We get the whole company together annually for what we call the Grand Meetup. This is a week dedicated to bonding and fun in a cool destination like La Paz, Mexico or Mont-Sainte-Anne, Québec or Budapest, Hungary. Throughout the year our individual teams meet for five to seven days for brainstorming sessions in various places. These smaller meetups involve some work and some play. Automatticians expect to spend up to a month each year working and hanging out with their teammates face to face. It’s a great way for our teams to build group cohesion and bang out special projects that are best suited to face-to-face collaboration.
We approach teams at Automattic fractally. This means that no matter how closely you zoom in or broadly you zoom out, the structure looks similar, just smaller or larger. Our teams consist of cross-functional roles — for example, a bunch of engineers, a designer, and a businessperson — and when that team grows to be above 10 or so members, the teams split into two groups of five. This policy prevents teams from growing so large that they become unwieldy. Our larger groups, which are made up of several teams, are called divisions These are designed to look and behave like the core teams, but bigger.
We still use P2, but after our mobile team began using the free version of Slack, we recognized it as a long-needed update to IRC. I knew the founder, Stewart Butterfield, and one of the early Automatticians had since moved to Slack as well. The product was undeniably good, and clearly modeled on the best elements of IRC. Eventually we made a mandatory company-wide switch and never looked back. P2 is used less for real-time communication these days and more as an internal space for announcements, longer asynchronous conversations, and project documentation.
Zoom was another tool that felt like a big upgrade from what we’d been using for years. As the company grew, psychological diversity grew. Many extroverts joined our ranks, and voice and video chat became more common. In the early days, the idea that we’d have an audio-only meeting would have been met with suspicion and would have been the subject of debate. For the most part, individual teams get to choose how they want to communicate. Usually it’s a mix of different media. Some use P2 every day, others only use it a few times a month for announcements and spend the rest of their time on Slack and Zoom.
I personally have contributed thousands of comments to P2. Over a million words. Everything is archived, and if I need to remind myself about a decision we made in 2012, I can search for that and find it easily, along with all of the debate and commentary around that decision. So it becomes a rich source of wisdom that has allowed the company to evolve more intelligently. It keeps us from making the same mistakes more than once.
Work at Automattic is unconventional in a number of ways, but I think our culture and practices have enabled us to thrive. That being said, I never want us to stop iterating and experimenting with new ideas. Some distributed companies have all their employees log on during the same work hours, and I think this is worth exploring, perhaps with an individual team. I’d also like to find better ways to foster psychological safety, so that everyone in the company knows that their ideas are worthy of consideration, no matter how long they’ve worked for the company or how far-flung they are.
Tomorrow’s knowledge workers are going to ask more sophisticated questions of distributed companies beyond the binary of whether or not they’ll be able to work remotely. They’ll want to know where the center of gravity for that organization is, and whether or not their contributions will be valued if they’re not working out of a corporate headquarters in the Bay Area. I hope that the distributed model we’ve helped to pioneer will empower these workers while simultaneously providing value to employers, as it has at Automattic.
We’ve spent the last 14 years working out some of the major kinks in the distributed model, but my aspiration is to spend the next 14 making it work even better. These are not easy problems to solve, but I believe Automattic is uniquely prepared to take them on because we’re always changing and ready to evolve. I hope the Automattic of 2033 looks very different from the Automattic of today.