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

by Scott Berkun

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.

My theory on meetings was simple: if what is being discussed is important, people will pay attention.

The radical combination of remote work, IRC meetings, and transcripts reaffirmed something I'd always known: starting a new job makes you a paratrooper. You jump out of the safe, comfortable airplane of your past experience to land in a place you have seen only rough maps of—maps made by the people who most want you to jump. These maps are happier and neater than the landscapes they represent, yet you want the map to be true, so you trust it. As a result, most

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.

The general work flow at Automattic had seven steps: 1. Pick a problem. A basic problem or idea for WordPress.com 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 WordPress.com. 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 ...

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 precis...

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 ar...

More than anything else, I recognized that the big cultural bet wasn't on process but on people. Instead of betting on the enforcement of an elaborate fifty-step process or the magical talents of management, Automattic put the onus on individuals. It was like a small start-up company where every employee was empowered, out of necessity, to make many decisions free of approvals from a long list of grumpy corporate gatekeepers. For me, and all the places I'd been, Automattic

The best feature names simply describe what the thing does.