The Year Without Pants: WordPress.com and the Future of Work

by Scott Berkun

From Mullenweg's brilliant, or possibly mad, perspective, what made me interesting for the job was my experience leading teams, combined with my complete inexperience working anywhere like WordPress.com. Whereas the culture of WordPress.com, a company of sixty people at the time, was highly autonomous and rooted in open source culture, I'd spent my career at Microsoft and consulting with other large Fortune 500 organizations. The very idea of teams was a dramatic change for the company but not for me. There was genius here: match people together who must depend on each other to survive, only for different reasons. Mullenweg believed I could exemplify how teams should function, and the company could teach me a different way to think and work.

We all suffer from bias in what we read, believing we see a wide range of ideas when in truth we filter on our politics and beliefs. But as I did my happiness tasks, I saw everything and felt good there was a way for so many people with different ideas to share.

Regular jobs mean you answer to others. Regular jobs mean you do regular, and often repetitive, things. Regular jobs mean you are not the center of attention and have to follow rules made by other people. Anyone who's an expert, guru, executive, or coach has likely lost any real sense of what real work is. We assume that because we can give advice on something, we are superior to those who take the advice, but that's not true.

Before my story continues, I need to tell you about how WordPress started. This isn't simply because it's a great story, although it is, but to introduce its culture as a character in this book. While I won't bore you with grand theories of anthropology (I'll leave that to the professors), I'm certain that to learn from a place, you have to study how its culture functions. A great fallacy born from the failure to study culture is the assumption that you can take a practice from one culture and simply jam it into another and expect similar results. Much of what bad managers do is assume their job is simply to find new things to jam and new places to jam them into, without ever believing they need to understand how the system—the system of people known as culture—works. Much like the frustrated moron who slaps the side of a TV when it stops working, taking action without understanding the system rarely helps.

But beyond their talent, IDEO employees shared values and attitudes that were not explicitly captured in the deep dive method despite how essential those things were for the method to work. In anthropology terms, this superficial mimicry is called a cargo cult, a reference to the misguided worship of abandoned airplane landing strips among tribes hoping for the goods that airplanes had delivered to return.

No technique, no matter how good, can turn stupid coworkers into smart ones. And no method can magically make employees trust each other or their boss if they have good reason not to.

The best approach, perhaps the only approach, is an honest examination of culture. But culture is harder to understand than a meeting technique or a creativity method. And culture is scary because unlike techniques, which are all about logic, culture is based on emotion. Few people have the skills to evaluate, much less change, a culture, even if they have the courage to try. It's far safer to simply wait for the next trend to come along and rally behind it, hoping the excitement for the new method distracts everyone from noticing how little impact the previous method had.

But for Mullenweg, open source was a central principle. He also cared how that principle attracted people with similar values.

Transparency. Since all discussions, decisions, and internal debates in the WordPress community are public, little is hidden. The spirit is that if you weren't willing to say something in front of your community, how much conviction could you have in it anyway?

Meritocracy. Those who put in more time and made better contributions received respect. Authority was earned, not granted. There were few job titles or designations. People who merely complained were given less respect than people who made or fixed things.

Longevity. That WordPress was born from a failed project never left Mullenweg's mind. He wanted to ensure the project lived on forever. The open source license meant that even if Matt became evil-Matt and tried and tried to destroy WordPress, someone could fork the project and continue. Unlike contributions to a closed project, contributions to WordPress would be eternal.

The culture grew out of a small seed, just as all cultures do. And no singular decision defines a culture. Instead it emerges from a back-and-forth between a leader and the contributors, reinforcing some things and pushing others away.

When each new person joined, he or she tried to fit in, reinforcing it. Those who didn't like the culture left. By the time WordPress was popular, the community had jelled around these values even if they didn't notice them or know why they were there.

That company was called Automattic, a play on the word automatic but misspelling it intentionally to include Matt's name.

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.

Realizing how critical the values he'd learned for WordPress were to the culture he wanted to continue at Automattic, he wrote a creed that would appear on official documents, including in my offer letter: I will never stop learning. I won't just work on things that are assigned to me. I know there's no such thing as a status quo. I will build our business sustainably through passionate and loyal customers. I will never pass up an opportunity to help out a colleague, and I'll remember the days before I knew everything. I am more motivated by impact than money, and I know that Open Source is one of the most powerful ideas of our generation. I will communicate as much as possible, because it's the oxygen of a distributed company. I am in a marathon, not a sprint, and no matter how far away the goal is, the only way to get there is by putting one foot in front of another every day. Given time, there is no problem that's insurmountable.

Most people doubt online meetings can work, but they somehow overlook that most in-person meetings don't work either. Being online does mean everyone might be distracted, but plenty of meetings today are filled with people with their laptops open, messaging each other about how bored they are. My theory on meetings was simple: if what is being discussed is important, people will pay attention. Even at the universe's dullest company, if I called a meeting to decide who will get a 50 percent raise, I would have their full attention. There is nothing wrong with the concept of a meeting. If the people in a meeting think it's a waste of time, then either they're the wrong people or what's being discussed is not important enough to justify a meeting. I knew if I kept our meetings on important decisions and little else, we'd do fine, whether in person or online.

Making good ordered lists is the fundamental thing any effective leader does, and it's the heart of popular planning methods like Kanban and SCRUM.

Clichés are often clichés because they're true (which is a cliché about clichés). They're easy to dismiss because they're well worn, but that's a mistake. Love and happiness are rare, despite the popularity of those words. We like to believe what we need is a huge breakthrough, a grand idea we've never heard before. This is a mistake. Knowing and doing are far apart. The reason most managers aren't good at what they do is that they overlook the basics, which likely includes earning the trust of their coworkers. Trust is expensive to build and easy to destroy, which is why it's rare. Given my liabilities, I bet on patience. It was the only way to develop the respect I needed to lead. The first meeting was a mistake because I was too eager and not patient enough. 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.

The inability to scale is one of the stupidest arguments against a possibly great idea: greatness rarely scales, and that's part of what made it great in the first place.

The slippery slope toward misery starts with all major players having their own agenda, their own thing they're championing this quarter, and they push to make it part of the official schedule. And as their peers respond in kind, a series of endless slices are made into every day, and every hour, until there is no room to breathe. And nothing is real. There is no actual work being done. Instead it's all metawork, or discussions about future work. It's a sea of abstraction. The nonmakers are in charge of the makers and insist on spending the off-site not making anything.

The general work flow at Automattic had seven steps:

1. Pick a problem. A basic problem or idea for WordPress.com is chosen.

2. Write a launch announcement and a support page. Most features are announced to the world after they go live on WordPress.com.

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.

4. Get to work. Designers design. Programmers program. Periodically someone checks the launch announcement to remind everyone of the goal.

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. Since the company started in 2005, it had launched hundreds of features and improvements this way. Many people had never worked at a major software company before, and this was ...

The fundamental mistake companies that talk about innovation make is keeping barriers to entry high. They make it hard to even try out ideas, blind to how much experimentation you need to sort the good ideas from the bad.

The entire company stood out in the hot sun, assembled on the long grass lawn of Seaside's elementary school. It was time for the company tradition of taking a photo of all the employees. In the early years, this was easy, since there were fewer than a dozen people, but now with more than fifty to arrange, these photos were spatial jigsaw puzzles.

Working online together had been fine so far, but being in the same room together gave us a new energy. This was exactly what these meet-ups were meant to achieve: for us to learn things about working together we could reuse the rest of the year when working apart.

Half the challenge of being a project manager is the things you must deal with that have nothing to do with your own team. From fighting for resources to coordinating with other groups, the prospect of all my personnel responsibilities fitting in a car together was refreshing.

There are many theories about why teams of four to six work best, but the simplest is ego. With about five people, there's always enough oxygen in the room. It means on average that every person gets to speak once every five times, which is enough for everyone to feel they are at the center of things.

“Man is after all a finite being in capacities and powers of doing actual work. But when it comes to planning, one mind can in a few hours think out enough work to keep a thousand men employed for years.”

As I watched Team Social work, happily uncontaminated by any pretense of management by me, I kept in mind the lesson I learned from Joe Belfiore, one of the best bosses I've ever had. He told me 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.

Leaders have two good choices with that uncertainty: use that tension to your advantage or diffuse the tension. I'm the kind of leader who kills uncertainty. I want to identify the doubts and nail them to the wall. They might linger there for weeks, but by making everyone's private fears public, they become far less dangerous.

I explained I knew full well that hiring me was an experiment. But I told them I liked experiments, and they should too. Experiments were awesome. The only way you learn is by doing things where you don't know the outcome. The only problem with experiments is not when the go wrong, but when you can't end them. I explained that Mullenweg and I had discussed the challenges. If any of the experiments we were doing, from teams to my leadership choices, to even the nature of my employment, didn't work out, they should let me or Mullenweg know.

Books about the future of work make the same mistake: they fail to look back at the history of work or, more precisely, the history of books about the future of work and how wrong they were. Few visions of the future come true, as we're very bad at predicting much of anything.

William Gibson famously wrote, “The future is here, it's just not evenly distributed.”

This is the advice paradox: no matter how much advice you have, you must still decide intuitively what to use and what to avoid. Even if you seek meta-advice, advice on which advice to take, the paradox still applies as you make the same choice about that advice too.

There is nothing wrong with tradition until you want progress: progress demands change, and change demands a reevaluation of what the traditions are for and how they are practiced.

A central element in Automattic culture was results first.4 Nobody cared when you arrived at work or how long you worked. It didn't matter if you were pantless in your living room or bathing in the sun, swinging in a hammock with a martini in your hand. What mattered was your output. Shouldn't the quality of work be the primary measure of worker performance? Isn't it good, then, to eliminate traditions that get in the way and add ones that help? Working distributedly facilitated this since many stupid traditions around work status, such as judging people by who arrives early or stays late, were impossible.

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.

The responsibility of people in power is to continually eliminate useless traditions and introduce valuable ones. An organization where nothing ever changes is not a workplace but a living museum.

He saw little reason to debate things for weeks or build elaborate strategies. Instead he preferred experimenting, collecting data, and repeating. He also had great intuition for holistic thinking. He realized many experiments would fail but that experimentation was essential. WordPress or Automattic as systems would always benefit in the long run from the lessons learned from those attempts, including the failures.

The company stays as flat as possible for this 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.

Granting authority is more powerful than any software, device, or method. Instead of treating employees like children, which many executive staffs do, Schneider and Mullenweg explicitly desired an environment for autonomous adults—a place for people who know best what they need to do great work.

Diversity of skill makes people self-sufficient. They didn't need much help to start projects and were unafraid to learn skills to finish them. This self-sufficiency prevented the need for paternalistic management. They did not want to be coddled. They weren't afraid to get their hands dirty in tasks that in a mature engineering company would span the turf of three or four different job titles. That lack of specialization made people better collaborators since there was less turf to fight over. The culture valued results more than process: people were happy to lend expertise they had or teach others what they knew.

Once you have two or three like-minded people, a culture forms that attracts more people with similar values and repels those that don't. 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. The hire-by-trial approach Automattic uses filters out people not suited for remote work for whatever reason. It's fair to say many talented people aren't suited to remote work, but many are. While few established companies can choose to become completely distributed, the distribution of Automattic, among its other interesting attributes, begs the question: What assumptions do you have about your organization that hurt you? And what experiments are you doing to discover them and find better ways to work?