The Dashlane Triple Track – Looking for the right organization

Today, I want to share the story of how we've evolved our organization over time. I hope you can learn from our success and our mistakes and get a bit of inspiration. 

The Dashlane story is a series of iterative steps. As we grew, we adapted our organizational structure to meet our changing needs. The key for us was to practice agility at the organizational level: always change and adapt to the needs of the business, while trying to improve ourselves, and solve our pain points. Similar to many early-stage startups, in our "garage days," we started out using Scrum as described in the Scrum Guide. We introduced various tools such as Portfolio & Roadmaps. We started setting goals with OKRs back in 2016. Perhaps the most significant change came in 2017 when we switched to a feature team model, which we have been iterating upon ever since. I will explain how and why we started off with a single track of work with a business-goal focus, and why we progressively introduced a second track for technical work, and eventually a third track with an actual feature focus. In 2021 we've invested significant time in improving our Feature Development Cycle (or FDC in short) with an aim at increased consistency and efficiency of practices across teams.

As you can imagine, those changes were timed with the growth of our business and our team, as well as triggered by the challenges and friction the team was facing. For instance, the Dashlane engineering team doubled in size in a bit more than a year around 2019, from 50 to 100. That gave us both opportunities to adapt the organization, but also generated substantial growing pains. It all boils down to finding what the right organization is at the right moment; the one that provides us with maximum efficiency and maximum value for our customers and our business. While at first, searching for the perfect organizational structure can feel like playing "Where's Waldo?," over a few iterations you end up finding the perfect setup for your team.

One side of the story is how to make sure we generate maximum value. How do we avoid doing half-baked agility and instead aim for full-stack agility?

An organization isn't merely groups of people working on projects; there are multiple layers in which we do business agility. On the most basic level, we have operations, "where the work gets done" and tasks turn into outputs. As we move upwards on our organizational pyramid, we consider the tactics we use to be more efficient and the strategies we use to set goals for ourselves and push the business forward. Finally, at the top of the pyramid, we have culture, which is effectively a distillation of what it's like to work someplace, based on values and principles.

Let’s go back in time.

It all started when we had our first developers. We hired our first iOS engineer, and he started coding the Dashlane iOS app, and in time an iOS team formed around him. At first we had platform teams: iOS, Android, Web… This worked well for small teams, with one clear stakeholder or line of business.

As Dashlane grew, this platform team structure began to make things complicated. We had synchronization issues between teams, too many stakeholders, and inconsistencies in the product. Imagine you are a team that has projects that are driven by consumer-facing marketing, coming from business-facing Sales, and meanwhile customer support is requesting more self-serve features in the product. This is very hard to manage across the board. And even though teams were built around a tech stack, we were struggling to allocate enough time for technical investment. As you have probably experienced, technical work always got deprioritized under business pressure to produce more features.

At some point, we switched to some variant of a feature team model. We had cross-functional teams focused on part of our business scope. We aimed at giving those teams full ownership and ability to deliver on that scope. We had teams related to our B2C funnel: acquisition, conversion and retention. Other teams focused on our B2B offering, and so on. The reason why we decided on a Business scope and not on a Feature scope for those teams was that we wanted to get business stakeholders closer to the development teams. So at the time, attached to each team, we had a designated Business Stakeholder. For instance, our Head of Paid Marketing was attached to the Acquisition team, while our Finance director was attached to the Conversion team.

And we iterated again. One of the drawbacks of teams built around business scopes is that their remit became very broad. We had a hard time focusing and building roadmaps with clear objectives. It was also a period of time when we were still looking for product-market fit and experimenting with many different ideas, so we needed flexibility. So we tuned the model and started using Mission Teams instead.

To understand the difference with the previous model, as you can see on the diagram below, we used to have a Retention team, but this is super vague. You can do big projects, or many small optimizations, without ever really making an impact on the company's overall retention. On the other hand, we did not want to have project teams, where you are just building feature X. So Mission teams were our compromise. Mission Teams were spawned to deliver against one clear objective. It still gave teams a lot of room for creativity and autonomy but at least we had more focus and alignment on the target. In that model, each Mission Team is comprised of representatives from the various technical platforms, depending on the needs of the team, but on the other hand we still have the notion of a community of developers around a platform. For instance, all the Android developers. In Mission Teams, we also have representatives from business functions: someone from Customer support, from Product Marketing, and so on, and whenever we needed a clear stakeholder from business, they were looped in as well. 

Where business teams were long-lived and stable, they lacked a clear scope. Missions teams honed in on a more tangible set of goals, but tended to be more short-lived, depending on the company's changing needs.

One pain point is that we were still making half-baked technical investments. Because we did not have a sustained and permanent effort, some platforms were lagging behind, with technical debt and immature development practices. In time, we experimented with many different approaches. We tried to allocate 10% of sprint time to tech but that never really worked. We dedicated 2 specific days of the sprint for platform engineers to come back together and contribute to technical topics. We even tried dedicating one week out of three for technical focus. I can tell you, none of them worked perfectly. However, because we had cut time explicitly out of the sprint, we did not have to fight for technical topics in the middle of a product backlog. Also, it was good for developers of the same platform to be back together working on shared topics. However, it resulted in constant context switching. It was hard to work on long term technical projects, since the time dedicated to them was incredibly piecemeal. And at the end of the day, there was a tendency for both sets of commitments to overflow. Mission work would happen during platform time and vice versa.

In the middle of 2019, we decided to split.

We created two distinct tracks:

25% may seem like a lot, but is in fact the minimum required in our context. We have learned in that time that whenever we reduce that capacity, we start lagging behind and the whole organization suffers.

An important point to note is the need for team member rotation. To ensure engineers are exposed to various parts of the code base and to provide diversity of work, we organize a slow rotation of engineers between mission teams and platform squads.

Platform squads are quite similar to mission teams. They operate on a two-week cycle which culminates in a review. Their Product Owner is actually an engineer, as opposed to a Product Manager. Their scope of work includes everything that is required to keep the engine running: from production monitoring to release management, to frameworks, tools, and refactors. Things like making sure the iOS app is compatible with the latest iOS version. etc. We define a yearly Platform Strategy aligned with the yearly Strategy for Engineering, and from there we derive quarterly technical roadmaps. Because this represents a significant investment of our people, that strategy as well as the quarterly roadmaps are presented and reviewed by the Exec Team. Each quarter, we evaluate the performance of both platforms and mission teams based on the expected deliverables we mapped out in our product and engineering roadmap.

As our business matured and we had clear areas of investment, we needed less flexibility while on the other hand we were struggling with not enough ownership and quality on our feature set. Once Mission Teams had dissolved, the maintenance for the features they built ended up on the Platform Squads, which proved to be way too much work on top of their existing scope of technical maintenance. We looked for a solution to solve that pain point and yet again adapted the organization to our new needs. We wanted a stronger, more long-term effort on the whole feature scope of Dashlane. We introduced a new construct in our organization, called Core Teams.

The main difference compared to Mission Teams is that Core Teams own a specific 'feature set.' Core Teams are long-lived, cross-functional and responsible for the maintenance and the quality of their feature set. In addition, they of course work on new features and solutions within their 'Core Areas.’ In that model, it is also easier for the rest of the organization to understand who they should turn to for their issues and needs. If you are a B2B Sales person, you turn to the « IT Admin » core team. 

With the addition of Core Teams, we now have three types of teams that operate in parallel:

With three different types of teams, how do we make sure there is alignment and synchronization overall?

That’s the Dashlane story so far. If you want to know more, take a look at those slides from one of my talks on the topic.

Looking forward to the next iteration to our organization.

Frederic Rivain

Frederic Rivain has been Dashlane’s passionate Chief Technology Officer since 2015. He is eager to learn, innovate, and have fun with the engineering team to ensure it efficiently supports Dashlane and offers the best service to all Dashlane users.

Read more