Drivy is a company which lets its users to rent one of of cars available in their area.
- Founded: 2010 by Paulin Dementhon
- City: Paris, France
- Funding: 43.3M$
- Company size at time of writing: 90
- Tech team: 13 (CTO, 3 mobile developers, 1 data, 2 backend, the rest fullstack)
What’s on your pizza?
Tartufo: mozzarella, mushrooms and truffle oil at Pupetta
So, Director of Engineering?
We reorganized the team in squads following the Spotify model
Who are you?
I started coding early, and went to an engineering school. I then worked for big companies, which I didn’t like much. I moved to the US for about 2 years where I worked in startups and agencies, before coming back to Paris in 2009.
Since being back, I worked for 2 startups : the first one (Tigerlily) went down, and the second one is Drivy!
During my free time I help new teams launch or scale their startup. Depending on the period, I also give some classes at schools like HEC or HETIC, and I also have a Ruby class and a Git class on OpenClassRooms.
How did you join Drivy?
I saw that they worked with Rails and that they were creating an interesting project. The company was in the perfect stage for me: quite small, but already with a team, a nice looking product and people using it.
There was a good fit from the start, the product had a huge potential as it could have a real societal impact, changing the way people view car ownership. It was basically a great company, with enough funding to achieve their ambitions, so I was sold quickly and became the lead backend developer.
And now, what is your current job?
I still code a bit, a lot less than before (not much time). My role is to staff the team well, and make sure everybody works in the best conditions — for example we reorganized the team in squads following the Spotify model, and that worked out very well.
I also participate in all tech choices, working a lot with the product teams.
So I take it your job has changed since you started?
Of course, as I joined as a developer. I switched to director of engineering around August 2016. The CTO became CPO, as the team was too big to keep managing both at the same time!
Tech at Drivy
It used to be hard to manage TV appearances but we don’t even see them put pressure on the architecture anymore
What is your stack?
Mostly Ruby on Rails on the backend, and Yarn, Webpack and a lot of ES6 on the frontend. SWIFT/Java for the mobile part, and we are hosted on Heroku, with some database and redis parts being on Amazon.
We have an important data stack as well: R, Redshift, Redash, Airflow, Superset, etc.
Have you had to change it since it all started?
Drivy started without a tech founder, so the first few iterations were built by an agency in Symfony 1. They did quite a good job in the end, but migrating to Symfony 2 would have been as big of a migration as migrating to anything else.
So we decided to go for Ruby on Rails, which had an already interesting ecosystem. We after that added ES6, Webpack, etc to make things smoother in the front-end.
Have you ever faced a crisis?
We don’t have a lot of bugs in prod anymore, because we invest a lot in automated testing. It used to be hard to manage TV appearances (we tend to attract media attention), but now we don’t even see them put pressure on the architecture.
We tackled the problems bottleneck by bottleneck, and now the entire system is very robust.
The Director of Engineering life
Drivy is the sum of lessons learned sometimes through mistakes
What’s your hardest problem, right now?
Hiring the right people, which is the one thing that makes everything else simpler. The other challenge is to make sure that we scale the tech architecture correctly, as well as the team.
So we don’t have a real “problem”, we just have mandatory hard things to do.
What’s your most important responsibility?
Making sure everything works the way it should for the users, the team and the business.
Team onboarding is a huge thing as well: making sure it’s not too slow nor too fast. And also making sure the product ships at a good rythm without burning out the team.
Would you change anything you did?
There’s a lot of tiny details, tiny problems that we could have solved faster. But we’re a company that works with agility, and we’re always ready to switch direction.
Drivy works well now, but it’s the sum of lessons learned sometimes through mistakes. We wouldn’t be there without them, so no, I wouldn’t change anything.
Everybody cares to listen what the others have to say, and we don’t have a “know-it-all cowboy”
Describe your tech team in a few words
Amazing, curious, and involved. Everybody wants to do well, everybody works for the same purpose, which is great. Nobody kills themselves at work either, which makes it a very sane environment to be in.
We have different personalities in the team, which gives a real dynamic to the group. Everybody cares to listen what the others have to say, and we don’t have a “know-it-all cowboy”. The team spirit is prevalent.
What’s the main thing you look at during a hiring process?
The most interesting part is to interact with the person: is there a good feeling? Can this person teach me something? Does this person understand the real problem behind my apparently genuine question? Are they generating ideas, or just following what we’re asking them to do?
One thing that I strictly follow is what some call the no asshole policy. Quite self explanatory.
Any hiring tip for our fellow CTOs?
Don’t underestimate the time it takes to hire someone. One of the best signs of an interview is that it takes longer than expected, and the team keeps asking questions way after the scheduled time is over.
Let’s project ourselves a bit
We went from being a tiny startup to needing to rent an entire bus to go on a company weekend trip
Where do you see Drivy in two years?
A better product, better integrated with the cars themselves. We’re in five countries for now, we’ll be in a lot more.
So basically everything in better!
Any problems you can see arriving soon?
We definitely have risks linked to the growth of the company. In 4.5 years, we went from being a tiny startup to needing to rent an entire bus to go on a company weekend trip.
There’s a lot of things that used to work when the company was small and that don’t when you grow, and you need to adapt to them. The hard part is to make sure you realize your mistakes and correct them quickly.
Article written by Alban Dumouilla and originally published on CTO.Pizza