Stepping into the Role of Tech Holder

Problem

First of all, in many companies it can be very frustrating to have a developer who, in seeing that a feature is not designed in a way that properly addresses the customer's needs, thinks, "I don't care, it's not my job..." or "It's the design team's mock-up, I can't change it". Or even worse, a developer who hasn't been properly informed and doesn't understand why the team is working on a feature in the first place. The second issue is commonly seen in organizations where the design of a solution is created by a single lead/senior-dev or architect. They are the expert, they will do the technical scoping, will find the solution, estimate the time required to do it, and then, in the end, they will hand off the coding to "junior developers". The combination of these two issues can culminate in developers coding in an attempt to tackle issues they don't understand, using solutions they haven't come up with, and facing deadlines they haven't chosen. This inevitably can lead to a certain level of detachment and a lack of personal responsibility within the project.

Actions taken

• We created the role of "tech holder" as a turning point for us in how we run our projects. With a roadmap of two to three months that runs a couple of projects at a time, for each project we will appoint someone as the tech holder for that specific topic who will work closely with the product owner from kick-off to delivery.
• On one project you may have a tech lead, but that person may change every quarter. This means that every developer at some point will be a tech holder. While the engineering manager oversees the individuals on the team by dealing with one on ones, setting career goals, etc, the tech holder is in charge of managing the project. The tech holder attends product workshops before the project launch and attempts to come up with outside-of-the-box ideas that respect our coding principles of performance, quality, and maintainability.
• The tech holder works in three big phases - before, during, and after development. Before development, they prepare and scope the project. During development, they are meant to deliver the project smoothly and after development they see through its release and share.
• Some of the tech holder tools being used during the projects are as follows:
• Tech holder checklist, where either the product owner or the tech holder runs through the list to see if the project is shifting or on track.
• Design document that evolves from the beginning to the end of a project. The tech holder uses it at first as their notebook. In the month leading up to development, it then becomes their support tool to present their solutions to the rest of the technical team. Finally, it is used as the technical documentation of the project after its release.
• Finding the right level of detail, meaning that the tech holder comes up with the solution V0.1 and then clarifies the needs while thinking of a simple implementation. In the end, we are weary if the tech holder's first solution is the one that is used. It is more important that the team can build on and improve upon this initial idea together.
• Project timeline, a tech holder's responsibility to draw a timeline next to the classic board and give their team an overall update during every daily stand-up meeting.

Lessons learned

• Our approach is unusual and not commonly seen in other companies, but is working extremely well for us as a cornerstone of our organization. Developers love it because they have a lot of responsibilities when they are the tech holder. They generally become really involved in the project management aspect of why we are doing this project. Our advice to you, knowing very well that your processes may not align directly with this approach, is to start small and iterate.
• The good thing about having a tech holder is that we want to empower everybody, especially the new engineers, to learn and know the different steps of the project.
• Our biggest value in the tech team is that the user comes first. We want developers who are not doing technology solely for the sake of technology. The most important for us is that the user remains first. We can not have a genius tech guy if he does not want to serve some end-user. This is not an interesting type of engineer for us. Due to this, our engineers get very excited when they are afforded the opportunity to be close to the field, to go in hospitals and doctor's offices to see how the product is being used, the issues it has, and then proceed with the design of its solution. It's a really good way for developers to enlarge their vision. It's not just about coding a specification when you have it. When you are a tech holder you have to be with it from concept to cash, or in other words, seeing it from the beginning to the end in terms of how the features are being used.
• The tech holder is never the sole developer on the project; they are bound to fail if this is the case. Nor is the tech holder an engineering manager. They are also not to be confused with that of a product owner, although the role does involve challenging the product owner.
• Beginning small, the checklist evolved over time; items were added and removed as seen fit after each success/failure. However, one of the problems we still see today is that newcomers at Doctolib tend to follow the checklist without necessarily reflecting upon or comprehending the rationale behind each listed step. It is because of this that we made it the responsibility of the engineering managers to coach everyone to make sure it will be used wisely and not blindly.
• We no longer use Burn-down Charts or Cumulative Flow diagrams because neither work as well as our timeline; we find it a better tool than the classic board to help the tech holder visualize the project delivery.