Iterating on the Dashlane Product & Engineering Organization
Two years ago, I shared a blog post that described the Dashlane journey to adapt our Product and Engineering organization to fit the constant evolution of our business needs.
Let me tell you the next part of the story and how we kept adjusting our structure during the two next cycles of our company life:
- First cycle: When we came out of the COVID-19 pandemic, the business was expanding. We restarted a strong phase of team growth, hiring globally.
- Most recent cycle: With the economic downturn, our focus shifted towards resiliency and efficiency.
But before I jump into it, let me give you a summary of past episodes. By 2021, we were operating with what we called the Triple Track, which was three constructs of teams that ran in parallel:
- Core Teams were the owners of our various Dashlane features. They represented around 60% of our Product and Engineering teams.
- Mission Teams were time-boxed, objective, or project-driven and helped us address specific goals. At that stage, they represented ~10% of our teams and were created ad hoc.
- Platform Squads were the last 30+%, representing our permanent technical investment for maintaining healthy web, server, and mobile platforms.
Scaling the model
As the team grew, we had around 20 to 25 teams with a mix of Core Teams, Mission Teams, and Platform Teams, all without proper coordination and structure to align them on shared goals. Delivery was inconsistent. Staffing of people between teams was often very complicated. Team leadership was diluted between different people (engineering manager, product manager, scrum master, tech lead, and so on).
In 2022, it was time to iterate again and ensure the model could scale.
We decided to group teams serving the same product area into Pods, which is essentially a cluster of teams in which feature ownership, goals, roadmaps, and staffing can be driven and coordinated more consistently. Pods belong to a Domain, which is the structure ensuring the connection to the big picture and the company strategy.
One important concept of that Domain > Pod > Team framework was to also reinforce a leadership duo between product and engineering, at each level, accountable for the delivery and success of the organization.
In 2022, we started with three Domains:
- Growth: Focused on growing our customer funnel. Very connected to our business stakeholders in Marketing and Sales.
- Delight: Ensured the best customer experience and owned the core features of our product.
- Foundations: Supported all platforms to deliver more efficiently.
That provided a clear, easy-to-read organization with the ability to scale up and down in a flexible way: You could just add teams to pods and pods to domains, depending on needs.
On the other hand, staffing challenges were still there, even if they were easier to handle. Also, we had to pay attention to the coordination and communication overhead to avoid duplication of efforts at the different levels.
From growth to efficiency
As the economic environment started to change in 2022, our focus, like a lot of companies’, changed. It was no longer about growing the business quickly, but about making sure we had an enduring business. It was a hard but healthy shift toward more efficiency.
To ensure stronger focus on delivery, we decided to evolve the management structure. We used to have engineering managers focused around one single platform, based on a technical stack. For instance, a “Web” Engineering Manager or “Android” Engineering Manager. Those managers had reports working on various teams.
We transitioned to a cross-platform management model, where Engineering Managers are leading a specific team, and all engineers in that team are reporting to them, regardless of their technical platform. This allowed us to align the management lines with the team structure and reinforce accountability around delivery and team performance.
On the flipside, it reduced the technical focus of Engineering Managers.
To ensure we wouldn’t lose strong platform identity and technical communities, we introduced the notion of guilds: A community of engineers interested in a technical stack and ecosystem. We created different guilds, such as the Apple Guild, the Android Guild, the Web Guild, and the Server Guild. Those communities meet regularly to discuss the vision and strategy for the stack, share practices, and improve technical processes. They’re supported by the platform teams associated with the guilds.
One learning we had along the way is that we had too few Apple and Android developers to really have them distributed across teams, so we ended up moving them back into centralized teams that serve all domains and are both guild and team at the same time.
Stay tuned for the next evolution
That’s where we are today. Those weren’t easy transitions. That level of change was often hard for people as we had to manage change fatigue and learn to operate within the new structure of the organization.
Our Domain > Pod > Team structure allowed us to scale down in a flexible way across 2023 while we reorganized teams. As a result, we have removed the Pods layer for now, which might have been a premature optimization.
Our main focus these days is to optimize our ways of working in that model. A few examples:
- We’ve been actively using DORA metrics to inform how to achieve higher operational excellence.
- We’ve reinforced the importance for teams to work in small increments and deliver value often.
- We’ve consolidated a lot of our execution work in GitLab to have more automation, visibility, and consistency.
If you want more details about the history of the Dashlane Product & Engineering organization, here’s a deck I’ve used in conferences.
Sign up to receive news and updates about Dashlane
