Automattic, the company I work for behind WordPress and WooCommerce, started a one-month company-wide experiment, Radical Speed Month, to test the opposite of big-team structures: self-pairing in teams of two, removing approval layers, no marketing, design, or product sign-off, and just shipping something real. All of those things, including security, still matter, arguably even more, but now they are concentrated in a pair, equipped with AI tools that have access to company context and using the judgment that experience provides.
It feels liberating. More importantly, it should help us understand which processes are still necessary, which should change, and how to focus on shipping something customers value, getting better and more capable products into their hands sooner.
When I sat down to write this, I noticed a few drafts from the last couple of months that I left unpublished, so this experiment connects to two things I keep thinking about.
The first is how software itself will change. I remembered Steve Jobs launching the iPhone and pointing out that two thirds of the screen was taken by a static keyboard, instead of adapting to the use case. A lot of software still feels like that today. You may only need one third, but the other two thirds come along anyway. A lot of it can be slow, bloated, and irrelevant. We can imagine software that is intuitive, fluid, just in time, and just for you. Constantly reviewed, questioned, simplified, validated, and tested. Just yesterday I watched Maggie Appleton’s talk, “What comes after the PR?”, which focused on the possibility of building much better software using AI in a collaborative way. This is the part that feels promising and exciting.
My second draft focused on a parallel stream of chatter and realizations in the industry. There is a huge question mark around how the industry and organizations around software will change, and how to navigate that change. There is a mix of excitement and uncertainty, not just for me, but for everyone around me. Every developer I talk to is floored by this new reality and these new capabilities. Will we need software, at least in the form we know it now, at all? At the same time, although the tools are clearly revolutionary, why is it still so hard to build something revolutionary with them? Maybe there is an inherent limitation. Or maybe there is still potential that we do not yet know how to tap.
With so much uncertainty, the only sensible response is to take action and learn by doing. No one truly knows where this is going, but standing still does not seem like a serious option. This experiment gives us a practical way to test ideas, build something real, and learn what needs to change.