Benefits of having a VTL

One of the first and most obvious benefits of a strong TL-VTL duo is the absence of a single point of failure (SPOF). The truck factor of your projects will most likely be at least 2 in this setting. Your TL and VTL can now enjoy much needed time out of the office knowing the other guy took the lead. Be it for vacation, personal, civic duty or health-related, one person can step away, knowing someone else will be there to make time off much more rewarding and relaxing and hassle-free.

Load balancing between TL and VTL is also a nice advantage. These guys can split presence in important meetings as needed, onboarding new team members or responding to incidents. While load balancing is similar to no-SPOF, they are not quite the same. Load balancing indicates the ability for TL and VTL to split work while both of them are in the office. SPOF is related to what happens when one of them is out of the office.

Another advantage of having a strong duo of leaders in an engineering team is that they can have complementing spikes. While your TL may be great at technical vision, perhaps she is not so fond of documenting it for the rookies in your team. A VTL with a more pedagogic attitude can bridge that gap. Needless to say, surround yourself with those that complement your own strengths and weaknesses.

Similarly, TL and VTL can sometimes share spikes. For example, if both of them are great at high-level design, then it is quite likely that, with the proper environment, this can spark amazing discussions and the end result will be much better than if a single one of them had come up with it. Tension in an engineering team can be a really powerful driving force for change and continuous improvement (though be careful, tension can be confused with pressure, which is not the same thing and can be more harmful than anything else).

On top of all these benefits, having a VTL will give you peace of mind when it comes to succession planning. The one thing about successful tech leads is that they’ll move on. They may grow into architects and oversee multiple teams working together, go down the management track, decide to explore new opportunities elsewhere, or perhaps even decide to start their own business. In any case, we need to make sure that, when that happens, we can just worry about celebrating and congratulating them, knowing for a fact that the team will be taken care of by the VTL, now in his/her new role as tech lead. Of course, at that point you’d need to start worrying about who steps into the VTL role —but that is a less urgent matter.

Rolling out the VTL role in your organization

“All right, all right… you convinced me, but how do I start?” Well, chances are you have VTLs in your teams already. Quite likely they emerged organically and don’t have an official title. How can you encourage this in all of your teams? Is it worth making VTL an official title? How do you encourage engineers to become VTLs? More importantly, how do you detect that a particular engineer is VTL material?

Without dodging these questions, I’m going to say that of course this heavily varies from one organization to another. In Medallia, we have VTLs in most of our teams. We don’t call them so by name and indeed they don’t have an official title, but we do value their contributions and celebrate their successes on a regular basis. As an example of this, VTLs are regarded as leaders and role models by the broader engineering organization. Furthermore, being a distributed engineering team with offices on 2 continents favors the emergence of strong TL/VTL relationships where one of them is in each office. Other teams in each location have someone local to go to for help in case they need anything about the team.

As a closing remark, most if not all of the items discussed here are not exclusive to engineering teams. In fact, other industries have long since acknowledged the importance of such positions, and that’s why we have vice presidents in countries around the world or assistant managers to help run branches or regions for big corporations. Software engineering teams seem not to be that different at least in this aspect.

Do you have a similar role in your teams? How does this work in your organization? Tell us in the comments below.