Back to resources

Stepping into the Role of Tech Holder

Different Skillsets
Delegate
Ownership
Motivation

17 September, 2019

Nicolas De Nayer
Nicolas De Nayer

VP Engineering at Doctolib

Nicolas De Nayer, VP of engineering at Doctolib, discusses what it means to be a tech holder and how the creation of this role has helped to build a more impactful & reliable product while making the job of developers more engaging.

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.

Discover Plato

Scale your coaching effort for your engineering and product teams
Develop yourself to become a stronger engineering / product leader


Related stories

Should You Stay Up to Date with Technical Skills As a Product Manager?

19 January

Nani Nitinavakorn, the Sr Product Owner at Revolut, describes how she keeps learning hard skills to increase motivation and respect her team.

Alignment
Innovation / Experiment
Different Skillsets
Personal Growth
Ownership
Coaching / Training / Mentorship
New PM
New Manager
Nani Nitinavakorn

Nani Nitinavakorn

Sr Product Owner at Revolut

Getting Creative to Land Your First Tech Job

19 January

Nani Nitinavakorn, the Sr Product Owner at Revolut, shares how she gained her first technical position, creating a direct method to apply for jobs.

Personal Growth
Ownership
Hiring
Strategy
Juniors
Career Path
Nani Nitinavakorn

Nani Nitinavakorn

Sr Product Owner at Revolut

Strategies to Deliver Effective Employee Feedback

18 January

Rachit Lohani, Head of Engineering at Atlassian, shares all his ideas and principles on providing feedback and avoiding discomfort while doing so.

Leadership
Internal Communication
Feedback
Motivation
Strategy
Team Processes
Rachit Lohani

Rachit Lohani

Head of Engineering at Atlassian

How to Recognize Traits of High-Performance From Candidates with Non-Traditional Backgrounds

19 January

Federico Fregosi, VP of Engineering at Contino, shares how he hired a candidate with an untraditional background and grew into a key player in the industry.

Alignment
Scaling Team
Onboarding
Ownership
Hiring
Federico Fregosi

Federico Fregosi

VP of Engineering at Contino

Understanding Career Growth: Promotion and Sideways Career Changes

19 January

Mike Bassett, Senior Director of Engineering at Electronic Arts, shares his journey through the career ladder, highlighting evaluation steps to ensure high motivation.

Personal Growth
Leadership
Motivation
Career Path
Mike Bassett

Mike Bassett

Senior Director of Engineering at Electronic Arts (EA)

You're a great engineer.
Become a great engineering leader.

Plato (platohq.com) is the world's biggest mentorship platform for engineering managers & product managers. We've curated a community of mentors who are the tech industry's best engineering & product leaders from companies like Facebook, Lyft, Slack, Airbnb, Gusto, and more.