The other day we passed product release number 25,000 for WordPress.com. That means we’ve averaged about 16 product releases a day, every day for the last four and a half years! How is this possible and why do we release software in this way?
Launching products is one of the hardest things companies do. Most companies pour months of work into making sure everything goes right at a launch – the features are right, the marketing is ready, the press is primed, the product is solid, etc. But a new breed of companies are doing things very differently. Instead of optimizing product launches to go as perfectly as possible, they optimize to have them go as quickly as possible.
Let’s compare and contrast:
#1 Optimize for perfection: Features are carefully analyzed and planned, progress is reviewed at multiple stages with various stakeholders, multiple development and testing cycles, launch dates are carefully planned out and coördinated. Result: Product is released every few months.
#2 Optimize for speed: Features are broken into smallest possible pieces, code is incrementally developed, tested and launched, launch dates are fluid, products can be updated in seconds. Result: Product is released continuously. The emerging term for this is continuous deployment.
People will tell you that it’s easy to be fast when your product team is tiny and you have just a few customers, but when you grow you will need to put product development processes in place that will slow things down but help you prevent chaos. One of our goals at Automattic is to prove that particular piece of conventional wisdom wrong. To do so, we have continued to invest in high-speed product releases as our team and customer base have grown. Here is how we do it:
Continue reading In praise of continuous deployment: The WordPress.com story
I’ve noticed a new trend in Silicon Valley. More and more startups are beginning life as distributed companies, and investors and partners are starting to accept it as normal. Our company Automattic is distributed, and I’m ready to sing the praises of running a business in this way. BTW, I think distributed (“evenly spread throughout an area”) is a better description than the more commonly used virtual (“nearly real or simulated to be real”) for a company that has people working from all over the place instead of a centralized office. In Automattic’s case, we currently have over 50 employees spread across 12 US states and 10 countries.
Here are my top 5 reasons why you should consider the distributed model for your company:
- Continue reading 5 reasons why your company should be distributed
Last Saturday marked my fourth anniversary as CEO of Automattic. It’s been an amazing time so far. I think 4 years is the longest I’ve ever been with one company. It’s also the length of an undergraduate college education (!) which gave me the idea to make a list of things I’ve learned during the last few years. The list is getting pretty long and is looking like a good set of suggestions for a series of blog posts about “Lessons learned at Automattic (so far)”. I’m hoping to do a post every week or two, starting with some of the topics I often get asked about:
- Open source business models: How did we structure Automattic as a commercial entity that both benefits from and supports the open source WordPress project?
- Distributed companies: We are a team of 50 people spread across 12 US states and 10 countries. How do we make that work?
- Internet scale services: We run multiple web services that see hundreds of millions of visitors a month. How do you reach an audience the size of Amazon’s and AOL’s with a small startup team?
There’s a lot more. Feel free to suggest what you think would be interesting to hear about (and to nag me if I don’t follow-up!).