Tag Archives: p2

Distributed FAQ: How Did P2 Become Automattic’s Signature Mode of Communication?

In Distributed FAQ, Matt Mullenweg addresses some of the most common issues companies, executives, and individuals face as they consider transitioning to a distributed model.

Q. Automattic is known for using internal blogs called P2s for most work-related conversations. How and why did that happen?

A. In Automattic’s early days, we collaborated a lot directly in the code, or on IRC (Internet Relay Chat), a Slack precursor. We quickly realized that it wasn’t great for asynchronous discussions, and when we tried email instead, it didn’t allow for the transparency that is the hallmark of open source (it also brought a lot of noise with it). Finally, we ditched email and moved to an internal blogging system. P2 is the evolution of the blog for the purpose of working within and across teams. It’s organized much like a Yammer or Facebook stream, but on the back end it still operates like a blog, allowing for archiving, advanced search, and rich media embeds. 

More

Distributed FAQ: How Does Crisis Management Work in a Remote Context?

In Distributed FAQ, Matt Mullenweg addresses some of the most common issues companies, executives, and individuals face as they consider transitioning to a distributed model.

Q. How do you tackle crises and tough situations in a remote setting, when it’s impossible to gather all the relevant parties in one room?

A. The number-one priority is communication. Communicating often and transparently is key. At Automattic, we have a company-wide Slack #announcements channel that will link to a P2 blog post for additional context. We advocate for a framework of radical candor. 

We’re a distributed company, but we deal with the same challenges as other companies, including security breaches, hacks, downtime, fraud, and employee issues. I believe that conversations that happen in written form can be very helpful — they’re archived, so we can refer back to them, and they facilitate learning. One person can share a written summary with their interlocutor so they come to a shared understanding.

While working distributed, you can de-escalate yourself easily. You can take a break. A micro-habit you may want to introduce is to take a mindful minute and breathe.

And one final guideline we’ve adopted over the years, after seeing it defuse tough, challenging moments: assume positive intent (lovingly dubbed API) in all communications. Take the extra moment to consider how you might have misinterpreted a colleague’s words, or how they may have misread yours.

For more on communication and chaos, listen to Matt’s conversation with Automattic’s Sonal Gupta.

Distributed FAQ: What Are the Key Tools for Creating an Effective Remote Work Environment?

In Distributed FAQ, Matt Mullenweg addresses some of the most common issues companies, executives, and individuals face as they consider transitioning to a distributed model.

Q. What are the necessary tools and processes to create an effective remote work environment?

A. There’s a lot to say here, of course, so let’s start with a few fundamentals:

  • Choose a small set of core applications for the entire organization, for example Zoom for video calls, Slack for day-to-day conversations, and G Suite for documents, spreadsheets, and (if you choose to use it) email. 
  • Foster a strong sense of autonomy. Give individual teams a lot of freedom to choose the rest of their stack, whether it’s GitHub for development, Asana or Trello for project management, InVision or Figma for design, and so on.
  • Try out a no-email approach. At Automattic, our secret sauce is that we don’t use email within the company. Instead, we have an internal blogging system called P2. P2 displays all conversations on a team or project’s homepage, updates in real time, and comes with the built-in benefit of being a searchable blog. You can also tag individuals and teams on P2. This system creates rich conversations that happen asynchronously and then become the collective wisdom of Automattic. We publish well over 1,000 posts and comments every day.
  • Default to public. At Automattic, we’ve developed a very valuable instinct: always default to everything being public (within the company, that is) — always default to trust.
  • Invest in solid video conferencing tools. Having a good setup for video calls is very important. Audio quality is essential if you’re on a lot of calls, so go for a good headset or use noise-cancelling software. A good desk lamp to illuminate your face can make a real difference. And give some thought to the background people will see behind you — it can have personality, but you’ll want to keep it from getting too cluttered. 

For a comprehensive list of recommended hardware and software for remote workers, check out our Tools and Gears page, as well as Matt’s “What’s in My Bag?” posts.

Remote Work Depends on Access to Information — and on Mutual Trust

When it comes to work, it never made much sense to give away all your secrets. The predominant culture of information hoarding and hiding exists partly because many of us live in fear for our jobs:

If I tell everyone exactly how I do my job, they can just get rid of me! 

If you don’t get along with your boss, they might fire you — so you try to make yourself as invaluable as possible. If you’re an expert, if you’re “irreplaceable,” then perhaps they’ll think twice.  

More

On Building Automattic

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. 

More