Planned Anarchy

No street signs. No crosswalks. No accidents. A fantastic Wired article about how removing the artificial safety nets we set up for ourself actually makes us safer. The illusion of safety is a very dangerous thing. This is totally applicable to software design too. If you put up a big notice saying “Don’t do this” people won’t read it, you have to design the interaction to encourage people in the right direction.

Top Emailers 2008, etc

As an update to last year’s post:

  1. Toni Schneider — 1,052
  2. Maya Desai — 826
  3. Mom — 659
  4. Raanan Bar-Cohen — 452
  5. Donncha O Caoimh — 424
  6. Barry Abrahamson — 386
  7. Mark Riley — 222
  8. Jane Wells — 218
  9. Ryan Boren — 200
  10. Andrew Ozz — 197
  11. Matt Thomas — 193
  12. Liz Danzico — 148
  13. Mike Hirshland — 144
  14. Heather Rasley — 139
  15. Joseph Scott — 129

I’ve expanded the list to 15. A lot of the same folks at the very top, but new faces in Liz and Jane from 2.5 and 2.7 usability cycles. Also three people on the list have changed their domain in the past year, just like I did. It must have been a year for that.

Also for fun here are some yearly posting stats courtesy of Alex’s queries:

Posts Avg. Words Total Words Avg. Comments Total Comments
2002 360 139 50,190 1 390
2003 429 168 72,359 3 1,287
2004 990 54 54,257 6 6,236
2005 624 48 30,090 9 5,963
2006 313 70 22,010 11 3,503
2007 334 60 20,267 17 5,919
2008 302 50 15,206 21 6,493

As you can see I’m doing fewer posts with fewer words than ever, but getting more comments. At this rate I’ll be down to 40 words per post next year. Yay brevity. 😉

Working on collating some travel / WordCamp stats.

Podsession Responses

There have been two interesting responses to the podcast I did with Om and Niall the other week. The first was Scott Johnson who responded in a podcast. As I expected, most people are taken aback by my statement to “let the engineers pick” what language and enviroment you use for your product. I think there is one important assumption that wasn’t articulated in that statement: you have brilliant engineers and you trust them. As a psuedo-engineer, I find it insulting when people suggest engineers are unable to factor anything other than their selfish language preferences, things like loaded costs, hardware costs, platforms, long-term viability, hiring, etc are simple variables that can be considered by any intelligent person. If anybody in Automattic came to me that was writing a tool in Python, C, Perl (it’s happened) or whatever, I might ask a question or two but at the end of the day I know they’re able to weigh the costs and benefits just like I would. If you’ve hired an engineer that isn’t able to make these decisions as well or better than you, then you’ve already lost the battle and over time more and more of your time will be spent plugging holes in a descent to mediocrity.

The second response was on the Pronet blog which in an amazing feat of blogging acrobatics managed to mention and link every single person tangentially associated with the podcast except me, even though I’m quoted in every heading. The Google Pages example is brought up again to illustrate that all the hardware in the world sometimes solve a scalability problem, but I still think that’s faulty because none of us had any idea why Pages was slow when it launched, it could have been a faulty router for all we know. Pronet responds to “Go with what your happiest working with” with a set of points to consider for a language, but again with the right people none of that matters. Happiness, in all things not just the language, should be the number goal and metric for everything in an early-stage startup. Happy engineers work smarter, longer, more efficient, attract better candidates, and have a better quality of life. (A corollary is that if you’re already set on a language path, don’t hire anyone who isn’t thrilled with working in that language.) For an example of how this can work in a really extreme case, I suggest everyone read the story of Viaweb and Lisp. (Another talk.)In my mind Lisp is a ridiculous language to build a web application in, but to them and their engineers it was heaven and they had better products earlier than their competition as a result of their unusual choice.

(As an aside, I wonder how many people said the same thing about Ruby for web apps before David Heinemeier Hansson, Rails, and 37signals, or even about PHP before Yahoo and Wikipedia? An example (and a little bit of promotion) is better than a thousand whitepapers.)

The Internet measures everything. And I am a slave to those measurements. After so many years of pushing much of my life through this screen, I’ve started measuring my experiences and my sense of self-worth using the same metrics as the Internet uses to measure success. I check my stats relentlessly. The sad truth is that I spend more time measuring than I spend doing.

Fantastic read over at Tweetage Wasteland : I Don’t Care if You Read This Article. Or put another way “Not everything that can be counted counts, and not everything that counts can be counted.” Hat tip: Mark Riley.

WordPress 19

Today is the 19th anniversary since WordPress’ first release, which is especially exciting for a number of reasons:

  1. The community put together an awesome site celebrating the occasion at wp19.day.
  2. We just had an awesome 6.0 “Arturo” release.
  3. Next week June 2-4 WordCamp Europe returns in-person in Porto, Portugal, and I’ll be there and so excited to connect with the community! Tickets are still available.
  4. Nineteen seems like an in-between number, but actually it’s very salient for me because now WordPress is the same age I was when the first release came out.
  5. Which means I’ve now been working on WordPress half my life!

Cheers and here’s to many more years together. 🥂

WP2 Thoughts

WordPress 2.0 “Duke” is available! Like 1.5 when it first came out I expect it will take a few months before the full implications of this release are realized. There are some surface changes (see 5 little things I like about WP 2.0) that still need some polish in places, but I think the underlying architectual changes are really rock solid. Interface changes are easy to iterate on in future versions. WordPress.org also has a rocking new design from Matt Thomas, and there will be some more action there in the coming months.

BuddyPress for the World

Happy to announce that BuddyPress is now available to the world. BuddyPress is a package built on top of WordPress which transforms WP into a social network complete with profiles, friends, messaging, groups, and even activity streams. Of course it’s 100% GPL and Open Source. It’s built on top of MU (which can be tricky to install) so still not for everybody yet, but this is a major milestone in the WordPress world. Check it out. Congrats to Andy and the whole BuddyPress team. 🙂 Here’s Andy’s official  announcement post and WordPress.org.

Paid Support

We just launched the Automattic Support Network which is a place for companies to purchase paid support for WordPress and MU. Originally I didn't think we'd need to do this, simply because the WordPress.org support forums are so amazing and there is such a good community around it. That hasn't changed, but some big companies and enterprise folks are uncomfortable with volunteer support, and want (and insist) on paying someone before deploying a product. Based on that feedback and a lot of input from Podz, we put together this new product, which is basically VIP support with a guaranteed response time. Toni has some more thoughts here. We also rolled out new pricing for commercial Akismet use a few days ago, and the response has been great so far.

Advice and Fallacies

One of the toughest things in business is when you get well-meaning advice from advisors, investors, or friends of the company who are valuable but might hold some ideas or ways of approaching problems that just aren’t applicable to your particular company or situation. They might be right most of the time, and it might have worked for them in the past to build a huge success, but it doesn’t mean it’s right for you, right now.

This is especially a struggle for Automattic because so much of what we do is deliberately different from companies that have come before us. The below is a sensitive-info-scrubbed version of a comment I made on an internal P2 in response to someone who had met with a close friend of the company who had said we should “hire more business people, and more people like so-and-so, who have a background in and passion for data analysis and structure. He also shared his ideas about what the additional business hires could be responsible for, such as P&L responsibilities for specific products.” The person he had talked to was asking why we weren’t following that advice.

The first part was easy, because so-and-so was actually leading hiring for a position around data and the early results were going well. The rest I ended up writing more about, which follows. It was only meant for internal consumption, so read it as such, but I got enough requests to share the comment publicly that I wanted to clean it up and release it for y’all.

On the “more biz people + P&L” side, it’s an area we disagree.

We’ve had more “business people” in the past, and found it just didn’t move the needle in the same way that investing on the support, engineering, and design side did. They also tended to generate more meetings and work for other people than was commensurate for their contributions.

We’ve also experimented with giving leads P&L responsibility for products and groups, but ultimately it was awkward because we don’t really want leads or teams focused on the loss or costs of what they’re doing — we just want to grow our core metrics and revenue in a healthy and accelerating way, and let Ops and myself worry about overall profit or loss for the company, costs of people and services, capital requirements, etc. We’re still at a stage where our primary goals are investing in growth and product excellence, I wouldn’t want a P&L concern to be a distraction from that, and that also takes us into the territory of different teams having “headcounts” of people they can hire for the year, or budgets set ahead of time and that they’ll lose if they don’t use, zero-sum accounting between teams and more balkanization you often see in larger organizations. When anyone thinks about P&L at Automattic, I want it to be holistically and with a long-term view, not for a single team or product.

It gets backs to the fallacy we talked about and agreed to avoid at the [WordPress.com leads] meetup, which is the business equivalent of Great Man Theory: the idea that a deficiency in the business or product will be solved by hiring someone senior to be in charge of that thing. Example: Automattic is bad at marketing, we should hire a CMO. (99% of the time when this is suggested it means an external person, because if anyone internal was good the problem wouldn’t exist.) It’s an easy thing for anyone to fall into, you can see it in [a recent internal thread].

This must work sometimes, because it seems to be a near-universal affliction of VCs on startup boards. It also is a little bit of a bikeshed, because while it can be difficult to understand or feel like you can have an influence on something fundamental to the product, like say the signup flow, most VCs have large professional networks and can have long and vigorous discussions talking about potential people who are executives in a given area and their first or second degree connections to them. Of course, like many of us, VCs are consumers of tech media which tends to ascribe all the success of an organization to a single person (like Sheryl Sandberg for Facebook not falling apart, or Adam Bain for revenue at Twitter). However often the problem has root causes more fundamental than a single person could shift.

I subscribe to a more environment-driven approach, that if you break down a problem into its component parts you can address them individually, often with relatively simple next steps, and build things from the ground up, rather than the top down. If you can’t do that, then it’s best to be candid that the area is not a priority and make sure that’s in line with what you’re focusing on instead. In this process leaders will emerge or if the effort matures to a point where one joins as a new hire he or she will have the resources, groundwork, and environment to succeed.

So in summary: always go back to first principles of decisions. Hires are seldom panaceas. Someone being successful in a role at another company doesn’t mean they actually did the work, or were the cause of the success. If there’s an area you’re weak, try to figure out the root causes of why you’re weak, and where possible try to improve the environment that creates the problem before pinning the turnaround on a “Jesus hire.” When you improve the environment it makes it much more likely a new external hire will do well. The majority of success or failure is a result of the environment, at least as much as the individuals involved.