How Our Product Team Works
Disclaimer: If you’re familiar with Spotify’s team dynamic and structure, you’ll hear a lot of borrowed terminology and concepts throughout this post, and our diagrams might look eerily similar. That’s because we’re huge fans of how Spotify does things, and we believe in a lot of the same product development values they do. If you’re not familiar, check it out here.
One part of Hudl I frequently have to explain to people outside the company is the structure of our product team. Fellow developers at other companies, friends I graduated with, and plenty of people in between want to know how Hudl works — and as it turns out, there’s a lot to talk about. We’re constantly evolving and learning more about how to keep our heads on straight, and as we do, we want to get the lessons learned on the table.
Growing Pains
In January of 2011, a few years after being founded, Hudl’s product team was at around 20 people. We didn’t have to care about things like who was responsible for what or duplication of effort — all that mattered was that coaches and athletes loved our software and that we were able to move quickly on that software. We had a few distinct areas of development, but the responsibilities of those areas were great enough that important features like recruiting, highlights, and signups weren’t given enough attention. We were able to move fast, but it couldn’t last if we still wanted to deliver quality product while scaling up.
Hudl’s product team has grown significantly since then. We’ve gone from the small, 20-person team we were at the beginning of 2011 to a team of around 120 today, and we’ve experienced plenty of growing pains along the way. People began to step on each other’s toes more and more often. Deploying became a process people dreaded, because they had to wait in our deploy queue for hours. Nobody had a clear idea of who was supposed to work on what. Eventually, these pains became unmanageable and we set out to correct them with a new team structure, keeping the following questions in mind:
1. How do we ensure our team’s structure scales with our rapid growth?
2. How do we keep bureaucracy at a minimum?
3. How do we keep ourselves fast (planning, developing, testing, and releasing included)?
4. How do we afford all our features and products the attention and development time they deserve?
We transitioned to a structure that was a take on Spotify’s around two years ago, keeping autonomy and speed in mind, and we think that it’s afforded us both of those traits with no end in sight.
Squads
The most atomic unit of our product team is the squad — a cross-functional, autonomous team of five to eight. Most squads focus their attention and development time on one of the many aspects of Hudl’s product, planning new features and releases at their own pace. The location of the squad doesn’t matter — we have squads with people from four different remote locations, while others work entirely in one office. Instead of requiring them to be in one place, we use tools like Slack and Google Hangouts to keep lines of communication open between team members. We also don’t designate a product owner (like Spotify does) because we think the entire squad should act as the owner of their features and participate in user interviews, development of success metrics, and other responsibilities you might associate with that role. Each product manager is a blend of multiple roles in the agile methodology, such as a product owner and agile coach — but only to the degree that the squad needs those roles.
However, one of the concerns with having so many small squads working independently is duplication of labor. It’s easy for two squads to write similar code, and do things in similar ways, but we want to avoid a constant reinventing of the wheel. To remedy this problem, we also introduced some foundational squads whose focus is to work on internal, infrastructural projects that allow other parts of the team to use common tools to move quickly and efficiently.
Just like Spotify, we try to avoid the concept of “ownership” when it comes to a squad’s responsibilities. You can think of it as an open-source project — each one has a set of core maintainers, and external contributors that have their work approved by those maintainers. We generally center each squad around an individual microservice with its code available to everyone on the product team, which we’ve explained in a bit more detail in a separate post. This model keeps squads from blocking each other; they’re generally responsible for adding features to the app they maintain, but if they don’t have the time just yet, or you’d like to see it introduced sooner, you’re free to add the feature yourself and ask them to look it over.
Our architecture and deployment strategy allows squads to release on their own schedule with minimal impact on others. Some squads will do two-week sprints, others will do one (a few even roll with Kanban instead of sprints!) — and most of the time, releases occur during these sprints, instead of on a schedule. By the latest averages, we do roughly 90 releases a week, with many more releases per week being perfectly within reach.
Squads do things in whatever way works best for them. We encourage agile mantras around shipping and iterating on features quickly, but don’t mandate any specific practices. Nothing is sacred. If you want to try a new way of issue tracking, go for it — some squads use pure JIRA, others pure GitHub Issues, and still others use a combination. If story pointing seems appropriate for your iterations, use it. If it doesn’t, don’t! When a tool works well for a squad, we encourage them to tell the rest of the team through guilds and other updates (which will be touched on later). Other squads that take interest in one of those new tools will generally adopt it, and eventually it may become standard throughout our team.
Tribes
We’ve got around 25 squads and that number is only increasing. At some point, scaling squads without any sort of common goals to rally around becomes unscalable. That’s where tribes come in.
Tribes at Hudl align closely with distinct sections of the product: “Team Sports”, “Individual Performance”, “Community”, and “Foundation”, and can be mapped pretty closely to an organization within a company. Each tribe has a particular goal and contains a number of squads that work with that goal in mind. For instance, the Team Sports tribe works to bring value to the different team sports across the globe with squads like Football, Basketball, and Soccer delivering features to give value to each of those sports. The Foundation tribe focuses on enabling people throughout the company to work more efficiently, with squads like Infrastructure, Dev Tools, and Platform providing different tools and frameworks to do just that. These tribes can scale to many, many squads, and ensure that no matter how granular we decide to be on each one’s responsibilities, they can all still work toward common goals.
Like squads, tribes operate fairly autonomously, but their goals are closely tied to our overall company goals. We have a product director and general manager for each to make sure the goals for product and business development within the tribe are rock solid. Each tribe can also have business development, marketing, sales, and support chapters to work specifically on its part of the product — something we’ve deviated from Spotify on. We feel that, since each tribe at Hudl is so analogous to a business unit, it makes sense to include business roles in each one to make communication between technical and non-technical roles as simple as possible.
Chapters
Within a tribe (and sometimes among tribes), we find it pretty important to keep people in the same role communicating with each other, outside the context of their own squad. We use chapters to give people that line of communication, and allow the chapters to really define how that line should operate to keep things the least bureaucratic while still delivering value to everyone involved. For instance, quality analysts will meet up once every week or two, while developers meet on more of an as-requested basis.
The content of meetings varies, as well — some meetings will primarily discuss risks and ways to improve the chapter, while others will share knowledge by talking about a new technology being used on a squad, or a development practice we want to start trying. The main goal of a chapter discussion is primarily to keep the chapter learning and improving, whether it be through retrospectives, tech talks, or discussions about upcoming feature and their risks. It’s also a great place for members of the team to voice concern with role-specific processes and challenge our process as it exists today.
Guilds
Last, but certainly not least, we needed to account for those interests that span across roles, squads, and tribes. Guilds provide a way for people passionate about a certain aspect of their work to get together and discuss new developments in the field and bounce ideas off each other. People can attend public speaking guild to hone their craft at conference presentations, sit in on security guild to learn more about how we can improve our password security, or watch a talk in mobile guild about how to write great unit tests in Objective-C.
A guild can be formed by anyone, at any time. All you need to form a guild is enough interested people — most of the time, “if you build it, they will come” rings pretty true and you’ll find people passionate about the same thing you are. That’s how the current ones came to be, and it’s likely how future guilds will spin up, too.
It’s Not All Perfect
We like to think our structure solves the majority of our scaling problems, but it has its shortcomings. A few of the most recent problems we’re trying to solve are:
1. Making sure information and expertise isn’t siloed between squads
2. Making sure squads are confident enough to develop features in other squads’ apps
3. Making sure our product team structure is completely cohesive with other teams within the company, like support and sales
These problems are, of course, difficult. They rely heavily on squads and team members themselves to communicate openly, challenge themselves by staying uncomfortable, and share knowledge with other parts of the company when it’s needed. As easy as that sounds, it can be even easier to stay in the comfort of your own expertise and keep that expertise to yourself.
We’re confident we can solve these problems with our current structure, and we’ll be excited to report back when we do. Until then, feel free to ask us questions, suggest new approaches, and challenge us on our model — we’re always open to new ideas! If this kind of team sounds fun to you, we’d love for you to join us.
Edit: This article originally mentioned having eight people on Hudl’s product team at the start of 2011. It’s since been revised with a more accurate headcount.
