The Tech Holder: the key to empowering engineers… about the build!
Thanks to the creation of Tech Holders we can build a more impactful & reliable product while making the job of our developers more engaging.
At Doctolib, for every project featured in the roadmap we have two key roles:
- a Product Owner
- a Tech Holder
They work closely together from kick-off through to delivery. In a previous article, we discussed how to empower developers on the run side, but today our focus is on the build.
At Doctolib, we faced certain common issues and part of the solution came in large part from the introduction of Tech Holders:
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.
What the Tech Holder is Not
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.
What the Tech Holder is
Every developer at some point will be a Tech Holder. While the Engineering Manager oversees the individuals on the team by seeing to 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 which respect our coding principles of performance, quality, and maintainability. Some examples could be:
- shortcuts and quick-wins that can make the time-to-market shorter:
“Let’s reuse this React component instead of this new screen; it will save days”
- decreasing the overall complexity:
“We can use the Elasticsearch implementation of Levenshtein instead of your complex algorithm”
- ensuring that the decisions made take into account quality, performance, and maintainability:
“Sorry Product Owner, but if you want to change this behaviour we will have to tackle some technical debt first… We’ll need two extra days”
In the end, it’s the Product Owner, keeping in mind cost, value, and data, who will make decisions if there is no consensus, but the Tech Holder must challenge them.
Three Big Phases
Before Development: Prepare and Size the Project
We never want to feel the pressure of delay in delivery, thus one of the main roles of the Tech Holder is to be held accountable for ensuring that the decision around a project’s release date is not made haphazardly; he must take the time to evaluate, minimise uncertainty, and anticipate any risks.
The Tech Holder will not have all of the answers, that’s why they rely on the whole tech team, however, it is their responsibility that we start the sprint off under the best conditions possible.
Of course, things can always go wrong and perhaps your plan A is no longer on track. This happens, and it is hardly the end of the world; under these circumstances, Tech Holder is in charge of:
- communicating transparently ASAP
- trying to come up with a plan B:
“Let’s not develop this button, it was mostly for show anyway.”
- making sure that the same issue does not happen again
“Let’s add onto the Tech Holder checklist that we must ask beforehand whether anyone will be taking time off during the project.”
During Development: Deliver the Project Smoothly
During the project, the Tech Holder is responsible for synchronizing the work of all of the engineers on a daily basis, ensuring that no one is having trouble or is unfocused, and that they are always looking ahead towards the release date. They also must always be up to date on the project, for instance being aware when specs change. Communication also plays a big role, they must notify the Product Owner as soon as possible if, for some reason, the release date needs shifting. They also will take time during retrospectives in order to discuss how the project is running and to determine what can be done for the team to improve themselves.
The TechHolder’s most useful tool is the timeline — which we review every day during the Stand Up Meeting, a subject we will come back to shortly.
After Development: Release and Share
Ready, Set, Go! Once the code is rolled out the most important part begins. The Tech Holder is in charge of checking that there has been no appearance of performance degradations or errors during production due to the new feature. It is also their job, of course, to check whether the feature is being used and being used well.
In the end we have many features; it is the Tech Holder’s responsibility to inform their peers about whatever may be important to know and what steps must be taken from a technical perspective.
This can happen during Tech Time (a bi-monthly meeting with all the engineers giving lightning talks about their learnings through success and failures) or using our Design Doc template which will be described in the next section.
Tech Holder Tools
The Tech Holder Checklist
Much has already been said about checklists and we certainly believe in their power at Doctolib so it should come as no surprise that this is our best tool for a good Tech Holder. We have created a checklist where every step is detailed and may even include subtasks or notes. The Tech Holder need only follow this process and ask for help if an item is not clear enough.
This list evolved over time. It began as a small checklist; 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.
Design Document
We use the same template for every project: a simple GDOC. It is a living 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
In the beginning, one of our early Tech Holders took the design doc too far. He spent two weeks working through every aspect of the project until all that was left to do was the coding. We noticed two problems with his approach:
- The Tech Holder was too attached to his solution and was struggling to accept feedback from his team.
- The rest of the Tech Team was not involved in the solution and, therefore, not especially committed to it.
We think that the key here is for the Tech Holder to come up with solution V0.1. They clarify the needs and think 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
For every project that we begin coding, the Tech Holder is in charge of drawing a timeline next to the classic board (to-do, work in progress, done). Multiple things can appear on it:
- days off
- hard deadlines
- stories
- dependencies
During every Daily Stand Up Meeting, the Tech Holder will give his team an overall update using the project timeline after a classic round-table discussion.
“We are late on this topic, let’s do a quick brainstorm on how to catch up.”
“Beware, you’re going to be the only developer working next week, be sure you synchronize with everybody”
“Maybe you two should pair program on this story because it is blocking the rest of the developers.”
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.
How to Become a Tech Holder?
You just have to dive right in. You’re a newcomer or a junior developer? It doesn’t matter.
Directly after your on-boarding you may choose a project which interests you and it’s very possible that you become the project’s Tech Holder. This might be scary at first, but it is the best way to learn. Plus your team, your Engineering Manager, your Product Owner will be there for you if you have any questions.
Just like with the role of Duty Guy, as you arrive at Doctolib you will be given responsibilities.
Results and Next Steps
It has almost been two years now that we have had Tech Holders at Doctolib and we have certainly seen many positive changes since then. This is particularly true in reference to team empowerment around the build. No longer is it only an Engineering Manager or a Tech Lead who cares about the advancement and success of a project. Our advice to you, knowing very well that your processes may not align directly with this approach, is to start small and iterate.
For us, the next challenge will be to define this role more clearly to our Product Owners, as recently we realized that they have been a little confused by it. For example, it’s still hard to know where to address certain questions: to the Tech Holder or the Engineering Manager? It’s a work in progress!
Finally, for us a good developer is a good Tech Holder; and a good Tech Holder is not about having the perfect solution but more about challenging the product and organizing the team during development. Being a good Tech Holder is a crucial skill if you want to advance in your career at Doctolib, because as a good Tech Holder, you have User First mindset, you understand compromise, and you are aware that while we might go faster alone we go further together.
