Rebuilding and scaling product development at Docker using Team Topologies
Learn how Docker applied Team Topologies methodologies while renavigating and rescaling the industry standard for containerization.
By Shawn Axsom (Director of Engineering) and Jean-Laurent de Morlhon (VP of Engineering)
We encountered siloing around products and functions, and domain knowledge was left to individuals rather than teams
Our focus on Stream-aligned teams aimed to address the primary concern plaguing Docker’s history: monetization strategy
We introduced dedicated Enabling Teams to address Security, Data, and UX Research needs
…we know that the Team Topologies approach has poised us to scale.
Shawn Axsom (Director of Engineering)
Jean-Laurent de Morlhon (VP of Engineering)
About Docker
Founded in 2010, Docker jump-started the modern container movement in app development. While we grew quickly, it became clear in 2019 that we needed to shift our strategies to become a sustainable company focused on long-term developer success. This included selling Docker Enterprise to Mirantis — a major step that helped us return to our roots.
We’ve since been developer obsessed, and have reorganized our engineering teams to help us scale. Though this effort is ongoing, it’s been successful so far. By following our developer-centric north star, we’ve grown by every measure since being a 60-person company.
We’ve also revamped our culture and organizational structure — shaping our Product Development organization around Team Topologies’ concepts. Follow along to learn how we’ve tackled this change, including what structural adaptations we’ve implemented and how this transformation has impacted Docker.
Rebuilding our culture from day one
Our November 2019 restructuring let us change how we worked. We doubled down on our core mission, developed lean processes, and re-emphasized our Docker Virtues: Developer Obsession, Humility, Bias for Considered Action, and Open Collaboration.
Open Collaboration requires proper communication channels. We established staff syncs, shared information openly during frequent company all-hands meetings (our version of town halls), and synchronized sprint cycles with company-wide demos.
We also revamped our product-management process. We moved from quarterly planning to a “rolling roadmap” — tracking company-wide projects and initiatives on a sprint-by-sprint basis. We also allowed more real-time adaptation of our priorities. Our strategy documents and OKRs guided the company and teams in a persistent direction, while our roadmap has evolved each quarter to reflect changing needs.
However, we faced some ownership challenges. We encountered siloing around products and functions, and domain knowledge was left to individuals rather than teams. Our product managers were unassigned and competing for priorities. Consequently, they lacked that cohesive focus properly formed Stream-aligned teams should have when following Team Topologies methodologies. More change was needed despite our wins.
Rebuilding our Product Development teams
After November 2019, we transformed our team structures in multiple steps:
Established Product-bound Teams (before adopting Team Topologies)
Restructured around Stream-aligned and Enabling Teams
Scaled by splitting Stream-aligned Teams and forming Platform Teams
Let’s evaluate how those steps ultimately took place.
Establishing Product-bound Teams
Prior to adopting Team Topologies practices, we focused our teams with heavy siloing around our individual products.
Our development teams in Palo Alto and the San Francisco Bay area continued to maintain Docker Hub — while we otherwise split product development amongst our Cambridge, UK, and Paris, France offices. With our new emphasis on Docker Hub, we did introduce a Docker Hub EU team. However, homogeneous development groups with little cohesion or collaboration across product boundaries remained.
Our initial rebuild was far from perfect. Product-focused teams required further subdivision as we scaled. The problem? Team Topologies emphasizes the effect Conway’s Law has on architecture, business agility, and end-users. Merely separating teams by geography avoided choosing a logical fracture plane — a key tenet of Team Topologies’ recommendations on finding good stream boundaries.
The Reverse Conway Maneuver should align teams and architectures in a manner that lowers cognitive load, minimizes dependencies, and matches product direction. Our first attempt failed to lower cognitive load. The Docker Hub US team still had to understand every part of Docker Hub equally. Product Management’s surface area also spanned Docker Hub, instead of divvying up feature set support. Any cross-product integration was minimized as both team dependencies and complexities were high.
While we made incremental changes, such as appointing dedicated product managers on teams when possible, we still needed revolutionary changes to scale better the next time around.
Restructuring around Stream-Aligned and Enabling Teams
We rolled out our initial Team Topology build in April 2020. This new structure emphasized Stream-aligned and Enabling teams:
Fracture planes were determined by horizontal product needs that fit company strategy, as well as by timezone. Product teams continued to focus on specific products and skill sets, but boundaries were no longer discrete.
We formed each Stream-aligned team with an embedded Product Manager and UX Designer.
We decided to forego Platform Teams in this phase. While Platform Teams would’ve been smart to create a solid foundation, we were resource limited. We knew that customer needs were number one, and that monetization would help us reinvest in new headcount to fuel Platform Team growth. Ultimately, we gave teams leeway to spend over 30% of their time on off-the-board items, pulling in sprint work for bugs, making architectural improvements, and reducing tech debt.
We created these teams with the following goals:
“Each team is autonomous. They have clear goals and skill sets — and are empowered to make their own decisions. They are aligned through the customer problems and their business targets that are shared in the rolling roadmap. Each Stream-aligned team has a dedicated product manager and designer alongside engineers with their unique, cross-functional skills. This is quite unusual but is important to us in making the teams truly autonomous.” Every team should be able to ship features with almost no synchronization with other Stream-aligned teams.
“All engineers should be customer-facing. We need to maintain a strong connection with creating value for our customers. We would avoid platform teams that have only internal consumers, besides Infrastructure & Data teams.”
“We aim to lower the current Cognitive Load of each team, so we own each part of the code we run.”
Our focus on Stream-aligned teams aimed to address the primary concern plaguing Docker’s history: monetization strategy. We also wanted to preserve our Developer Obsession virtue. In other words, we needed to ship user-facing features that’d be worth paying for, before worrying about scaling again.
We also created our essential Enabling Teams with core competencies that supported the product-development process — though these teams were understaffed as we tackled monetization. There were plenty of takeaways from this evolution.
Lessons Learned while implementing Stream-aligned Teams
Our initial Stream implementation succeeded at our primary objective: cognitive load.
Docker Hub’s US team wasn’t responsible for all of Hub’s infrastructure and services anymore. It was much easier to onboard engineers and to expect them to develop a more comprehensive view of their team’s services.
Thankfully, individualized knowledge silos collapsed for engineering and products. With a smaller team scope, letting multiple engineers overlap in focus across the surface area of subsections of a team’s responsibilities was possible.
Finally, we saw a renewed emphasis on product organization by going deeper into specific product concerns — given that narrower focus.
However, team boundaries are critical. Scoping a team is like scoping a project. Ideally, team scopes are also manageable and enable balanced work — while eliminating ambiguity and preventing anything from slipping through the cracks.
While rolling out our new teams, we crafted mission statements with goals, features, and service ownership in mind.
Admittedly, it would’ve been smart to immediately establish a strategy and roadmap. However, some teams formed consistent roadmaps more slowly, while others — like Accounts & Growth — often had an abundance of projects with tight timelines.
We also grappled with time constraints and reskilling. While not stemming from our initial structures, deadline pressures and a lean workforce often required us to revert to product-siloed teams. Accounts & Growth could’ve solely handled our SSO project, for example, but we borrowed Desktop resources from other teams to hit aggressive targets. We wanted to best serve our customers’ needs rather than unlocking future efficiency through autonomy.
Scaling by splitting Stream-aligned Teams and forming Platform Teams
It was finally time to scale. Given our 4x ARR growth, we were able to reinvest into Product and repay our developers with a stronger roadmap. However, this required some tweaks to our latest Team Topologies methodologies.
An inordinate number of projects continued to land on select teams. We needed to identify new fracture planes within those teams.
Now that we’d seen staggering growth, we had to ensure that infrastructure and developer productivity needs were addressed. This helped us build a resilient infrastructure and maintain high velocity.
Our new Stream-aligned teams branched mainly from preexisting teams. For example, we split the Accounts & Growth Team into Accounts, Business, Billing, and Customer Enablement Teams. While we’ve learned lessons from our prior restructuring, scaling introduces complexity and challenges that make team interactions and needs unpredictable. We reserved a buffer in our headcount to adapt to changing needs and circumstances.
With the introduction of Platform Teams, we reimagined our decision making and practices around Open Collaboration. We also rethought buy-in regarding their cross-cutting concerns. We’ve established Platform Teams with a more democratic approach to servicing their communities of practice.
We’ve also introduced dedicated Enabling Teams to address Security, Data, and UX Research needs. These operate akin to Product and Design embedded resources to start — however, we’ll explore new ways to manage the team when its needs become centralized.
A brighter, more manageable future
The road from November 2019 to now has been a long one — let alone from our historical 2013 and 2010. But, our future is bright. It’s the most promising it’s ever been since we originally received unicorn status.
We still have ambitious plans and more lessons to learn this year. We’ve created proposals that’ll change the way we operate, and that’ll allow our teams to be cohesive yet independent. Crucially, we know that the Team Topologies approach has poised us to scale.
Learn more about Docker
Website links
Social links
To learn more about key ideas from Team Topologies like the four types of teams, the platform as a product approach, or how to align teams with true value streams, have a look at our Team Topologies Academy courses and learning paths.