Pocket Book Reviews - The Year Without Pants

Scott, an ex-Microsoft-project-manager turned writer offers to work at Wordpress for a year to try out some ideas.

The CEO, Matt Mullenweg, was okay with this; at the time, Wordpress didn’t truck much with Project Managers, and wanted to try it out.

####This Book is Not At All Like “Remote”

Remote is a book about how Basecamp does remote, The Year Without Pants (TYWP) is a book about how Wordpress does remote. There are a lot of similarities, but the books read very, very differently.

It’s funny, though, the office cultures that the books describe are pretty similar.

While Basecamp uses Campfires and Basecamp for all of their discussions, Wordpress is more venerable, so they used IRC, Skype, and a asynchronous messaging tool that they hacked in to Wordpress called “P2” that’s so functionally identical to Basecamp that we could almost treat them as the same product.

Remote is a book of short-article-sized advice chunks. “Don’t do X”, an article might read, followed by five tight paragraphs on why not to do X.

The Year Without Pants is a book of extended anecdotes, compressed in some places, expanded in others, and much harder to adequately summarize. I’m going to try.

Summary Stuffs

There are three major things that happen in this book.

• 1: Wordpress throws a lot of parties

• 2: Wordpress’s unique culture has a valuable lesson for Steve

• 3: Steve brings valuable PM ideas to a company that’s mostly disorganized engineers.

Wordpress Throws A Lot of Parties

In order to fight some of the social isolation and disconnections that come from running a worldwide distributed company, Wordpress would hold a week-long all-hands once a year, and Scott’s team (which was also distributed worldwide) would meet up in exciting remote locales every couple of months.

_It’s the only week all year that all employees are in the same place. From the typical executive’s perspective, this puts even greater pressure on planning the week down to every second, to schedule presentations on what competitors are doing or to have leaders give strategic briefings. But little of this happens at Automattic. Instead of more structure, more chaos is introduced. Instead of an escape or a show, the company meet-up focuses on launching new ideas on Wordpress.com - not for practice but for real. Every team was instructed to pick a project for the week and ship it before they went home._

Wordpress Throws A Lot of Parties

There are many anecdotes where Scott stayed in a hotel in some distant dream-holiday location like Greece or Lisbon, drinking heavily with a bunch of software developers, and banged out quick prototypes together as a team.

I’ve definitely felt that delicious, creative rush of working on zany hackathon ideas or proof-of-concept prototypes with a small, focused team. It’s a great way to start a project, and I feel like that’s the time when being an in-person team is at its most potent. There is value, potentially tremendous value, to kicking off projects in real time, in distant locales, far away from home and other distractions.

Wordpress’s Unique Culture Has a Valuable Lesson for Steve

Wordpress is fully remote, like VRChat and Basecamp, and so a lot of the book is Steve agog that work is somehow getting done without meetings, managers, or offices, by people who seem to enjoy what they do. Apparently to someone from Microsoft, that is borderline _magical_. I'm going to leave a lot of those parts out, because a lot of them were covered in Remote.

• Wordpress also starts new engineers on the community team (who they call “happiness engineers”) before they’re thrown into the acid mines.

• Happiness Engineers are given access to the Grand Pile of Tickets and allowed to work on them, in a very self-directed fashion, at any time and pace that they feel like - the company maintains a public leaderboard of how many tickets are being resolved and how many documents are being created by each team member.

Wordpress’s Unique Culture Has a Valuable Lesson for Steve

• The company is composed of many small (3-5) autonomous teams of engineers, many of whom are wholly responsible for a few different components or products.

• Any engineer can push code to live at any time. There’s an advanced CI pipeline that allows engineers to push code to fixed percentages of users (“this feature is live across 10% of the product”) and measure the response before rolling out sitewide.

Wordpress’s Unique Culture Has a Valuable Lesson for Steve

• Engineers are expected to define metrics for the problems that they intend to solve, build measurements for those metrics into those features, and during (and post) launch, demonstrate that those features measurably, impactfully worked, then iterate to improve.

• However, the metrics were used to inform decision making, not to drive decision-making. “There’s no good KPI for KPIs”. Metrics were more focused on measuring whether the features worked at all - i.e. “we added the ability to create Glergs” - “how many Glergs are being created?” - rather than more abstract measurements.

Wordpress’s Unique Culture Has a Valuable Lesson for Steve

• All bugs are P1s all the time. Everyone is expected to hop in and fix bugs whenever they’re found.

• In fact, everyone is expected to pitch in and help all of the time with… everything, if they can.

• The company is built on pillars of trust - hire great people, trust they’re great, and get out of their way. Let them organize themselves and do their thing.

• While most teams defaulted to IRC and P2s (Slack and Basecamp, essentially), teams were expected to self-organize, and so many of them used whatever tools they felt like to organize their projects.

Wordpress’s Unique Culture Has a Valuable Lesson for Steve

• There is no QA. Every team is directly responsible for verifying and maintaining the quality of the components that they produce.

• There is no Ops. Every team is directly responsible for launching and monitoring the components that they produce.

• Employees are expected, like Valve employees, to be T-shaped - great at one thing, good at lots of things.

• Matt Mullenweg craves and protects the chaos, preferring “people over process”.

Wordpress’s Unique Culture Has a Valuable Lesson for Steve

• Most high-stakes decisions - including who was on what team, and the large-scale projects and goals for all of the teams - ended up on Matt’s plate.

• There were loads of monetization options, but the company exercised a lot of restraint about how it chose to monetize.

• Morale is very high. Everyone is smart, self-directed, and passionate about making good work happen.

Steve Brings Valuable Project Management Ideas to a Company That’s Mostly Disorganized.

• The “every bug is a P1” philosophy doesn’t work well when the incoming rate of bugs exceeds the team’s ability to solve them. With no formal bug-tracking or any way of triaging bugs, it was possible for more important bugs to sit around while engineers worked on whatever seemed most urgent to them. Matt didn’t seem to care, and the product seemed to work pretty well in aggregate anyways, so maybe just letting engineers work on whatever seems important actually works fine? Scott wasn’t sure.

• Meetings, while rare, could often be long, rambling, agendaless affairs.

Steve Brings Valuable Project Management Ideas to a Company That’s Mostly Disorganized.

• Engineering-driven features tended to be small, safe, conservative, non-intersecting, and incremental. This lead to “NASCAR design”: interfaces overcrowded with small, useful bits and beeples - and rarely led to a coherent or pleasant feeling design.

• For that same reason, when big ideas or large, complicated problems reared their ugly head, teams rarely mobilized to deal with them.

• The company’s aversion to schedules or planning left Scott feeling a bit like the company could use some fire and direction.

• The always-async discussion structure often left Scott not knowing who had seen which posts, and therefore whether quiet meant “sure, sounds good” or “nobody has seen this”.

Steve Brings Valuable Project Management Ideas to a Company That’s Mostly Disorganized.

So, Steve decided that his team’s role at Wordpress would be to unify disjoint projects with big features that had concrete deadlines, and that his role would be to do some Traditional PM & Design Stuff - some usability analysis, some wireframing, some planning, some agenda management, running real-life meetings.

And it worked out pretty hard for Steve, at first - one of his big projects, Highlander, was harder to deliver than expected. Without visibility into what his engineers were struggling with, Steve sunk further and further into madness trying to figure out what was going wrong. They ended up delivering, mostly, on time, although they were never quite sure if the thing they delivered was much good.

Jetpack, on the other hand, ended up launching juuuust on time and being a big part of Wordpress that’s still used today.

I guess the lesson is that, uh, sometimes the radical self-organized engineer commune can benefit from some traditional production practices.

Bonus Conclusion: The Big Four Tools

While the tools vary from team to team, it’s safe to say that the four tools that are absolutely non-negotiably required for a team of distributed workers are:

• Public synchronous, channeled messaging; Slack, IRC, or Basecamp Campfires

• Public asynchronous, message-board messaging; Discourse, Basecamp, P2, or even (in the way of the Ancient Ones) e-mail mailing lists.

• Some way to make high-bandwidth personal-feeling team voice calls; Skype, Zoom, or VRChat

• Public synchronous “whatever is being worked on” - so for developers, this is Git, obviously. For non-programming teams this would be Dropbox or Google Docs or - well, whatever they’re working on.

The original site didn't record this post's date; this one is approximate.