Follow along with Shawn Axsom (Director of Engineering) and Jean-Laurent de Morlhon (VP of Engineering) to learn how Docker has applied Team Topologies tenets to better organize and serve internal engineering teams.
Embracing New Approaches
At Docker, we’ve been developer obsessed, and have reorganized our engineering teams since 2019 to help us scale even further. 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. This vision doesn’t just encompass our Docker users, but also our own internal engineers.
Accordingly, we’ve revamped our culture and organizational structure without losing what makes us unique — moving away from siloed, product-based teams to Stream-aligned and Enabling Teams, and now to Platform Teams based on Team Topologies.
We recorded an in-depth conversation about Docker’s engineering journey with Team Topologies co-author, Matthew Skelton, to discuss our progress at DockerCon 2022. Read on to learn more about our transformation and how we’re making Docker a streamlined, more-collaborative workplace.
Rebuilding Our Culture
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.
Our engineering teams also shared plenty of feedback on internal processes. They’ve highlighted ways in which teams could work together more effectively, ship faster, and flatten the steep learning curves accompanying each product’s codebase. We’ve taken this to heart while reshaping Docker’s teams.
Let’s first discuss open communication. We’ve 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. It’s since been much easier to keep engineering teams on the same page. Additionally, this has helped form new support structures and encouraged team members to communicate — as opposed to feeling walled off.
Next, we’ve 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 have guided everyone in a persistent direction, while our roadmap has evolved quarterly to reflect changing needs.
However, we faced some early 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 that true Stream-aligned teams should have when following Team Topologies methodologies. There was definitely more room for improvement.
Reorganizing Product Development Teams for High-Scale Growth
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 this process ultimately took place.
Establishing Product-Bound Teams
Prior to adopting Team Topologies’ practices, we organized 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 geographically 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. We hire great engineers, and we aim not to manage them but to unblock them from their best work. Stream-aligned teams minimize dependencies that would delay and obstruct them.
- “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.
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 re-skilling. 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.
By introducing 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.
Join Our Docker Team
As an engineer, Team Topologies lets you tackle your development goals. You can dismiss product-related concerns and truly follow your passion — whether that’s working with other developers, customers and account management, building the Docker Desktop Extensions ecosystem and SDK, or creating tooling atop the world’s largest library and community for container images. You can wear multiple hats (if you’d like) and directly impact a number of exciting initiatives at Docker.
We’d love for you to join Docker as we enter our next phase of growth. We’ll encourage you to not only share your ideas, but implement them across key products. You’ll also be exposed to a number of new projects that are kicking off, thanks to substantial funding we’ve recently received.
Eleven teams are currently hiring on our Career Openings Page, with more opportunities coming later this year.
These include engineering roles in web and desktop development, data engineering, and engineering management. We also have open technical project management, product management, and design roles.
Want to learn more about working at Docker? Visit our Careers Page to view current openings, read about our benefits, and explore some cool perks — including Whaleness Days, just one of the ways we promote a healthy work-life balance.