Automattic's 30-Day AI Experiment Changed How

Automattic — the company behind WordPress.com, WooCommerce, Tumblr, and a family of other web products, with roughly 1,400 employees according to its own press page — did something unusual a couple of months ago. It told a large portion of its staff to stop whatever they were working on, pair up with one other person, and spend 30 days building and shipping something real. No roadmap obligations. No lengthy approval chains. Just: make something, and get it out the door.

They called it Radical Speed Month.

Sanja Grbic, a product designer on the Jetpack team with over a decade in the industry, used those 30 days to ship three products. She spoke recently about the experience, and her account is worth sitting with — not because it proves AI is going to change everything, but because it raises a sharper, more specific question: what actually has to be in place before AI tools can deliver the velocity everyone keeps promising?

Automattic Had Already Done the Hard Work

Before Grbic describes a single project, she describes what Automattic had built before the experiment started. The company had already rolled every employee through a two-week, role-specific AI training course — immersive, with hands-on time, not a slide deck you click through on your lunch break. The systems team had set up documentation clean enough that a non-engineer could spin up a working development environment without calling IT. Years of asynchronous, distributed work meant the company's institutional knowledge was written down and searchable rather than locked inside people's heads.

That backstory is the story. Radical Speed Month was the spark; Automattic's infrastructure was the kindling.

Grbic is direct about this: "All of the company initiatives that I described together gave me the space I needed to experiment and find my own process that works within what we already have established in the company." She's not describing a tool that works out of the box. She's describing what happens when an organization has spent real time — and real money — preparing its people and its systems to work differently.

What Happens When the Bottleneck Disappears

Grbic's three projects trace a learning curve in compressed time, and the arc is instructive.

The first was a group exercise — a board game session manager built in two hours with two designers, an engineer, and a product lead. Grbic is candid that she thought she understood Git, the version-control system software teams use to manage code changes without overwriting each other's work. She didn't, not really, until the engineer in the group walked everyone through it. The product itself was trivial — a fun, low-stakes app with a charming 16-bit illustration of their office. What mattered was the dynamic: the engineer spent her time teaching rather than building, and the whole group moved faster because of it.

Grbic's observation from this exercise is the most durable insight in her talk: "If you're an engineer, the impact that you have when you enable others may be far greater than the impact of doing more engineering yourself."

The second project — her main focus for the month — was a design system status tracker. A design system, for readers outside the industry, is essentially the shared visual vocabulary a company's products use: standard buttons, colors, layout rules, components. Keeping track of which pieces are current, which are deprecated, which have been updated across multiple products is genuinely complicated. Grbic proposed a tool to surface that information automatically, pulling data from GitHub (where code lives), Storybook (a tool for cataloguing and previewing individual interface components in isolation), and Figma (the design tool most product teams use to mock up what something should look like before it gets built).

The engineer on her team had doubts about whether it was feasible. Grbic built it anyway, largely on her own, over about two and a half weeks. The AI coding tool she used — Claude Code, an AI assistant that writes and edits code based on plain-language instructions — handled most of the actual code generation. She used Figma late in the process only for fine-tuning visual details she couldn't easily communicate any other way. Everything else she built directly in the live project, iterating as she went.

"Delivering this product was a defining moment for me," she said, "where I moved from a designer to a design engineer."

Think of it the way desktop publishing reshaped newsrooms in the 1980s: a layout editor who once depended entirely on a typesetter to physically set type could suddenly control the finished page herself. The bottleneck between conception and execution collapsed, and with it, the traditional division of labor.

That's what happened to Grbic. The AI didn't replace the engineer — the engineer was still essential in project one. But it gave Grbic enough capability to own an idea from concept to deployment without waiting for a handoff that might never come on the right timeline.

The third project — an iOS chat tool for WooCommerce merchants, built with a fellow designer in six days — arrived almost as proof of concept. By that point, both designers had adjusted their process. They started not in Figma, where designers traditionally work out ideas at high fidelity before a single line of code is written, but in a structured project folder where their planning conversations and decisions were documented as they worked. The prototype came from building, not from mockups. Figma came back only at the end, for aesthetic polish. A fully working proof of concept, including AI-powered responses to shoppers and real-time chat, in six days, by two people without engineering titles.

The Question Every Manager Should Be Asking

Here is where I want to be precise, because there's a version of this story that's easy to misread.

The takeaway is not "give your team AI tools and watch them ship faster." If Automattic had simply handed everyone a Claude subscription in January and wished them luck, Radical Speed Month would have produced a lot of half-finished experiments and some frustrated employees. What Automattic actually did was invest — in training, in documentation, in infrastructure, in permission to fail — before it ever asked people to move fast.

Grbic's prescription for large organizations is to "provide your people with access to the new tools, find your enablers and champions, create space for experimentation, and give them agency so that they can break out of their habits." That's not advice you can implement in an afternoon. It describes an organizational posture that takes months to develop and requires genuine commitment from leadership, not just a line item in a budget. Most companies rushing to deploy AI tools are skipping straight to the experiment without building the substrate that makes the experiment work.

The uncomfortable implication of Grbic's account is that Automattic succeeded partly because of who it already was: a fully distributed, documentation-obsessed, asynchronous-first company whose institutional habits turned out to be excellent preparation for an AI-augmented workflow. A more typical organization — one where knowledge lives in meetings and in people's heads, where security processes are a maze, where role boundaries are defended rather than permeated — will get a different result from the same experiment.

That's not an argument against trying. It's an argument for being honest about what "trying" actually requires. The companies that replicate Radical Speed Month's results won't be the ones that announce a 30-day sprint next quarter. They'll be the ones that spend the next 18 months building the conditions Automattic already had when the sprint began.