As I’ve talked about before, the team I work on at HP is a collection of folks scattered all over the world, working from home and hacking on OpenStack together. We’re joined by hundreds of other people from dozens of companies doing the same, or similar.
This year our team at HP kicked off an internal book club, each month or two we’d read the same book that focused on some kind of knowledge that we felt would be helpful or valuable to the team. So far on our schedule:
- Daring Greatly: How the Courage to Be Vulnerable Transforms the Way We Live, Love, Parent, and Lead by Brené Brown
- The Year Without Pants: WordPress.com and the Future of Work by Scott Berkun
- Crucial Conversations: Tools for Talking When Stakes Are High by Joseph Grenny, Kerry Patterson, and Ron McMillan
This month’s book was The Year Without Pants. I had previously read Scott Berkun’s Confessions of a Public Speaker which is my favorite book on public speaking, I recommend it to everyone. This, and given that our team is in some ways very similar to how the teams Automattic (makers of WordPress) work, I was very interested in reading this other book of his.
Stepping back for a high level view of how we do work, it’s probably easiest to begin with how we differ from Automattic as a team, rather than how we’re similar. There are certainly several notable things:
- They have a contract to hire model, partially to weed out folks who can’t handle the work model. We and most companies who work on OpenStack instead either hire experienced open source people directly for an upstream OpenStack job or ease people into the position, making accommodations and changes if work from home and geographic distribution of the team isn’t working out for them (it happens).
- All of the discussions about my OpenStack work are fully public, I don’t really have “inside the company”-only discussions directly related to my day to day project work.
- I work with individuals from large, major companies all over the world for our project work on a day to day basis, not just one company and a broader community.
These differences mattered when reading the book, especially when it comes to the public-facing nature of our work. We don’t just entertain feedback and collaboration about our day to day discussions and work from people in our group or company, but from anyone who cares enough to take the time to find us on our public mailing list, IRC channel or meeting. As a member of the Infrastructure team I don’t believe we’ve suffered from this openness. Some people certainly have opinions about what our team “should” be working on, but we have pretty good filters for these things and I like to think that as a team we’re open to accepting efforts from anyone who comes to us with a good idea and people-power to help implement it.
The things we had in common were what interested me most so I could compare our experiences. In spite of working on open source software for many years, this is the first time I’ve been paid full time to do it and worked with such large companies. It’s been fascinating to see how the OpenStack community has evolved and how HP has met the challenges. Hiring the right people is certainly one of those challenges. Just like in the book, we’ve found that we need to find people who are technically talented and who also have good online communication skills and can let their personality show through in text. OpenStack is very IRC-focused, particularly the team I’m on. Additionally, it’s very important that we steer clear of people whose behavior may be toxic to the team and community, regardless of their technical skills. This is good advice in any company, but it becomes increasingly important on a self-motivated, remote team where it’s more difficult to casually notice or check in with people about how they’re doing. Someone feeling downtrodden or discouraged because of the behavior of a co-worker can be much harder to notice from afar and often difficult and awkward to talk about.
I think what struck me most about both the experience in the book and what I’ve seen in OpenStack is the need for in-person interactions. I love working from home, and in my head it’s something I believe I can just do forever because our team works well online. But if I’m completely honest about my experience over the past 3 years, I feel inspired, energized and empowered by our in-person time together as a team, even if it’s only 2-3 times a year. It also helps our team feel like a team, particularly as we’re growing in staff and scope, and our projects are becoming more segregated day to day (I’m working on Zanata, Jim is working on Zuulv3, Colleen is working on infra-cloud, etc). Reflecting upon my experience with the Ubuntu community these past couple years, I’ve seen first hand the damage done to a community and project when the in-person meetings cease (I went into this topic some following the Community Leadership Summit in July).
Now, the every-six-months developer and user summits (based on what Ubuntu used to do) have been a part of OpenStack all along. It’s been clear from the beginning that project leaders understood the value of getting people together in person twice a year to kick off the next release cycle. But as the OpenStack community has evolved, most teams have gotten in the habit of also having team-specific sprints each cycle, where team members come together face to face to work on specific projects between the summits. These sprints grew organically and without top-down direction from anyone. They satisfied a social need to retain team cohesion and the desire for high bandwidth collaboration. In the book this seemed very similar to the annual company meetings being supplemented by team sprints.
I think I’m going to call this “The year of realizing that in person interaction is vital to the health of a project and team.” Even if my introvert self doesn’t like it and still believes deep down I should just live far away in a cabin in the woods with my cats and computers.
It’s pretty obvious given my happiness with working from home and the teams I’m working on that I fully bought in to the premise of this book from the beginning, so it didn’t need to convince me of anything. And there was a lot more to this book, particularly for people who are seeking to manage a geographically distributed, remote team. I highly recommend it to anyone doing remote work, managing remote teams or looking for a different perspective than “tech workers need to be in the office to be productive.” Thanks, Scott!
Monday, Sep 14th, 2015 at 13:53
Thanks for mentioning the book and glad you found it interesting.
One thought related to your post is how people with open source experience already understand how to work remotely, or at least in a decentralized organization. This is rare for most of the working world, but I’m not surprised that you found so many parallels.
The book has a general audience readership it seems and many of them are surprised that any of what i described worked at all – and when I explain that Apache, Linux, etc. some of the most important software in the world, shares some of these same elements they still have a hard time imagining it.
It seems much of the working world has a narrow set of experiences for what “work” is and have a hard time even imagining alternatives, which is part of why I wrote the book in the first person (rather than as a manifesto like 37signal’s remote). I wanted to describe the actual realities, as that’s perhaps the bigger gap to more people trying these ideas.
Anyway – thanks for reading the book and mentioning it. Appreciated.