SPEAKER_00
Hi there, welcome to my talk. My name is Sania 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 Automatic 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 1400 people and we're fully distributed which is pretty interesting for also what I'm about to show you. We're fully 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 at Automatic for five years now on the Jetpack design team and in the past I've worked for several companies of different sizes, different types of products and different team organizational 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 designer role has morphed and evolved a lot. We still have all of these different types 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 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 different roles but the expectation is the same for everyone. It's that it will bring us speed and of course this is why companies are rushing to put it to use. But no matter what role uses AI, 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 product ecosystems that have software that's anywhere between five and twenty years old and that have 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 Automatic. 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 project was initiated where every single employee goes through a two-week course designed specifically for their role. This is completely immersive with lectures and focused hands-on time, 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 use every day for research and planning is Context AHC. 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 two 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, we couldn't all do this at one time. So we had to do this 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 two week in-person AI enablement course. So AI tools played a huge role in what I was able to deliver. And that's why I was building not one, but three different projects. And when Radical Speed Month started, I had some knowledge of GitHub. I would review PRs. I had played around with Cloud Code. But I had never actually built and shipped something in code at work. I've done a small hobby project here and there, but that was a completely different experience. I'm going to share my personal journey of how my skills and process and collaboration style shifted 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 Radical Speed Month was starting, I was at the in-person AI enablement training. And over there, as part of the program, we did an exercise where as a group of four, we had two 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. So we wanted to create an app that's used to create, view and join and manage board game event sessions. You can see what that looked like. This is what we built in two hours. We built an app where people can start and stop a session, see what games and spots are available and even chat with each other. And on top of that, we chose this 16-bit style illustration of our actual office that 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. At the very beginning, we agreed that we all want to contribute and we were very lucky that the engineer that was in our group was really great at setting us up for success. He set up the project in GitHub, helped us grasp some basic commands and helped us understand how Git works. I worked with versioning in the past in different situations, and I thought I understood Git, but actually I didn't. I really needed someone to tell me how it works and what are the best ways to set up a project. We were sitting together, we were testing out the app and we were building it together and dividing the work among us. So we were all committing code to this project. And since this app that we were building wasn't related to any of our existing products, there were no risks involved and our focus was on learning, which was really great. We only used Cloud Code for this purpose. And outside of that, the only visual tool used was Nano Banana to create the office illustration. And the biggest insight 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 role, this is a great learning. It can be 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. Because now with AI, we can all do a little bit of the work that's outside of our domain. And this was the biggest learning for me, 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 a design operations person. And our main goal, 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 problem space is huge. Our design system 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. 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 tracker, the solution that I proposed raised questions with the engineer around performance, around maintenance, and if we would be able to build it in the first place. But I was 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 the discovery portion was three people, but the design and build was just myself. And it took around two and a half weeks to build this. And as I worked on it piece by piece, especially when I reached the point where I had actual live component previews working, I was really blown away at what I was able to achieve. I moved through the project without any restrictions in mind. I was just trying to push the limits. And 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 Cloud Code. I wanted to deliver an image and that worked. But the live project 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 hosting and deploy it in our internal platform as an internal tool, as well as on an external public facing site that had a little curated data and information. And delivering 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. And then, of course, within Radical Speed Month, I was allowed to experiment. 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 needed and I didn't have to spend a lot of time in negotiations and handover. And that was two and a half weeks. So I had one week left in Radical Speed Month. So I paired with a fellow designer. And here, you'll see the incredible shift in speed and process that happened. In only six days, we went from zero through the entire process to building an iOS chat for WooCommerce merchants that allows them to answer shoppers in real time, reply from their phone, or even set up AI to answer the questions for them. And this is a fully working proof of concept that includes authentication through WordPress.com, includes a Jetpack connection. If you use WordPress, you might know what that is. We also built a widget that inherits the site theming, where the site visitors can ask questions, as well as a 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 not. What was important here was that the alignment and the ideation part was fairly easy. It was fairly easy for us two designers to align and shape the features because we always have the users in mind. And on the process side, 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 noticed that significantly sped up collaboration, as well as the build later. And I've continued this practice in my daily work. 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 we had a very good plan. Then we built the prototype or the product. And then we went back into Figma to 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 people in other roles start working in code. The second one moved me from a designer to a design engineer. 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 the third project that I shared was proof that we've unlocked speed 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 larger organization, try to implement this even just at your team level. Changing processes or tools in large organizations requires shifting the human behavior behind them. So 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 and unlock the speed of the tools. And then we'll see what AI tools can bring. Thank you.
SPEAKER_00
with it 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 Automatic 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 1400 people and we're fully
SPEAKER_00
distributed which is pretty interesting for also what I'm about to show you. We're fully 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 Automatic for five years now on the Jetpack design team and in the past I've worked for several companies of different sizes, different types of products and different team organizations configurations. So after all these years I've not only accumulated
SPEAKER_00
experience in designing products, I also have a lot of insight into team dynamics and organizational structures within product teams. Over the years the designer role has morphed and evolved a lot. We still have all of these different types 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 many different roles but the expectation is is the same for everyone. It's that it will bring us speed and of
SPEAKER_00
course this is why companies are rushing to put it to use. But no matter what role uses AI, 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 product ecosystems that have software that's anywhere between five and twenty years old and that have 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 Automatic. We were encouraged to use
SPEAKER_00
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 project was initiated where every single employee goes through a two-week course designed specifically for their role. This is completely immersive with lectures 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
SPEAKER_00
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 use every day for research and planning is Context AHC. 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 two 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, we couldn't all do this at one time.
SPEAKER_00
So once we had to do this 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 two week in-person AI enablement course. So AI tools played a huge role in what I was able to deliver. And that's why I was building not one, but three different projects. And when Radical Speed Month started, I had some knowledge of GitHub. I would review PRs. I had played around with cloud code.
SPEAKER_00
But I have 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. I'm going to share my personal journey of how my skills and process and collaboration style shifted 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.
SPEAKER_00
So this is the story of the first project I worked on and my first contributions in code. As I mentioned at the time Radical Speed Month was starting, I was at the in-person AI enablement training. And over there, we did an, as part of the program, we did an exercise where as a group of four, we had two 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. So we wanted to create an app that's used to create, view and join and manage board game event sessions.
SPEAKER_00
You can see what that looked like. This is what we built in two hours. We built an app where people can start and stop a session, see what games and spots are available and even chat with each other. And on top of that, we chose this 16-bit style illustration of our actual office that 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. At the very beginning, we agreed that we all want to contribute and we were very lucky that the engineer that was in our group was really, really great at setting us up for success.
SPEAKER_00
He set up the project in GitHub, helped us grasp some basic commands and helped us understand how Git works. I worked with versioning in the past for, you know, in different situations, but, and I thought I understood Git, but actually I didn't. I really needed someone to tell me how it works and what are the best ways to set up a project. We were sitting together, we were testing out the app and we were building it together and dividing the work among us. So we were all committing code to this project. And since this wasn't this, this app that we were building, it's not related to any of our existing products.
SPEAKER_00
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 create the office illustration.
SPEAKER_00
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 is a great learning for any role. It can be 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 of the work that's outside of our domain. And this was the biggest learning for me, that engineers will need to become enablers and teachers.
SPEAKER_00
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 a design operations person. And our goal, our main goal, 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 problem space is huge. Our design system 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. We saw a lot of opportunities. So we decided to divide and each person took on a problem to tackle.
SPEAKER_00
And what I proposed, this design system status tracker, the solution that I proposed raised questions with the engineer around performance, around maintenance, and if we would be able 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 the discovery portion was three people, but the design and build was just myself. And it took around two and a half weeks to build this.
SPEAKER_00
And as I worked on it piece by piece, especially 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 restrictions in mind. I was just trying to push the limits. And 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.
SPEAKER_00
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 wanted to deliver an image and that worked. But the live project 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 that had a little bit of a curated data and information. And delivering this product was a defining moment for me where I moved from a designer to a design engineer.
SPEAKER_00
This is, of course, enabled by AI, but most of all, it was enabled by the fact that I could own the entire process. And then, of course, we were within the Radical Speed Month, I was allowed to experiment. 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 needed and I didn't have to spend a lot of time in negotiations and handover.
SPEAKER_00
And then that was two and a half weeks. So I kind of had one week left, a Radical Speed Month. So I paired with a fellow designer. And here, you'll be able to see the incredible shift in speed and process that happened. In only six days, we went from zero to through the entire process to building an iOS chat for WooCommerce merchants that allows them to answer shoppers in real time, reply from their phone, or even set up AI to answer the questions for them. And this is a fully working proof of concept that includes authentication through WordPress.com, includes a Jetpack connection. If you use WordPress, you might know what that is.
SPEAKER_00
We also built a widget that inherits the site theming, where the site visitors can actually ask the questions, as well as 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 not.
SPEAKER_00
What was important here was that the alignment and the ideation part was fairly easy. It was fairly easy for us two designers to align and shape the features because we always have the users in mind. And on the process side, 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 noticed that that significantly sped up collaboration, as well as build later. And I've continued this practice in my daily work. The main artifact we worked on here as well was the prototype.
SPEAKER_00
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 we had a very good plan. Then we built 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.
SPEAKER_00
And this is a skill that I believe will be crucial as more and more people in other roles start working in code. The second one moved me from a designer to a design engineer. 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.
SPEAKER_00
And the third project that I shared was just proof that we've unlocked speed 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 larger organization, try to implement this even just at your team level. Changing processes or tools in large organizations requires shifting the human behavior behind them.
SPEAKER_00
So provide your people with the 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 and unlock the speed of the tools. And then we'll see that AI tools can bring. Thank you. Thank you.