When to split your team into squads
Here at Ritual, we’ve recently split into two separate squads on our Digital Product team, and it’s going pretty well so far. We’re still only a few weeks into the new structure, and we’re quickly identifying and ironing out any kinks in the process, but I’d like to take a moment to share our path toward squads, how we’ve structured them, and how we’ve slowly rolled into the new structure.
Ritual’s digital product team started almost three years ago, with the first Head of Product hire, and myself (as Engineering Lead) and our Data and Analytics Lead starting shortly after. At the time, Ritual had just announced a $10.5 million round of Series A financing, and our debut product, Essential for Women, was just about to celebrate its 1st anniversary. Our company’s founding team had proven success with product-market fit while keeping overall complexity low. Our value proposition of creating products that provide clean, traceable ingredients in a multivitamin, paired with an easy-to-manage monthly subscription was not only new to the multivitamin industry, but it made the business model extremely simple. The company could (and did) use a simple off-the-shelf subscription service, connected to the website, and enable customers to subscribe to the multivitamin easily. The simplicity of the whole solution was immensely appealing to me as a potential hire, while also providing foundational elements that could be built upon, as Ritual would launch more subscription products and deepen its relationship with customers. Upon joining, I immediately started building out our team: hiring three excellent software engineers, and hitting the ground running on evaluating what our technology solution would be that could facilitate the basics of a subscription eCommerce platform. This solution would allow us to build upon it as our business would continue to grow.
Fast forward to late 2019 (1.5 years later)
What was once four engineers has now grown strategically into ten, including two on QA, and one leading DevOps. We’ve also added product managers and digital experience designers, and the company has grown from the 15 employees when I joined, to over 70. As we’ve grown, so have the challenges and opportunities presented to us. We’re no longer focused on 1 product, but 3 (and soon more!). We’ve brought all of our web development in-house, building new features into our core eCommerce platform, enabling customers to subscribe to our products and ship them monthly, and rebuilt our marketing site at Ritual.com using the popular JAMstack principles. Since launching into our tech stack, we’ve experimented with new ways to communicate the value of our products and our brand, and added new features and functionality to better support our subscribers’ experience. With each unique insight and idea, we add to our backlog of work and prioritize efforts accordingly. Overall though, we’re a lean team striving to make the most substantial impact for our customers’ experiences surrounding their interactions with our products and our brand.
Almost naturally, as we started to build more changes on our site and in our infrastructure, we fell into the two camps of back-end and front-end web development — the back-end team working on integrations with our payments and shipping partners, and the front-end team focusing on updates to our site to communicate the value in our products. From here, we started to look forward to our digital product initiatives, and we found that we kept falling into these two camps — front-end and back-end, or sometimes front-end and back-end with a little bit of front-end/full-stack support. Either way, we were self-dividing our team’s resources into the initiatives we were excited for them to work on.
Then, we noticed something. Many of the projects we wanted to take on didn’t really fall into the front-end/back-end disciplines. They were all aligned with broader initiatives for the company — with some focused on attracting and acquiring new customers, and others focused on functionality that would strengthen our eCommerce capabilities. On the one hand, this looked like experimenting with new product detail pages and launching our Clinical Trial results for our first product. On the other, we’re building payment and subscription features that enable the sale of future products. These two streams of work started to become more evident to us and began to garner backlogs of work on their own. This was when we realized; it’s time to switch our structure into squads — the first being “Growth,” the other being “Platform.”
It may not be obvious to most teams that these things take time and team growth (we had delayed splitting into squads for over a year). In our case, we made an early decision to consider squads, but not to jump too readily into them; instead, to evaluate our team structure frequently and objectively, and to plan our migration into a new structure when that time came. We waited, and we found a natural progression that has, overall, helped us focus on the initiatives that we should be focused on. Committing to evaluate and re-evaluate team structure has been the key to our ability to recognize the need to make this change. It’s helped us justify our approach to changing the structure when we were ready to, and it’s provided structure to what could otherwise be thrown together. Our squads are setup with a full-stack engineer, and a dedicated technical lead and product manager, while other teams like QA, DevOps, and Digital Experience Design (XD) support on a project-basis.
Additionally, this structure has given us the opportunity to start to stretch into what Spotify (the modern innovator on squads) calls “Chapters” — establishing opportunities for collaboration across front-end or back-end engineers who sit on separate squads. (ie. Just because you’re on a squad doesn’t mean you’re siloed in conversation; what changes is the topic of conversation with fellow engineers.)
Since splitting into squads, we’ve also split many of our normal team processes, to focus conversations within each squad. The squads have their own daily standup, sprint planning, and sprint retrospective meetings, each staggered in times, as others may need to join both squads, depending on the projects in motion. They also have their own backlogs and roadmaps, represented in Jira, separate Slack channels (#team_growth_squad, #team_platform_squad), separate Slack user groups (@growth_squad, @platform_squad), and separate GitHub teams. Establishing these clear lines of communication and collaboration within squads helps keep teams focused, while broader channels allow for cross-squad conversations and visibility.
We’re still growing and learning — as we keep iterating on our new squads, we’ll continue to share our insights as a young (but fast!) growing company.
