How to transition a team to remote work
Vivek Haldar wrote this thoughtful review of The Year Without Pants. His primary critique is there wasn’t enough focus on tactics and methods. In his review he asked a few good questions which I’m answering here.
Regarding his primary critique, I offered this:
Many people wanted me to write a pure “how to run a distributed company” book, centered on advice and techniques. I was certain this was a mistake, or at least a squandering of the opportunity I had. WordPress and Automattic are so interesting, and such an important example, in so many ways (a leading web platform, open source, no email, distributed work, etc.) that I knew as a writer I had to focus on their story, and the story of my experience as an outsider trying to become a leader in their culture.
I was given no restrictions about what I could write about or how to write it. A general manual for leadership, or distributed work, felt underwhelming given that this will likely be the only book ever written about WordPress.com. Honest insider accounts are rare, certainly written by workers involved in a project, rather than a journalist who had to trade honesty for access. Naming the book “The Year Without Pants” was meant to suggest it was about a year, rather than a manifesto for a particular kind of work, but perhaps that wasn’t clear enough.
The book was published so what I think it of it matters little now. Each reader, like Vivek, will decided for themselves if they got what they wanted, or expected, from the book or not.
Q. how can an existing company either accommodate or make the transition to being distributed?
For general advice see the FAQ for Year Without Pants, How To Change A Company and How To Convince Your Boss to Try New Things.
Chapter 15 of the book, titled The Future of Work Part 2, offers advice on the general way it happens: one person at a time. A worker has to say to their boss “hey, I can be just as, or more, productive if you let me work remotely. Let’s try it and see.” And then the boss has to say, “Yes, lets try that and see what happens”. If that experiment goes well, it will be repeated by others. This is the primary way change happens anywhere: two smart people agreeing to try something and then, if it works, agreeing to do it more. There’s no magic: just two open minded people.
It will usually be the youngest managers, on the youngest teams, at the youngest companies, that are willing to try new things first. They have fewer preconceptions and fewer things to fear. It’s no surprise most of the 100% distributed companies I’ve found are young software companies. But do consider that most remote workers on the planet are at large corporations (Aetna, American Express, IBM, etc.) where the financial payoffs of remote work have outweighed their fears. Someone at each of those companies had to be first to pitch the argument for experimenting with remote workers.
Of course a team leader, or an executive, can accelerate change if they have control over policies. But typically people with control over policies are conservative: they’ll wait for the existence of a highly productive and vocal minority with enough influence before even considering changing policy. If YOU, reading this, want to work remotely, it starts with you pitching your boss to give it a try. If they see it as a win for you to win by working remotely, they’ll naturally promote the idea.
If you want to see a post purely about how to do that pitch, leave a comment, or submit the question here. (Also: My general advice on pitching ideas).
Q. how can distributed work scale?
Automattic is currently about 200 250 300 people. I could easily see the company reach 1000 people, with 5 product units each with about 200 people in them. Everything within those units would be much the same as it is now. Continuous deployment is part of how Automattic works and it helps with scale: since new ideas launch regularly you rarely have large dependencies between teams. The challenge with scale is for leaders of each unit, assuming they existed (and the units were not self-organizing collectives as some people theorize as ideal), to avoid the traps of middle-management, and maintain the same employee driven autonomy the company has now, while keeping the company lined up well on strategy.
The history of work is useful here too. Read about the U.S. civil war or WWII or the Peloponnesian War. Armed forces in the grand wars of the past were intensely distributed, with thousands of soldiers working on what was supposed to be a singular strategy, separated by enormous distances. Messages were sent by runners and horses: ridiculously slow compared to Skype or SMS. My point is that there are plenty of examples of large scale distributed work if you look for them. My success and failures described in The Year Without Pants rarely hinged on my team being distributed or not.
Of course most companies fail. Most projects fail. We give a disproportionate amount of attention to absurdly successful things. If WordPress or Automattic fails in some significant way my first thought would not be to question the fact that they’re distributed, and the book does critique other elements of the company and the culture appropriately.
Learn from the Linux kernel. To me, the most successful large distributed team ever is the one that builds the Linux kernel.
Linux, and open source project management in general, is well documented. Karl Fogel’s Producing Open Source Software is excellent and examines many of the common challenges, with good advice for solving them. Although he doesn’t explicitly take on distributed work, most open source projects are highly distributed. WordPress and Linux share many parallels, with one strong founder as leader, a small number of lieutenants, and hundreds of individual contributors. The gate keeper role played by the founder and lieutenants is the key part of the story: it’s not as if any random contributor can make critical decisions on their own. It’s a hierarchy in the classic sense of the word, just with soft and open community based rules for how to become part of it.
I read Torvold’s book Just for Fun, and found it fascinatingly humble. He didn’t set out with the plan to create a phenomenon, an irony lost on all of the people who seek to merely copy what he has done with the hopes of replicating the outcome. I attribute much of his, and Mullenweg’s, success to CULTURE, which is why all of chapter 3 in The Year Without Pants is an examination of how the WordPress culture was created. Few technical founders pay sufficient respect to culture and it shows in how their organizations fall apart.
Side story: as I kid I remember the joy of stumbling on a movie on TV where I had no idea what it was and loving it in part because I had no idea what was going to happen. That almost never happens anymore. We are such proficient consumers now that we know far too much about films before we see them, and most reviews and previews are effectively Cliff’s notes versions of the stories. I need more film serendipity so I can have more film pleasure. Gratefully I didn’t know much about Gravity other than the trailer.
