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

by Scott Berkun

What started as a simple, streamlined tool with .71 now had hundreds of features, all competing for attention from users, the classic consequence of continuous deployment.

I'd seen this before. The solution is vision. Someone has to define what we're trying to get to and clarify which ideas are both more and less important in completing that vision.

For all of the strengths of WordPress's bazaar culture, its user experience lacked the grace and clarity a cathedral architect would naturally provide.

By framing the problem around my simple scenario, we had a way to evaluate the merit of specific feature ideas: Will this feature get more people further along in the scenario? Will this get them more rewards when they publish?

Often I made a teamwide bet about one of the data points we were going to collect to help keep us interested.

Architects are notorious for designing and disappearing, never returning to see how their choices worked or failed after the building opens.

Ambiguity makes everyone tolerant of incompetence.

Although we gave her nothing, she gave us the gift of a story to share—something a new team on their first adventure together needed to find.

One school of meetings is to simply list an agenda of questions so the meeting has a spine to hold it together, but the meeting that morning didn't have one of those either.

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.

Fear of this uncertainty motivates people to spin their wheels for days considering all the possible outcomes, calculating them in a spreadsheet using utility cost analysis or some other fancy method that even the guy who invented it doesn't use. But all that analysis just keeps you on the sidelines. Often you're better off flipping a coin and moving in any clear direction. Once you start moving, you get new data regardless of where you're trying to go. And the new data makes the next decision and the next better than staying on the sidelines desperately trying to predict the future without that time machine.

The absence of dedicated quality assurance people made every employee accountable for quality, which is rare if there are many QA people around.

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.

In project terms, if you make only small maps, of, say, the next two weeks, you never run the risk of your map being very wrong, and you learn more from the present since it has your full attention.

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.

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,

Not a single programmer had lifted a finger to even start thinking about how to build it. This kind of vaporware speculation drove me crazy. Most of Automattic was too young to realize vaporware can go on for years with people endlessly believing in something no one is working on, preventing plenty of good plans from starting because of an unchallenged mythology.

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.

There's a degree of control that the filter of technology gives you—a control that introverts often prefer. The centricity of those filters in most of the important relationships in his life enables freedoms most people would never imagine.

The benefit itself rarely has much to do with it. If someone who works for you wants to work remotely or use a new e-mail tool or brainstorming method, little is lost in letting him or her try it out. 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.

In a normal workplace, you sense how well you fit in by how often people seek you out, and you can compare that to the conversations you observe others having without you.

“If I read incoming e-mails carefully, the e-mails I send will generate fewer replies.”

E-mail has rarely discussed disadvantages: E-mail empowers the sender. They can put in your inbox whatever they like and as many times as they like (many receivers use filters and rules as countermeasures). E-mail is a closed channel. There's no way to see an e-mail if you are not on the “to” list, forcing work groups to err on the side of including everyone. Only a fraction of e-mail has direct relevance to any particular person. E-mail decays over time. If someone writes a great e-mail, an employee has to do something to preserve it. Otherwise it sits in an inbox, hidden from new employees. Over time, that organizational knowledge fades away.

P2s by design invert these assumptions: The reader, not the sender, chooses what to read. The reader chooses how often and in what form he or she wants to read. Since P2s are a form of blog, they're easy to skim, easy to reference with a URL, available to all forever, searchable, and easily pushed into different reading tools.

All designers should be visualizers for P2 threads, saying “do you mean something like this? (show sketch)”—it improves the quality of any conversation to see, rather than just read.

If your thread gets hijacked, start it again—don't assume it means what you wanted to get isn't worth getting.

It's easy for people to dismiss a thread if the first thing they see in the comments is a long debate between two people about a detail you don't care much about.

I've always demanded that my bosses explain things I don't understand. I want to be taught, not told. I don't mind being proven wrong or trumped provided I learn something, but I did not follow decrees well.

The countermeasure for Matt bombing is what's called “managing up.” As the lead for Team Social, my job for the team was to have as few public ruffles with Matt as possible.

The only honest test of the value of any management activity is to run projects without some of them and observe how well people perform with a lighter touch. It's a test few leaders have the courage to take.

Research labs and innovation groups run afoul at the other end of the spectrum: too little friction. Like a puck on an air hockey table floating around aimlessly, ideas need something to work against—a mallet or a wall—to use as leverage. There must be someone challenging ideas in ways their creators don't necessarily like in order for those creators to see the blind spots in their thinking. Breakthroughs await in those blind spots.

Continuous deployment made these downsides and benefits irrelevant. WordPress.com continually added new features, each launch creating another wave of attention generated largely by customers, the best possible advocates.

Automattic had a unique relationship to friction: No formal schedules Little competitive pressure No influence from marketers Minimal hierarchy/flat structure Most people work at places with high friction from these sources and struggle to imagine working without them. There are entire jobs, like project management, based on applying friction and driving schedules.

I had to find ways to introduce friction into a culture that hadn't felt it before.

This is a classic management situation. What can you do? There are only a handful of choices: 1. Look at it myself. If I were more of a programmer, I could have jumped in. The bet would be I could see something that they didn't. That's a big bet, though, and possibly seen as a lack of trust. 2. Ask another programmer to look. This is the same as the first option through delegation. 3. Change something. Making the project simpler might help. I could sharpen the goal, ask better questions, or simplify the scenario. I asked Adams if he saw a way, but he didn't. The smallest useful goal was the one we had. 4. Kill the project. Give up and move on. 5. Keep going. Assume everything is fine, and we just need more time.

I poked at the ultimate questions for managers: Do I know everything I need to know? Do they trust me enough to tell me things they think I don't want to hear? There was only one way to find out. Every few days I gently inquired about where things were at, what the next steps were, if they were blocked and how I could help. Although these chats revealed little, they did clarify what was on my mind to them. It also opened a private Skype backchannel with everyone, something I hadn't done before.

In a company dominated by incrementalism, this project challenged my team in unfamiliar ways. We had made a big bet that was hard to divide into small pieces.

simply because you have a fancy word for something doesn't make you any smarter. It probably makes you stupider because you confuse your precise vocabulary with precise skills.

No method can capture how and when to abandon the method or tweak it; only a team and its leader can do that. And for a team to do that successfully, they need to trust each other.

Methodologies are often another bad friction that managers impose, putting more faith in a bunch of rules than in the people they've hired.

I pulled another trick from my hat: increase motivation. We were excited about Highlander and Jetpack, and defining those projects might inspire us to push through the IntenseDebate work.

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.

Often the first step, the first undeniable sign of progress, is the hardest to get. With the first win under your belt, everyone has a clear reminder that wins are possible. Programmers are competitive by nature, and someone has to set the pace on every team, constantly demonstrating what can be done.

These efforts were corny, but they had positive effects that were hard to measure. Reminders to have a sense of humor gave us room for trying ideas to improve WordPress.com that'd we never pursue in a company afraid to behave in public like a person instead of a machine.

In all, five warning bells went off in my mind: 1. Success demanded a different culture. If we missed the date, Automattic would look bad and Jetpack's launch would fail. I imagined Mullenweg up on stage doing magic tricks in front of a huge crowd, killing time instead of announcing Jetpack to the world. 2. Programmers would have to do estimates. I hadn't seen a single work estimate at Automattic. You can't be on time unless you estimate work. The first time that a team that has never done estimates before does them, accuracy is poor, as is how much they care about the consequences. 3. We'd need more people on the team. The rough work map we made for Jetpack implied that three programmers was not enough.1 4. Jetpack needed a simple user interface. Jetpack was a bridge for various blogging features. The technology required to do this was complex, but users' experiences had to be as simple as flipping a switch and forgetting it was there. 5. We'd need release management and compatibility testing. Web programmers work with browser compatibility all the time, but Jetpack worked on different servers. We'd need to test Jetpack on many different hosts. This meant another unfamiliar bag of tricks: bug tracking, test plans, and release candidates (RC), things rarely used at Automattic.

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.

Humans are much more complex than software, and since the interface has to interact with people, it's the most difficult to do well.

The easiest way to work to a schedule is a spreadsheet with three things: Each work item, listed in priority The developer assigned The developer's work estimate