My review: The Year Without Pants
I just finished reading Scott Berkun’s The Year Without Pants. This is my review.
I want to start by saying that I greatly admire Berkun’s work in general, and have read almost all his books (I think everything but Confessions of a Public Speaker). That said, I don’t think YWP is his best to date.
YWP is an excellent account of, well, Berkun’s time at Automattic, and its culture and techniques viewed through the eyes of a “traditional” project manager. There is a disconnect in the way the book was pitched and what it actually contains. It was pitched partly as a book about remote work being the future of work, and partly as a book about how to make work more fun. It is tangentially about both those things, but the primary thrust of the book is the personal narrative of the author working and shipping at Automattic.
What was missing was any discussion of how to take Automattic’s specific culture and tools and ways of working, and extrapolate them to other settings, such as a new company, or an existing traditional one. (He later wrote about this on his blog.)
Also, for a book that wants to sell the idea of a distributed company, a significant fraction of it ends up detailing the meet-ups where teammates physically met and worked together for a few days. All team-members would come to a given city for a week, camp out in a large hotel room or apartment, and basically code, eat and drink (and maybe sleep a little) the whole time. That might be exciting and fun, but it sounds like a horrible way to work (even for one week) for someone older or with a family.
So it was a great account of how Automattic has had success with the distributed team model, but left me wanting much more. Berkun particularly shines when talking about team dynamics, leadership and project management, and I did learn quite a few new ideas and techniques from that.
Some interesting questions that I think a book on distributed teams and remote working should address:
- how can an existing company either accommodate or make the transition to being distributed? This is the big one. Because existing companies dwarf new ones. If one wants to change the way work works, one has to tackle this thorny problem.
- how can distributed work scale? By now it is not controversial to claim that distributed teams and remote work is effective for small to medium companies. But how can we scale it to larger teams and companies, going from hundreds to thousands of employees?
- learn from the Linux kernel. To me, the most successful large distributed team ever is the one that builds the Linux kernel. The artifact is complex and is now the substrate for the modern internet, and the team building it has thousands of contributors. And it has been delivering new releases and features and bugfixes steadily for more than a decade. And it has been doing this with almost no overarching oversight, other than Linus and the subsystem lieutenants weighing in on technical matters. The amount of physical proximity with other kernel hackers is small compared even to the case of Automattic–most kernel hackers will meet their fellow hackers once a year at a Linux conference. To those living on LKML and slinging patches around, this is a completely natural way to work and has become second nature. To anyone outside, it seems like an impossible feat, especially when it seems to be so hard to ship any software even with physically co-located teams and tons of oversight. Anyone who wants to understand distributed teams has to take a long, hard look at the Linux kernel community and try and learn from what they are doing.
But all the same, I do look forward to Berkun’s future work.