Sharing The Tech Lead Role

Problem

At Doctolib, we want all of our developers to be really involved in the process of developing new features and we want all of our processes to be done in a collective way. Even when scaling our organization, we try to avoid having a lot of floors of management or having engineering managers do all of the scoping and preparation of projects.

Actions taken

"We want everybody to be involved with the process of developing new features, from beginning to end."

To achieve this, a year ago, we decided that we didn't need to have one lead developer per team. Instead, we decided to have what we call a "Tech Holder" for each project.

Using this process, if we develop a new feature our product manager will have to work out what we need but from the beginning, he will collaborate directly with one of our developers. Once we have the roadmap for the next quarter, we identify a developer for each project and they will take on a tech holder role. The developers will act as Tech Leaders but just for a single project for two weeks.

We made it a point that developers from every level could act as Tech Holders. It's not easy for everybody and it can be quite tough for junior developers and developers who aren't used to leading others. However, this process has really helped the developers to grow and develop.

For a while, my role became coaching other developers in that role, rather than ruling over the team. This has created a great situation for people to learn. As a manager, I was able to help them a lot because we have created a situation where everyone works together to improve over time. Some projects were harder than others and sometimes people failed at being Tech Holders, but this tended to be because a project was harder than expected and these situations provided team learning opportunities.

A few months ago, we held a big retrospective meeting focused solely on the Tech Holder role and how we can improve the experience. While some feedback came back about how it hadn't worked in a specific situation or that there were a few pain points, overall the feedback was great and the retrospective allowed us to adapt the process in order to improve it.

Lessons learned

"You should always seek to find ways to involve developers from the beginning to the very end of developing new features."

We now use this process all the time. Involving people in this way and getting them involved directly with the product side of development has made our developers much more attentive to their work. They focus more on the quality of the product and of the code they write, and the team collaborates much more effectively.