Product designer Sanja Grbic of Automattic shares her experience during Radical Speed Month, a 30-day company experiment in which Automattic paused its roadmap to see how quickly software could ship. She describes three products she shipped during the month and the insights each revealed about designer-engineer collaboration and how removing bottlenecks can unlock teams. # Channel Identity Observations: Sanja Grbic / Automattic Talk ## Observable Identity Signals - **Speaker affiliation stated explicitly**: "I'm a product designer" at Automattic, "5 years now on the Jetpack design team" — the talk is presented from the perspective of a practitioner inside a large company, not a channel-wide self-description. - **Title framing**: "500 people vibe-coded for 30 days. I was one of them." positions the video as a first-person account of a large-scale organizational experiment, implying the channel surfaces insider talks/experiments. ## Intended Audience - **Practitioners in large organizations**: Direct advice — "If you're in a large organization, try to implement this um even just at your team level" — targets leaders/team members at large product companies. - **Designers and non-engineers adopting AI coding tools**: The narrative arc ("I had never until then actually built and shipped something in code") speaks to designers/non-engineers learning to code with AI. - **People interested in organizational change around AI**: Closing recommendations about access, champions, experimentation space, and agency frame the talk for those driving AI adoption. ## Claimed Scope & Expertise - **Personal experience claim**: "I've spent over a decade building software and watching how teams build software." - **Organizational scope claim**: Automattic described as "around 1,400 people," "fully distributed and asynchronous," behind WordPress.com, Jetpack, WooCommerce, Tumblr, Beeper. - **Experiment scope claim**: "around 500 people that started around 794 projects in these 30 days" during "radical speed month." ## Demonstrated Presentation Patterns - **Case-study structure**: Three sequential projects (board game session manager, design system tracker, WooCommerce iOS chat) each with explicit learnings — a demonstrated pattern of evidence-backed storytelling rather than abstract advice. - **Concrete tool specifics**: Names tools used (Claude Code, "Nano Banana" for illustration, Figma, GitHub, "context AC" MCP server) — demonstrates a technically specific, practitioner-level presentation style. - **Honest limitation disclosure**: Distinguishes work experience from hobby projects ("I've done a small hobby project here or there, but... that was a completely different experience"). ## Self-Description vs. Demonstration - **Claimed**: Role transformation "from a designer to a design engineer" — a creator claim about personal growth, supported by described deliverables (deployed internal and public tracker). - **Demonstrated**: The transcript itself shows a reflective, process-oriented communicator who extracts organizational lessons from personal experience (e.g., "engineers will need to become enablers and teachers"). ## Notes - No curated metadata was supplied; all observations derive from title and transcript. - No channel-level statements (e.g., "on this channel we...") are present — identity evidence is limited to this talk's framing. # Delivery Observations — Sanja Grbic, "500 people vibe-coded for 30 days" ## Overall Tone & Register - **Conversational, talk-format delivery**: opens with a direct address — *"Hi there. Welcome to my talk. My name is Sanja and today I'm going to share with you an experiment"* — and closes with a polished summary and call to action: *"Thank you."* - **Enthusiastic, positive framing**: recurring intensifiers like *"very very helpful,"* *"really really really great,"* *"really mind-blown,"* *"incredible shift."* - **First-person storytelling**: consistently anchors the material in personal experience — *"I built three projects during this time,"* *"my skills and process and collaboration style shifted."* ## Structural Habits - **Signposting between sections**: explicit transitions such as *"Before I dive into the experiment,"* *"So back to the experiment,"* *"Moving on to the second project,"* *"And then that was 2 and a 2 weeks."* - **Setup → project → takeaway pattern** for each of the three projects, with each ending in a distilled insight (e.g., *"the biggest insight, I think, for me from this project was..."*). - **Context-first framing**: long contextual preamble about Automattic, her background, and AI enablement before reaching the experiment itself. ## Vocabulary & Recurring Phrases - **Repeated keywords**: *"speed"* / *"velocity"* / *"unlock speed"*; *"agency"*; *"experiment"* / *"experimentation"*; *"enabler"* / *"enabling"*; *"prototype"*. - **Paired-team language**: *"two-person teams,"* *"pair with a partner,"* *"I paired with an engineer,"* *"I paired with a fellow designer."* - **Quantitative specificity**: frequent concrete numbers — *"1,400 people,"* *"5 years,"* *"2 weeks,"* *"2 hours,"* *"2 and a half weeks,"* *"6 days,"* *"30 days,"* *"500 people... around 794 projects."* ## Teaching Habits - **Defining terms for the audience**: explains distributed work — *"We're fully distributed and asynchronous which means that most of our work... are very well documented"* — and contextualizes Jetpack: *"If you use WordPress, you might know what that is."* - **Contrast framing** to build understanding: small teams vs. large organizations; Figma-first vs. prototype-first process; designer vs. design engineer. - **Distilled, transferable lessons**: converts personal experience into generalized advice — *"engineers will need to become enablers and teachers,"* and a closing imperative list: *"provide your people with the access to the new tools, find your enablers and champions, create space for experimentation, and give them agency."* ## Speech Patterns (verbatim transcript features) - **Noticeable self-repairs and stutters**: *"of of roles,"* *"to to to set up a project,"* *"the the the prototype,"* *"I I I had the agency."* - **Fillers**: frequent *"um"* and *"uh"* throughout, e.g., *"Uh I'm going to share my personal journey."* - **Repeated word doubling**: *"very very helpful,"* *"really really great,"* *"distributed distributed."* - These suggest spoken, unscripted-sounding delivery; the transcript is likely a raw ASR capture, so punctuation of pauses is uncertain. ## Narrative Habits - **Highlighting surprise/learning moments**: *"I was really mind-blown at what I was able to achieve,"* *"I thought I understood Git, but actually I didn't."* - **Reframing setbacks as luck or growth**: *"One lucky circumstance for me was..."*; *"I was kind of empowered by the previous exercise."* - **Crediting others**: names the engineer who *"was really really great at setting us up for success,"* and thanks the systems team — a modest, team-oriented attribution style. ## Uncertainty Notes - No timestamps or tone-of-voice (audio) evidence are available beyond the transcript; observations about warmth or enthusiasm rely on word choice only. - Recurring phrases like *"really"* appear frequently enough to be a stable pattern; some doubled words may be transcription artifacts rather than spoken emphasis — this cannot be confirmed from text alone. # Observation Document: “500 people vibe-coded for 30 days. I was one of them.” — Sanja Grbic, Automattic ## Speaker - **Sanja Grbic**, product designer at Automattic (5 years, Jetpack design team), self-described non-engineer with 10+ years building software. All claims below are hers from the talk. ## Context She Establishes - **Automattic**: ~1,400 people, fully distributed and asynchronous; extensive documented knowledge from “the past couple of decades.” Company behind wordpress.com, Jetpack, WooCommerce, Tumblr, Beeper. - **AI at Automattic before the experiment**: access to tools/courses, then a **two-week role-specific immersive “AI enablement” course** for every employee; later, everyone encouraged to contribute code. Credits the systems/operations team for security, processes, and documentation good enough for a non-engineer to spin up a dev environment. Mentions an **MCP server (“context AC”)** giving AI tools access to internal knowledge, used daily for research and planning. - Her stated premise: AI raises speed expectations for all roles, but velocity differs between small 1–3 person teams on zero-to-one products and large organizations with 5–20-year-old software and thousands of people. ## The Experiment: Radical Speed Month - ~2 months before the talk (as stated): pause roadmap work for **30 days**, pair up, “ship something real.” AI use welcome but not required. - Run in stages; roughly **a third of the company (~500 people)** in the first round, starting **~794 projects**. - Grbic concurrently attended the in-person AI enablement course, which she says is why AI tools played a huge role in her output. ## Project 1: Board Game Session Manager - **Team**: two designers, one engineer, one product lead; built in **2 hours** as a training exercise. App to create/view/join/manage board game sessions, including chat; 16-bit office illustration (made with “Nano Banana”). - **Process**: engineer set up the GitHub project, taught Git basics. Grbic: she thought she understood Git but “actually I didn't.” - **Claimed insight (quoted)**: “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.” Generalized: **engineers will need to become enablers and teachers**; with AI, everyone can do some work outside their domain. ## Project 2: Design System Status Tracker (main project) - Paired with an engineer and a design ops person; goal: surface up-to-date design system info to humans and AI tools. Design system is open source, serves many products, “always in flux.” - Her proposed solution raised engineer questions about **performance, maintenance, and feasibility** — a recorded tension she resolved by building the full idea herself as a proof of concept. - **Build**: discovery by three; design/build solo, ~2.5 weeks. Tracker pulls links from GitHub, Storybook, Figma; sorts by status, tags library names; search “worked perfectly.” Shared with designers, iterated on feedback. - **Process shift**: built the prototype first, used Figma only later for visual fine-tuning (delivering images for things she couldn't explain to the tool). Prototype in ~1 week, plus ~1.5 weeks to rebuild/fix, host internally and on a public-facing site. - **Claimed significance**: a “defining moment” — moved from **designer to design engineer**, enabled mainly by **owning the entire process** (agency, no negotiation/handover time), not just by AI. ## Project 3: iOS Chat for WooCommerce Merchants - Paired with another designer; **zero to working proof of concept in 6 days**. - Features claimed: real-time shopper replies from phone, optional AI answering; wordpress.com authentication; Jetpack connection; a widget inheriting site theming; an AI agent that scans the site and “discerns whether it can answer a question or not.” - **Process claims**: alignment/ideation easy because both were designers “with the users in mind”; used a Claude Code project folder as shared file system for chats/ideas, which “significantly sped up collaboration” — a practice she continued. Prototype again the main artifact; Figma used only afterward for mood board/UI fine-tuning, reversing the usual high-fidelity-Figma-first workflow. ## Overall Claims and Reasoning - In 30 days, her long-standing process “completely shifted,” and she asserts “that was true for many other people.” - Three-stage framing: (1) engineer role elevated from **builder to enabler** — a skill she believes will be crucial as more roles work in code; (2) her own shift to **design engineer**, including pushing code to production within a large system requiring serious onboarding/security; (3) the third project as “proof” the speed was unlocked via shared understanding of the tools. - **Recommendation to large organizations**: changing tools/processes requires shifting human behavior — provide tool access, find enablers and champions, create space for experimentation, and give people **agency** so they can break habits and unlock AI-driven speed. ## Qualifications and Unresolved Points (preserved) - The experiment's causality is her personal framing; she presents her outcome as enabled jointly by AI tools, the concurrent training, and autonomy — she names agency as “most of all.” - The design system tracker's feasibility concerns from the engineer are noted but not reported as resolved beyond her proof of concept. - “~500 people / ~794 projects” applies only to the **first round**, staged participants; company-wide outcomes are not quantified. # Video Attribution Observation Record ## Video Metadata - **Title:** 500 people vibe-coded for 30 days. I was one of them. - Sanja Grbic, Automattic - **Video ID:** `01a15ca8-d4b7-7e68-93ee-1efffe188945` - **Format:** Conference-style talk ("Welcome to my talk"), single speaker presentation. ## Speakers & Roles ### Primary (and sole) Speaker - **Name:** Sanja Grbic (per title metadata; self-identifies as "Sanja" in transcript) - **Role:** Creator / Presenter - **Professional identity (self-stated):** - Product designer at **Automattic**, ~5 years on the **Jetpack design team** - Over a decade building software - Self-described transition during the talk: "from a designer to a design engineer" ### Referenced Third Parties (not speaking, described by speaker) - **Unnamed engineer** in first project team — role: enabler/teacher who set up GitHub project - **Unnamed design operations person** and **engineer** — second project discovery partners - **Unnamed fellow designer** — third project pairing partner - **Automattic systems and operations team** — credited with security/processes/documentation setup - **Automattic as organization** — ~1,400 people, fully distributed and asynchronous ## Referenced Sources & Tools - **Companies/products cited (descriptive, not promotional claims by third parties):** WordPress ecosystem (wordpress.com, Jetpack, WooCommerce), Tumblr, Beeper, Sketch, Figma, Adobe suite, GitHub, Storybook - **AI tools named by speaker:** Claude Code (transcribed as "Cloud Code" / "claw code"), Nano Banana (image generation), "context AC" (an MCP server for internal knowledge access — name as transcribed) - **Internal initiatives described:** AI enablement two-week course; "Radical Speed Month" (30-day experiment, ~500 participants, ~794 projects) ## Promotional Segments - **None flagged.** The talk is a first-person retrospective of an internal company experiment. Mentions of specific tools (Claude Code, Nano Banana, context AC, Figma) are described as tools used, without commercial promotion or sponsor attribution in the transcript. ## Availability & Uncertainty - **No curated metadata supplied** beyond title; no comment availability, citations, or external source links present. - Tool names "context AC" and "Cloud Code" reflect transcript phonetics; exact product spellings unverified from source. - No timestamps or quotations verifiable beyond transcript text; no third-party claims from outside the speaker's own account. Hi there. Welcome to my talk. My name is Sanja and today I'm going to share with you an experiment we did at our company that's somewhat unusual and very exciting. It was a one-month initiative called radical speed month where two-person teams were given full autonomy to build and ship projects. I built three projects during this time. I will walk you through them and we'll talk about the outcomes and learnings for myself as a designer as well as the system-wide impact this experiment had. I'll tell you a little bit about Automattic first. We're the company behind several products in the WordPress ecosystem such as wordpress.com, Jetpack, WooCommerce, as well as many other brands like Tumblr, Beeper, and many more. We are around 1,400 people and we're fully distributed which is pretty interesting for also what what I'm about to show you. We're fully distributed distributed and asynchronous which means that most of our work, our thoughts, our concepts from the past couple of decades are very well documented. I'm a product designer and I've spent over a decade building software and watching how teams build software. I've worked for I've been at Automattic for 5 years now on the Jetpack design team and in the past I worked for several companies of different sizes, different types of products, and different team organiza- configurations. So after all these years I've not only accumulated experience in designing products, I also have a lot of insight into team dynamics and organizational structures within product teams. Over the years the the designer role has morphed and evolved a lot. We we had We still have all of these different types of of roles like web designers or UX designers or interaction or product designers. We've also used many different tools from the Adobe suite to Sketch to Figma and many many others in addition to those. And AI is a new tool. It is definitely not built just for designers. It's versatile so it can be used by many other um many different roles, but the expectation is is the same for everyone. It's that it will bring a speed. And of course, this is why companies are rushing to put it to use. But no matter what role uses AI, um this velocity is going to look very different in small teams like one to three people that are building new products. Let's say a zero to one product versus large organizations that might have built entire entire product ecosystems, that have software that's anywhere between 5 and 20 years old and that have uh more than a thousand or even thousands of people. Before I dive into the experiment, I will tell you a little bit about what preceded it in terms of how we use AI at Automattic. We were encouraged to use it, to learn it, and to experiment with AI from the very beginning. At first, we had access to tools and courses. Then the AI enablement was initiated where every single employee goes through a two-week course designed specifically for their role. This is completely immersive with lectures and and focused hands-on time. Very very helpful. And over time as AI coding tools got better, everyone was encouraged to get comfortable with contributing in code. And we can thank our systems and operations team for setting up fantastic security and processes as well as documentation that's good enough that a non-engineer such as myself can spin up a working development environment. And last but not least, an incredibly helpful tool that I that I use every day for research and planning is context AC. It's an MCP server that gives AI tools access to all of the knowledge and data that we have documented over the years that I previously mentioned. So back to the experiment. About 2 months ago, we kicked off this project. The instructions were to pause the roadmap work for 30 days, pair with a partner, and ship something real. We were welcome to use AI, though it wasn't a requirement. And of course, um we couldn't all do this at once. We had to do this in in stages, and we had about a third of the company participating in the first round. That's around 500 people that started around 794 projects in these 30 days. One lucky circumstance for me was that during this month, I was also participating in this 2-week in-person AI enablement course. So AI tools played a huge role in what I was able to deliver. Um and that's why I was building not one but three different projects. And when Radico Speedman started, uh I I had some knowledge of GitHub. I would review PRs. I had played around with cloud code. But I had never until then actually built and shipped something in code. And I mean at work. Like I've done a small hobby project here and there, but that's completely that was a completely different experience. Uh I'm going to share my personal journey of how my skills and process and collaboration style shifted over the over the course of the 30 days. And this will also give us insights into how this change can be promoted and implemented at the organizational level for large companies. So this is the story of the first project I worked on and my first contributions in code. As I mentioned at the time uh Radical Speed Month was starting, I was at the in-person A&E enablement training. And over there we did an as as part of the program we did an exercise where as a group of four we had uh 2 hours to build something together. We were two designers that aren't super comfortable in code, an engineer, and a product lead. And we decided to build this board game session manager. We had a board game evening planned that night. Uh so we wanted to create an app that's that's used to create, view, and join, and manage board game event sessions. Um you can see what that looked like. This is what we built in in 2 hours. We built an app um where people can start and stop uh uh a session, uh see what games and spots are available, and even chat with each other. And on top of that we chose this 16-bit style um illustration of our actual office that uh people found especially appealing. The most interesting thing about this project isn't what we built. It was how we worked together and leveled up together. Uh at the very beginning we agreed that we all want to uh contribute, and we were very lucky that the engineer that was uh in our group was really really great at setting us up for success. So she set up the project in GitHub, helped us grap grasp some basic commands, and helped us understand how Git works. I worked with versioning in the past um for you know, in different situations, but and I thought I understood Git, but actually I didn't. I really needed someone to to tell me how it works and and what what are the best ways to to to set up a project. We were sitting together, we were testing out the app, and we were building it um together and dividing the work among us. So, we were committing code to this project. And since this wasn't this this app that we were building, it's not related to any of of our existing products, so there were no risks involved, and our focus was on learning, which was really really really great. We only used Cloud Code for this purpose, and outside of that, I think the only visual tool used was Nano Banana to to create um uh to create the office illustration. And the biggest insight, I think, for me from this project was that 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. And for any this this is a great learning for any role. It can be um the same for engineering or design or product. Keep in mind that when you're working on a team with mixed abilities, and if you're stronger in a specific skill, make sure that you're helping and enabling each other up, because now with AI, we can all do a little bit um of the work that's outside of our domain. And this was the biggest learning for me, uh that engineers will need to become enablers and teachers. Moving on to the second project I worked on, this was my main focus for the radical speed month. I paired with an engineer and um a design operations person. And our goal, our main goal, we we worked on some design system projects together in the past. And here our main goal was to surface relevant and up-to-date design system information to humans and AI tools. And this um problem space is huge. Our design system uh that we use for our WordPress ecosystem products is open source. It serves many products internally and externally and is always in flux. So, the problem space was big. Uh we saw a lot of opportunities. So, we decided to divide and each person took on a problem to tackle. And what I proposed this design system status track tracker um the solution that I proposed raised questions with the engineer around performance, around maintenance, and if we would be able to to build it in the first place. But I was kind of empowered by the previous exercise. I was allowed to experiment, so I decided to build the full idea as a proof of concept on my own. So, um the discovery portion was three people, but the design and build was just myself. And it took around 2 and 1/2 weeks to build this. And as I worked on it piece by piece, especially uh when I reached the point where I had actual live component previews working, I was really mind-blown at what I was able to achieve. I moved through the project without any um without any restrictions in mind. Um I was just trying to push the limits. And um the tracker was picking up links from the GitHub repo, from Storybook, from Figma, sorting them according to status, tagging them with the correct library names. Search worked perfectly, and I was really excited about this product, and I shared it with fellow designers. I iterated a little bit based on the feedback, but everyone was pretty excited. I built the prototype initially as a start, and then I used Figma only later in the process for some visual fine-tuning. Some things that I just couldn't explain to claw to claw code, I I wanted to deliver an image, and that worked. But the live project was was I was what I was iterating on directly. And the prototype was built within a week, and then it took another week and a half to rebuild it for some fixes, to set up a hosting, and deploy it in our internal platform as an internal tool, as well as on an external public-facing site with that that had a little bit of a curated um data and information. And delivering this this product was a defining moment for me, where I moved from a designer to a design engineer. This is of course enabled by AI, but most of all, it was enabled by the fact that I could own the entire process. We were within the radical speed month, I was allowed to experiment. I I I had the agency and made all of the necessary decisions. In large organizations, this is very hard to do, but here I could just build whatever I thought was um was needed, and I didn't have to spend a lot of time in negotiations and handover. And then that was 2 and 1/2 weeks, so I kind of had 1 week left Um a radical speed month, so I paired with a fellow designer and here you'll be able to see the incredible shift and speed and process that happened. In only 6 days, we went from zero to uh through the entire process to building an iOS chat for WooCommerce merchants that um allows them to answer shoppers in real time, reply from their phone, or even set up AI to answer the uh questions for them. And this is a fully working proof of concept that includes authentication through wordpress.com, includes a Jetpack connection. If If you use WordPress, you might know what that is. Um we also built a widget that inherits the site theming where the site visitors can actually ask the questions, as well as the the fully capable AI agent that scans the site for information and answers visitors' questions in real time, and also discerns whether it can answer a question or or not. What was important here was that the the alignment and the the ideation part was fairly easy. It was fairly easy for us two designers to align and shape the features with because we always have the users in mind. And on the process side, um what was interesting is that we started the exploration as a cloud code project folder where all of the chats and ideas were recorded into a file system. And I I noticed that that um significantly uh sped up collaboration, as well as build later. And we've uh continued I've continued this practice in my in my daily work. Um the main artifact we worked on here as well was the prototype. And that's the biggest shift for our process because normally we would start in Figma and we would work in Figma until we reach very high fidelity. But here uh, we had uh, very good plan. Then we um, built the the the prototype or the product and then we went back into Figma to just come back to it in a visual sense to build a mood board and for some UI fine-tuning. And in only 30 days, my process that has been similar for years has completely shifted. And that was true for many other people. The first project showed me how the engineer's role can be elevated from a builder to an enabler. And this is a skill that I believe will be crucial as more and more um, people in other roles start working in code. The second one moved me from a designer to a design engineer. Um, and here I'm talking about being able to push code to production in a well-established large system that requires serious onboarding and security practices. 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. And and the third project that I shared was just proof that we've unlocked speeds because I already had adjusted my process a little bit, but then we both leveled up together and had a shared understanding on how we can apply the tools so we could also easily meet each other. If you're in a large organization, try to implement this um even just at your team level. Uh changing processes or tools in large organizations requires shifting the human behavior behind them. So, provide your people with the access to the new tools, find your enablers and champions, create space for experimentation, and and give them agency so that they can break out of their habits and unlock the speed that AI tools can bring. Thank you.