An Introduction To Dashlane’s CTO

Hi everyone,

My name is Frédéric Rivain. I am the new VP of Engineering (CTO) at Dashlane. I am taking the opportunity to write a first Tech post on the Dashlane blog.

Even though we tweet regularly, we now also intend to publish technical articles about our practices and our experience. We’ll share our technical ideas, choices and challenges regarding the software we build and use to run Dashlane.

In this post I would like to share my experience on how to get on board when you are joining a team as a technical manager or a CTO.

There are at least 3 different sides of it: people, projects, tech.

1. As a manager, you need to get to know people first – meet with your new teammates. I like to spend 30 minutes with each person, just to introduce myself – both my past work experience, and also some of my personal life, like family and hobbies, as a way to connect – and to get an introduction from the person I am speaking to. Then, I ask 3 simple questions: rate your happiness from 1 to 5, name the thing you like best at work, name something you would like to change or improve.

Those 3 questions allow me to get a feel on overall happiness, the strengths and weaknesses of the team, and start thinking about possible short-term actions. If manageable, I suggest to do it with as many people as possible in the company. Dashlane is small enough that I may manage to meet with everybody, even though it takes a lot of time. But it is key to knowing the people, understanding what each one does, and starting to find your way around.

2. In parallel, you need to start diving into the on-going projects – understand how teams are operating. At Dashlane, we have scrum teams following the standard scrum rituals, so it is easy to just join the sprint plannings, sprint reviews and stand-ups. This is an important part of on-boarding, but you should be careful not to over-invest time on it too soon, as you can easily get sucked in fast by the day-to-day intense rhythm of projects.

3. Then, of course, you have the technical side of it. This one takes more time to grasp as you need to lift the hood and understand the engine beneath. I try to first have an overall architecture view before digging deeper, team by team, technical domain by technical domain. Also, I look into general technical practices such as code review, unit testing, continuous integration, automated functional tests, monitoring, etc.

In a way, getting on board is a bit like running an audit: you are meeting and talking to people to understand how things work, to assess strengths and weaknesses. The difference is that you won’t just have to produce a shiny report with ideas and recommendations. You will have to actually drive and implement them with the support of the team.

It is important to structure your on-boarding period, and track what you have to do. In some companies, this is very formal as you have a list of things to do in your first 30-60-90 days. But this is a process you should own yourself, adapting the possibly existing check-list into a personal task list based on your own perception.

Along my past experiences, I have tried to identify common, generic areas of subjects that you should tackle as a technical manager. I represent it as a group of bubbles or constellations of topics.
After the first days and weeks of initial on-boarding, I use this constellation to give an overview to my team.

My first big milestone during my on-boarding period is the first Engineering Meeting with the whole team, where I share my overall vision and strategy.

Below is an extract for your interest. I organize these meetings every month or so, with the intent to share information, communicate around the on-going activity across all teams, and discuss team life.

That’s it for today. Stay tuned for more Tech posts on the Dashlane Blog.