The Year Without Pants by Scott Berkun

I have been working more and more in a remote setting. Working from home while traveling. Partially remote teams. Fully remote teams. Tropical storms and snowstorms in a country that shuts down every time there’s a storm.

For all of the above reasons, I started researching the subject of working remotely more and more. One of the most highly publicised books in this sphere is, of course, Remote: Office Not Required, which I had read a while ago. Despite having lots of advice, extracted from the experience of 37signals/Basecamp through the year I needed something more. When I came across with The Year Without Pants, which promised an in-depth view of the day to day of working at Automattic, the fully distributed across the globe company founded by Matt Mullenweg, I almost jumped at it.

Scott Berkun was hired by Matt to lead a team of remote developers, scattered across 16 time zones. Scott proceeds to show us the anarchic operations of a small company (it was just over 100 employees in 2011 when most of the action of the book takes place). The book certainly delivers, bringing us closer to viewing how a highly successful company by any measure treats their projects, employees, and problems. I loved the details at the beginning of the book so I was a bit disappointed when Scott fast forwarded most of his last few months. I believe he probably did the right choice, otherwise the book wouldn’t be as readable as it is in its current format, but it would have been great to continue to explore the day to day work (if you’re into that sort of company porn, and yes I’m coining that term here!). In the end, I’m left wondering if the company remains the same (both in spirit and operationally) or if it has evolved since now it boasts more than 600 employees. Maybe one day Scott will make a temporary return to Automattic to grace us with a sequel.

I’ll leave you with some of my favorite passages.

One major mistake Schneider had seen was how companies confused supporting roles, like legal, human resources, and information technology, with product creation roles like design and development. Product creators are the true talent of any corporation, especially one claiming to bet on innovation. The other roles don’t create products and should be there to serve those who do. A classic betrayal of this idea is when the IT department dictates to creatives what equipment they can use. If one group has to be inefficient, it should be the support group, not the creatives. If the supporting roles, including management, dominate, the quality of products can only suffer.

One trick is to be the scribe. If you take on the task of taking notes, people have a chance to see how you think. If they find your recording of what happened clear and honest, you get a trust point. If the way you summarize complex things is concise but still accurate, you get another. Soon there’s enough trust to lead decisions and take bigger bets. Being the scribe is often seen as a chore, but it has big upsides, especially in a supremely informal culture like Automattic’s.

There are no big schedules, few big plans, and no enforced mechanisms for coordination. It sounds like chaos, and it is. But if everyone understood chaos and perhaps liked the uncertainty, they would find freedom and opportunity. And if everyone wanted to do great work, they’d seek out collaborators and greater order when needed. The move to teams was supposed to encourage this to happen more often.

The general work flow at Automattic had seven steps: 1. Pick a problem. A basic problem or idea for is chosen. It could be something like, “It’s too hard to print blog posts,” or, “Let users share from WordPress to Facebook.” There are always hundreds of ideas and dozens of opinions about which ideas are important. There’s no formal system for deciding, but many came from Mullenweg or as suggestions from the Happiness folks. After an idea is chosen, discussion begins on how it should work. 2. Write a launch announcement and a support page. Most features are announced to the world after they go live on But long before launch, a draft launch announcement is written. This sounds strange. How can you write an announcement for something that doesn’t exist? The point is that if you can’t imagine a compellingly simple explanation for customers, then you don’t really understand why the feature is worth building. Writing the announcement first is a forcing function. You’re forced to question if your idea is more exciting for you as the maker than it will be for your customer. If it is, rethink the idea or pick a different one. 3. Consider what data will tell you it works. Since it’s a live service, learn from what users are doing. The plan for a new feature must consider how its positive or negative impact on customers can be measured. For example, if the goal is to improve the number of comments bloggers get from readers, we’d track how many comments visitors write each day before and after the change. 4. Get to work. Designers design. Programmers program. Periodically someone checks the launch announcement to remind everyone of the goal. As more is learned about what’s possible, the announcement becomes more precise. Sometimes the feature pivots into something different and better. 5. Launch. When the goal of the work has been met, the feature launches. It’s often smaller in scope than the initial idea, but that’s seen as a good thing. The code goes live, and there is much rejoicing. 6. Learn. Data is captured instantly and discussed, often hourly, by the folks who did the work. Bugs are found and fixed. For larger features, several rounds of revisions are made to the design. 7. Repeat.

the central way he’d evaluate me was the quality of what made it out the door. It wasn’t about the ideas I had or how I managed schedules. It wasn’t how I ran meetings or how well liked I was. Those were all secondary. What mattered was what we shipped. And he told me the only reason anything good ships is because of the programmers. They are everything. They are not factory employees; they are craftspeople, craftspeople who are the fundamental creative engine of making software. Although my job title was program manager, I wasn’t granted power to run around making demands all day. There would be days I’d need to make demands, but I’d have to earn them. I had to earn the respect and trust from the programmers and designers I worked with. With trust, everything was possible. With trust, I could discover how to get the best possible work from them.

Any manager who eliminates superfluous traditions takes a step toward progress. If removing a restriction improves performance or has no impact on performance but improves morale, everyone wins. Continuing tradition simply because it’s a tradition works against reason.

Schneider described his philosophy in this way: 1. Hire great people. 2. Set good priorities. 3. Remove distractions. 4. Stay out of the way. These freedoms at Automattic reminded me that the hardest part of work is what goes on between your ears and between you and your coworkers.

Remote work is merely physical independence, and the biggest challenge people who work remotely face is managing their own psychology. Since they have more independence, they need to be masters of their own habits to be productive, whether it’s avoiding distractions, staying disciplined on projects, or even replacing the social life that comes from conventional work with other friendships.

A trick of leading creative teams is finding creative ways to nag people. You get more mileage if you make people laugh, even if it’s at themselves, at the same time you’re reminding them of something they’ve forgotten.

The realization that everyone is different when you talk to them alone is a secret to success in life. In private you have their full attention. If you talk to two children in front of their mom and then each alone, you hear different things. The mystery for why some people you know succeed or fail in life is how courageous they are in pulling people aside and how effective they are in those private conversations we never see.

Being a good lead is all about switching hats: knowing which level of abstraction to work at to solve a problem. It’s rarely a question of intelligence; instead, it’s picking the right perspective to use on a particular challenge.

The more experienced that managers are, the longer the list of bad things they’ve seen that they’re trying to avoid. This is what I call defensive management, since it’s designed to prevent a long list of bad things from happening. Defensive management is blind to recognizing how obsessing about preventing bad things also prevents good things from happening or sometimes even prevents anything from happening at all.

But reverting code was rare. Instead programmers were encouraged to make another change that fixed the problem. As a rule, everyone who launched something was expected to stay online for a few hours to ensure things went smoothly.

It sometimes takes ugly effort to make beautiful things. People who love great things but are ignorant of how they’re made are mystified by how dirty they have to get their own hands to make anything at all: they think the mess means they’re doing something wrong, when mostly it just means they’re finally doing real work.

You should never be religious about methods of any kind. The only sane way to work is to let the project define the plan. Only a fool chooses tools before studying the job to be done.

Humor has always been a primary part of how I lead. If I can get someone to laugh, they’re at ease. If they see me laugh at things, they’re at ease. It creates emotional space, a kind of trust, to use in a relationship. Sharing laughter also creates a bank account of positive energy you can withdraw from, or borrow against, when dealing with tough issues at work. It’s a relationship cushion.

most Automatticians have tangible jobs: writing code, designing screens, answering tickets. They’re not in the stressful limbo of abstraction that middle managers and consultants live in. Instead there’s little posturing or showing off. People who know how to build things don’t worry about turf. They know they can always make more. It’s often people whose jobs are abstractions that see a company as a zero-sum game where they have to fight and defend what’s theirs to stay alive or get promoted.

I find P2 great for documenting things, ok for soliciting feedback on something, but pretty terrible for having a “discussion”. If I want to discuss something with someone (or a group of people) I just ping them on IRC. Skype, phone, etc. also work for discussions. No need to have a discussion with myself on a P2.

In retrospect, I don’t see the wider distribution of our team as the cause for our poor productivity. Instead, it was the division of labor and the low morale for IntenseDebate. When our team became more dispersed, I had the choice of switching to a simpler project and have them all work together, a good choice when learning something new.

On a team that has good morale, seeing teammates launch things inspires, and inspiration brings with it new effort and ideas.

Mullenweg clarified the importance of the project, and as a good leader should, he offered whatever resources I needed. It’s a great bullshit test of any boss who says, “X is important.” If she doesn’t match that statement with resources, she’s incompetent, insincere, or both. If it’s important, prove it.

The natural mistake engineers make is to build from the bottom up. They leave the user interface last, assuming it is the least complex technology. This is wrong. Humans are much more complex than software, and since the interface has to interact with people, it’s the most difficult to do well. By building from the bottom up, technologists paint themselves into a corner, resulting in ugly, hard-to-use things. By the time they finally got to the user interface work, so many constraints exist that even the best designers in the world couldn’t salvage the project. The answer is simple: design the user interface first. This is a mandate at any organization that makes things people love to use.

One side effect of having teams is there will always be things that fall through the cracks. Teams create territories. This is a force for good since it helps people focus and feel pride. But it creates problems for projects that fall between teams. If you try to cover everything, the teams are unfocused, and if you cover too little, there’s no room for growth. But even if you carefully design teams, the turf needs to be conceptual, not territorial. Organizations become bureaucratic as soon as people define their job around a specific rule, or feature, rather than a goal. For example, if you tell me my job is to cook the french fries, I will resist anything that threatens the existence of french fries, since when they go away, so does my job. But if you tell me my job is to make side dishes for customers, I’ll be open to changing from fries to onion rings or other side dishes, even ones we’ve yet to invent, since my identity isn’t tied to a particular side dish but instead to the role side dishes play.

In any organization, large projects require leverage, but few employees have any. People who have grand ideas but little influence wonder why no one supports them. They think the lack of support is a judgment on their ideas rather than the politics of authority. Ideas are evaluated differently depending on the mouth they come out of.