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

by Scott Berkun

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.

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.

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

In my story so far at WordPress.com, every employee I met was smart, funny, and helpful. They'd invested heavily in tools and systems but put the onus on employees, even new ones like me, to decide how, when, and where to do their work. These attributes of culture didn't arrive by some technique sprinkled around the company

Like most other events that change the world, it didn't seem interesting to anyone except the people willing to do the work.

But my fear was that if I stayed in the same place for a decade, I'd never leave. I wanted an interesting life, and as much as I didn't know what that meant, I was certain that working for the same company for ten years would not help me figure it out. I convinced myself my prospects would improve if I were unemployed. To be unemployed by choice meant I'd have no baggage and be free to learn a new way to be. My vague ambition was to write books, and off I went.

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.

something you use. Anyone can proclaim to believe in anything. The question is how much of their actions reflect those beliefs.

The first thing I tell teams of people who are struggling is ML: Make a list. Write down the list of problems to solve or issues to fix. Get it out of their brain and on paper. It's less stressful when its written down. Then put them in order of importance, with an order that everyone understands: what comes first, what comes next, and so on. 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.

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.

Lazy critics dismiss new ideas with critiques like, “It's nice, but not real,” or, “It can't scale,” suggesting that if you developed the idea further, it would fail. But they forget to ask the bigger question: What good is something that scales well if it sucks? Why is size the ultimate goal or even a goal at all? If you're the kind of person who loves Seaside or the place where you work, you don't need it to be any bigger than it is. 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.

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.

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.

Schneider described his philosophy in this way: 1. Hire great people. 2. Set good priorities. 3. Remove distractions. 4. Stay out of the way.

I learned how little résumés and pedigrees express about a person's passion. It takes more passion to choose, on your own, to build a website, a mobile application, or a company than to follow years of instructions to get a degree.

Many employees at Automattic were what's called T-shaped, meaning they had one very deep skill set, and a wide range of moderate proficiencies. Although I was hired as a lead, my deep skill set in this sense was interaction design. 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.

The game company Valve, makers of the games Half-Life and Portal, have a similar philosophy. They hire T-shaped programmers and designers—people who are masters at one craft but skilled at many.

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.

Asking the user experience question is the ultimate way to prioritize engineering work, as it shifts the perspective back to where it belongs: the impact that decisions will have on customers, not engineers. Both matter, but the customer matters more.

Even with design, you make bets on how the trade-offs of one direction are superior to the trade-offs of another. For many programmers, these abstractions are disturbing. The uncertainty of it is disconcerting. Much like writers and designers, they are drawn to precision work. They like the control of each pixel, bit, or letter. It satisfies perfectionistic or even obsessive compulsive tendencies in their personalities. To move to, as Adams's would say, squishy topics like choosing who to hire or fire, or what feature idea has the most merit, is distasteful for many programmers. Even programmers who are good at this often dislike it. 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.

To understand who people really are, start a fire. When everything is going fine, you see only the safest parts of people's character. It's only when something is burning that you find out who people really are.

Studying how a culture manages its problems is a powerful way to understand the culture.

If my frustrations weren't matched by the frustrations of the people doing the work, perhaps it was my problem and not theirs.

Today many managers love the saying, “You are what you measure.” They're convinced measurement is the secret to success and seek metrics to track—sometimes called KPIs, or key performance indicators, much like IBM executives did back then. Some companies, including Google, insist on having metrics to evaluate any decision, goal, or feature. Despite the popularity of this belief, it's easy to get lost in the very metrics that are supposed to help you find your way.

Eventually everyone realizes that the metric, which was good for a time, is now being gamed. Employees go so far out of their way to score well on the metric that it has negative effects on the real quality of what the company makes, something people recognize intuitively.

All metrics create temptations. Even with great intentions and smart minds, data runs you faster and faster into a stupid self-destructive circle. Data can't decide things for you. It can help you see things more clearly if captured carefully, but that's not the same as deciding. Just as there is an advice paradox, there is a data paradox: no matter how much data you have, you still depend on your intuition for deciding how to interpret and then apply the data.

When a culture shifts too far into faith in data, people with great intuitions leave.

Making great things requires both intuition and logic, not a dominance of one over the other.

He wanted a data-influenced culture, not a data-driven one. He didn't make data the center of the conversation but wanted to ensure they were part of it.

But the problem isn't functionality. Functionality means a piece of software is capable of doing something. Merely having a function doesn't say anything about how many people can figure it out or are even interested in trying. Your car might be equipped with dual warp drives, but if you can't find it or figure out how to use it, what good is the ability to travel at the speed of light? Not good at all. It's design, not functionality, that determines if people will succeed or fail in fulfilling the promises products have made to them.

Automattic hired people for their love of WordPress, begging the question whether this woman, or any of her coworkers, had any interest in trains at all. Of course, Greece could barely afford to pay anyone, and perhaps all of Greece's friendly trainophiles had migrated elsewhere. A philosophy can't do much if you can't pay people what they're worth. But then again, WordPress was fueled by volunteers working on their own time. Could something like WordPress's culture work for government? Or for a public service? I

It was continual background energy for the whole meet-up, the visceral sense we were all together in a good place, with good food and quality of work life in every way provided for us. It never entirely made sense to me why we were there, but the effect of it was clear: we were all energized, inspired, and ready to earn our trip to an amazing place.

I wanted us to make big bets and show the company we could have visions of cathedrals and build them with bazaar methods.

The bottleneck is never code or creativity; it's lack of clarity.

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.

Often acquisitions create a paradox: they're hard to fit into a company for the same reason they're attractive to acquire.

In the old days, Microsoft used to deliberately understaff teams to help keep pretense and BS low. Too much understaffing causes misery, but if you cut it right and delegate ownership liberally, morale and productivity stay high. Passionate people love to feel like empowered underdogs.

But the downside to working in small increments, the way of the web and Automattic, is that stupid things can happen because of the absence of forethought. By forethought, I mean thinking through, for even a handful of hours, how all the parts must fit together, or considering which parts are hardest and doing those first to ensure the project is viable at all.

After years of leading projects, the best thing I've learned is that I have to periodically shift between thinking small (bazaar) and thinking long term (cathedral). Asking my team, “If we do these three features in a row, how do they build together into something better than the sum of the parts?” I don't want them fixated on thinking that far ahead, but I do want them to raise their heads and look to the horizon periodically, because that glance improves how they'll evaluate whatever they're building today.

To start big projects, you must have the capacity for delusion. All the rational people, despite their brilliance, are too reasonable to start crazy things.

Laughter leads to running jokes, and running jokes lead to a shared history, and a shared history is culture.

While cultures form organically, someone has to be the instigator and get things in motion, reinforcing the good and reducing the bad. In many ways, this was me, always looking for little ways to improve the odds. But it was always clear to me that the master facilitator of culture was Mullenweg.

separating the people making the product from the people supporting the makers,

Things that are less fun to do are usually harder to do, which means the pile isn't ordinary work but a pile of unloved, unwanted, complex work: 1. We do things we like first. 2. We do things we don't like last. 3. The things we don't like tend to be harder. 4. Late changes have cascading effects. This means that at the end of any project, you're left with a pile of things no one wants to do and are the hardest to do (or, worse, no one is quite sure how to do them). It should never be a surprise that progress seems to slow as the finish line approaches, even if everyone is working just as hard as they were before.

I'm certain of the following: Self-motivated people thrive when granted independence. Managers who want better performance must provide what their staff needs.

the trust that remote work grants employees. Some employees abuse free office supplies from the copy room. Others lie about taking sick days. Every benefit granted can be used to perform better work, or it can be abused. The benefit itself rarely has much to do with it.

If his or her performance stays the same or improves, you win. If it goes poorly, you still win, as you've demonstrated your willingness to experiment, encouraging everyone who works for you to continue looking for ways to improve their performance.

Outsiders assume remote work means working from home, but that's an important inaccuracy. The true directive is that employees can locate themselves wherever they want. You could work from your back deck. Or you could rent an office in a coworking space or travel around South America in a used Jeep with good wi-fi. In all cases it is up to you as an employee to figure out how to be productive.

If Pascal, who once wrote, “If I had more time I'd write a shorter letter,” had to contend with this, he'd have said, “If I read incoming e-mails carefully, the e-mails I send will generate fewer replies.”

if you have a team of people who hate each other, they will make each other miserable no matter how many billions of dollars of communication technology they use. Alternatively if you have people who trust each other and have similar goals, they'll be effective with smoke signals and carrier pigeons.