Dashlane Triple Track
•Descargar como PPTX, PDF•
0 recomendaciones•2,106 vistas
We build a Password Manager, to help consumers and businesses manage their digital identity in a safe and user-friendly way. The story of agile practices at Dashlane is a series of iterative steps. As we grew as a company, we adapted our organization to our needs. We tried to learn from our past mistakes, and we did a lot and matured along the way. We are actually always looking for the right organization at the right moment, the one that provides us for the maximum efficiency and the maximum value for our customers and our business.
Recomendados
Más contenido relacionado
La actualidad más candente
La actualidad más candente (20)
Similar a Dashlane Triple Track
Similar a Dashlane Triple Track (20)
Más de Dashlane
Último
Último (20)
Dashlane Triple Track
- 2. Copyright Dashlane 2 We build a Password Manager to help you
- 3. Copyright Dashlane 3 Founded in 2009 by Bernard Liautaud and 3 French students from Ecole Centrale ~250 employees in Paris, Lisbon and New York Consumer product (B2C) + Enterprise offer (B2B) ~15 “product & engineering” teams 100+ Engineering Team
- 4. Copyright Dashlane 4 • Iterative evolution. • Learning as we grow. • Adapting to our needs and scale. • Various states of maturity. Garage Mode Move to Agile. Scrum by the Book Portfolio & OKR Feature / Business Teams Mission Teams Dual Track Triple Track FDC ?
- 6. Copyright Dashlane 6 * As quoted from Felipe Castro
- 7. Copyright Dashlane 7 Operations Tactics Strategy Culture Agile Development Scrum, Kanban, … Lean Goals / OKR 1 2 3 4
- 8. Copyright Dashlane 8 • Originally, platform tech teams: - Desktop, iOS, Android, Web, Server, Semantic Engine • Works well for small teams. With one line of business. • Starts hurting as you grow the team and as you diversify: - Synchronization issues between platforms - Inconsistency in product • Technical investment and Business work mixed within platform teams
- 9. Copyright Dashlane 9 • Inspired by the Feature Teams model (a la Spotify) • Cross-functional teams including: Product, Development, QA + Design, Analytics, Product Marketing, User Support • « Mini Startup » inside the company, with end-to-end responsibility on their scope. • Business focus - Acquisition - Conversion - Retention - 2 focused on B2B - 1 for Partnerships - 1 for our semantic engine
- 10. Copyright Dashlane 10 Mission Teams Too many ideas, no filtering lens for Product No clear sense of when to stop and do something else Lagging indicator-focused Lots of room for creativity within a boundary Success is clear Leading and lagging indicators No room for ideas Success is delivery not results Leading indicator-focused
- 11. Copyright Dashlane 11 • Cross-platform teams, with dedicated resources and skills, based on Missions • Small teams of 1 Product Manager, 2 to 6 engineers, 1 UX designer, 1 QA. • A double organization: 1. Mission Teams 2. « Platforms » communities of practice PLATFORMS Mission Team 1 Mission Team 2 Mission Team 3 … Mission Team N Product Manager x x x x Scrum Master x x x x QA x x x x Server x x iOS x xx Android x xx Windows x xx Web x xxx UX Design x x x x Analytics x x x x User Support x x x x
- 13. Copyright Dashlane 13 • Testing different approaches for technical investment • 10 % of the sprint • First 2 days each sprint (20%) • 1 week after each sprint (33%) • Platform communities come back together to work on their platform
- 14. Copyright Dashlane 14 • Easier prioritization • Help tightening the platform communities • Constant context switching • Difficult to work on long term technical projects • Both ways overflow
- 15. Copyright Dashlane 15 Platform Minimum of 25% of total platform resource allocation Team member rotation Missio n Team Product Product Tech Business Design TEAM MEMBER ROTATION 25% MIN
- 16. Copyright Dashlane 16 • Platform Squads are similar to normal mission teams • High autonomy regarding the team processes: sprints, kanban • Bi-weekly reviews • The product owner is a Tech Lead • They are in charge of: - production monitoring - release coordination - refactors, optimizations, platform bug-fixing... - Tooling and cross-platform tech projects - communication points for the rest of the organization (User Support, Marketing,...) - Team Captain role
- 17. Copyright Dashlane 17 • Aligned to a yearly Engineering Strategy and OKRs • Quarterly technical roadmaps - Built by the teams - Must contain technical OKRs - Presented to the executive team • Evaluate for impact
- 19. Copyright Dashlane 19 • Long-living (1+ year of existence). • Cross-functional staffing • Own a Core Area of the Dashlane feature set • Responsible for the quality of their feature area (bug-fixing, performance,…) • Deliver new features and solutions in that area. They define customer goals and metrics they want to achieve. Core Areas IT Admin Sharing & Collaboration Autofill Engine & Experience Auth & Sync Protect the User Growth Ops Monetization
- 20. Copyright Dashlane 20 Product Tech Business Design TEAM MEMBER ROTATION 25% MIN
- 21. Copyright Dashlane 21 Company OKR Team OKR Team Roadmap Team Delivery Plan Sprint Reviews - biweekly Planning Sync - monthly Quarterly Rodeo Meeting - quarterly Town Hall Demos - weekly Internal Dog Fooding - continuously
- 23. Copyright Dashlane 23 • Clearer, more focused organization • Permanent maintenance and investments • On our functional scope • To support technical needs • Stronger team ownership • Need to be a certain team size • Risk of under-staffing (remains a staffing challenge). Avoid spreading yourself too thin • Tendency of silo. So important to rotate people.
- 24. Copyright Dashlane 24 1. Find the right mix between tech and business 2. Focus and avoid context-switching 3. Experiment all the time with your organization. Aim for learning. 4. Assess for impact, not for delivery.
- 25. Copyright © 2020 Dashlane
Notas del editor
- Welcome ! Can you all hear me well?
- My name is Frédéric RIVAIN. I am the CTO of Dashlane. Who knows about Dashlane ? We build a Password Manager, to help you manage your digital identity in a safe and user-friendly way. Today, I want to share our story and how we evolved our organization in time. I hope you can learn from our success and our mistakes and get a bit of inspiration.
- But a bit of context first. We were founded almost 12 years ago and we have 3 offices in Paris, Lisbon and New York. Our product serves both consumers, B2C, and the enterprise world, B2B. To give you a sense of scale, we have around 15 “Product & Engineering” agile teams, supported by an Engineering Team of 100+ (all inclusive developers, QA, scrum masters, IT, security…).
- The story of agile practices at Dashlane is a series of iterative steps. As we grew as a company, we adapted our organization to our needs. We tried to learn from our past mistakes, and we did a lot and we matured along the way. 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. From the garage mode of the early days, as many startups, we started with a classic Scrum approach, pretty much by the book. We introduced various tools such as Portfolio & Roadmaps. We started practicing with OKR back in 2016. The big change came in 2017 when we switched to a feature team model, which we have been iterating upon since then. I will explain how and why we started off with a single track of work with a business-goal focus, and why we introduced progressively a second track for technical work, and eventually a third track with an actual Feature focus. This year’s focus has been a lot around 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 between end of 2018 and early 2020, from 50 to 100. That gave us both opportunities to adapt the organization, but also generated a lot of pains of growth.
- It all boils down to finding what the right organization is at the right moment, the one that provides us for the maximum efficiency and the maximum value for our customers and our business. It sometimes feel like playing « Where is Waldo? » but iterating on it you end up finding the one that works for you at a certain moment.
- One side of the story is how do we make sure we generate maximum value. How do we avoid doing half-baked agility? If you have never heard of Felipe Castro, I encourage you to google his work. He has done very interesting work around OKR.
- It is not enough to use agile project methodologies, such as Scrum or Kanban. You need to go up the pyramid and inject agile concepts at all levels: in your tactics of how you generate ideas and prioritize projects, in your strategy (this is where OKR come in), and to the top, into an agile company culture. That is the hardest, and a never-ending journey. We are still struggling ourselves, going sometimes up and sometimes down in that agile pyramid. It also means that, while most of the changes have been driven directly by Product & Engineering (and that’s one reason it is so important to partner closely between CTO and CPO), the rest of the organization is a key stakeholder, from the CEO to our business partners (Marketing, Sales, Customer Support…).
- But 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, it became very complicated. We had synchronization issues between teams, too many stakeholders, inconsistencies in the product. Imagine you are a team that has at the same times projects that are driven by B2C marketing, other coming from B2B Sales, while customer support is requesting you for 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 allocating enough time for technical investment. As you have probably experienced, technical work always came last or was deprioritized under business pressure.
- 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. It was really about giving those teams full ownership and ability to deliver on that scope. We had teams related to our B2C funnel: acquisition, conversion and retention. 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 FP&A director was attached to Conversion.
- And we iterated again. One of the drawbacks of those business scopes is that they were very broad. We had a hard time having focus and roadmaps that had clear objectives. It was also a period of time when we were still looking for product-market fit and experimenting with many different ideas, we needed flexibility. So we tuned the model and instead had Mission Teams. To understand the difference with the previous model, as you can see on the slide, 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 other hand, we did not want to have project teams, where you are just building feature X. So Mission teams were kind of 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 has representatives of the various technical platforms, depending on the need 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 needed a clear stakeholder from business. But it is more adhoc compared to our previous model.
- One pain point is that we were still doing half baked technical investment. Because we did not have a sustained and permanent effort, some platforms were lagging behind, with technical debt and immature technical practices.
- In time we experimented with many different approaches. We tried to allocate 10% of the sprint time to tech but that never really worked. We dedicated 2 specific days of the sprint for engineers of a platform to come back together and contribute to technical topics. We even tried 1 week out of 3. I can tell you, none of them worked perfectly.
- However, because we had cut time out from the sprint, prioritization was structural. 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 and work on shared topics. But on the flipside, it generated a constant context switching. It was hard to work on long term technical projects, since those times were very much sliced. And at the end of the day, there was a tendency for both to overflow. Mission work would happen during platform time and vice versa.
- Middle of 2019, we decided to split. We created 2 tracks: The Mission Teams, in charge of delivering against their business goal to produce value for our customers. We have a variety of them, either product-driven, business-driven or even at times tech-driven. A second dedicated track, which we call the Platform Squads. They are in charge of supporting the required technical investment on each ecosystem. We landed around 25% of our engineers allocated to platform efforts. They are driven by the Tech Leads. 25% may seem a lot, but it is a minimum required in our context. We have learnt in 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, on a quarterly basis.
- Platform squads are pretty similar to mission teams. They have a 2-week cycle, with reviews. Their Product Owner is actually an engineer, not a Product Manager. Their scope of work includes everything that is required to keep the engine running: from production monitoring, to release management, frameworks and tools, 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 with OKRs. 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, based on the roadmap and the objectives, we evaluate the progress of the platform squads and their impact on the business and supporting all other mission teams.
- As our business matured and we had clear areas of investment, we needed less flexibility and on the other hand we were struggling with not enough ownership and quality on our feature set. Once Mission Teams had dissolved, the maintenance ended up on the Platform Squads, and that was way too much work on top of technical maintenance. We looked for a solution to solve that pain point and yet again adapted our 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 the Core Teams. The main difference compared to Mission Teams is that Core Teams own a specific 'feature set'. And on the slide you can see the list of 'Core Areas’ that we defined for Dashlane in 2020. Core Teams are long-living, 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.
- So today we have 3 types of teams that operate in parallel. In summary: Platform Squad is our permanent technical investment allocated to maintaining our platforms in a healthy state. Core Teams is our framework to have teams owning part of our Dashlane feature set. This represents around 50 to 60% of our team. Finally, our Mission Teams are time-boxed, objective or project-driven and help us address specific goals.
- With 3 different types of teams, how do we make sure there is alignment and synchronization overall? We ensure teams are as autonomous as possible, with as few dependencies as possible to other teams. They all own and drive their own roadmap, based on their Team OKR, which cascades from Dashlane Company OKR. To be clear, the O is provided top-down as a mandate, while the team decide on their KR and Initiatives. We provide teams with a shared and consistent framework of operations, along with guidelines. This is one of the areas we have been focusing mostly in 2021 and I will share briefly in the next slide. Reporting and synchronization is done through different means at different levels: sprint reviews every 2 weeks, monthly planning sync, our Rodeo meeting which is our quarterly check in on team progress and review of plans for the next quarter, Town Hall demos…
- If you think about everything that needs to happen to deliver value to customers, whatever the project methodology you use, you have quite a lot to go through. As you scale and have more and more teams, if you want to maintain the same bar and achieve high performance of the organization, it is essential to have a common framework of operation, in writing, that can serve as a playbook for teams. That could be the subject of a whole separate talk, but is an important investment we are making at the moment.
- What are the learnings of our current organization? On the good side, we now have a clearer and more focused organization, with less context-switching. If you are in a Mission Team, you know you will be delivering against a specific goal to serve the business. If you are in Platform, you are supporting the tech stack for the whole group. If you are in Core Team, you have full ownership on a bunch of features. Thanks to Platform Squads, we make sure we maintain a permanent tech investment, and we can prioritize longer-term tech projects. While discussing with stakeholders, it is a forcing function that ensures that as an organization we always factor in the technical needs. For the whole Dashlane team, it is clear who owns what and is in support whenever there are issues and needs. On the bad side, that only works once you are at a certain team size. We could not really have implemented that organization when we were too few. Once you start having 4 engineers of the same platform, then you can essentially start having 1 dedicated to the plaform. And so the associated risk is to under-staff some teams and to be back in the mistakes of the past. As we review our team staffing every quarter, it remains an internal challenge to avoid parallelizing too much. There is always a good excuse to prioritize a new shiny business project. Last but not least, it is important not to create silos. Some engineers will prefer working on technical topics in the platfrm squad, so it is important to rotate people from time to time so they all share and participate to various teams.
- As a conclusion, here are 4 key take-aways. Obviously we are not doing tech for the sake of it, but to serve our customers and our business. You need to have the right level of technical investment so you can support your business and your team efficiently. So find the right mix for your organization. As much as you can, avoid context-switching for engineers. You lose a lot of time, of energy and efficiency, when you are multi-tasking and not focused on a single targeted goal. Having clear distinct tracks of work allowed our team to be more focused. An organization is like a product. You need to experiment, test new structures, learn and iterate. You can start small if needed, but your overall business context changes all the time, so should your organization. Learn and adapt. Finally, look not only for what was delivered but also for the impact. Whether it is a direct customer-facing impact, or an internal impact through a tech project.