(Potentially) unpopular opinion: Asking “How do you define the role of tech lead?” is the wrong question. I encourage instead tech leads and other engineers to reflect about what being a technical leader actually means; the rest will follow.

So, what do you do now? I am a tech lead

Every few other months I travel back to Paris, the city that played host to my student days and the friendships I forged there. During my last visit, I crossed paths with a group of former classmates, eager to catch up on the years that had passed. Over a few rounds of drinks, multiple times over the inevitable question arose: “So, what do you do now?”. Every time I stated that I was a tech lead at Electricity Maps, I was met with the same reaction. I would only be questioned about the company as a whole and never about what being a tech lead is about.

It made me wonder — was it the ambition of Electricity Maps’ mission that captivated their interest? Was the concept of a tech lead so universally understood that it needed no further explanation? Were they actually not interested in hearing about my job?

Recollections of similar discussions I had at times when I was a data scientist suggest that the loose definition of the tech lead duties are at fault. I would then typically be asked about our tech stack, key characteristics of our data, models used and so forth.

The boundaries of the tech lead duties have been difficult to define. That was true when I was promoted to that position, after having had that responsibility unofficially for 10 months; it was still true a few months ago, after 10 months of being a tech lead officially. During that time, the team I have been leading has undergone a remarkable transformation. It has evolved from a two-engineer operation into a multi-disciplinary force capable of simultaneously delivering sophisticated new features across multiple work streams. We now are able to simultaneously leverage our domain expertise to build robust quality guarantees for the data we serve, develop novel approaches to model electricity grids dynamics, as well as improve our data processing and storing methods. Such initiatives require continuous utilisation of expertise from different domains- data engineering, data analytics, mathematical modelling, product management -, covered by different members of the team. It is only now, after taking time to complete a clear role description - together with Electricity Maps’ CTO James Dietrich and other Tech Lead Mads Nedergaard -, that I finally have a personal model for what a tech lead is supposed to do.

Over this time, the boundaries of my role have evolved constantly, between areas commonly associated with senior engineering, product management, research project management, and engineering management. Through this journey, I’ve gained valuable insights and identified latent traits that are crucial for tech leads, which I’ve found to often be overlooked in conventional definitions of the role.

The Beginning

In the beginning the engineers created the semi-conductors and the transistors. Now the motherboard was formless and empty, darkness was over the surface of the deep, and the Spirit of the engineers was hovering over the useless blobs of silicon. And the engineers said “Let there be software” and there was software. Together with software arose unbridled complexity. The engineers saw that complexity was perilous and said “let there be a tech lead to deal with it”. So the engineers created the tech lead.

The tech lead genesis is clear; the tech lead’s primary responsibility is to prevent the inherent complexity of software development from hindering its progress. Sources of complexity in software are numerous. Processing large amounts of data generates complexity; integrating external resources and dependencies generates complexity; optimising resource utilisation generates complexity; prototyping new features generates complexity. Viewing the tech lead from this perspective reveals an innate ambiguity. The tech lead is regarded as a navigator of complexity, whose contributions will assist the team in keeping its course. Given that, in a sufficiently large project, the individual contributions of other team members will undoubtedly surpass those of the tech lead, the most crucial effort of the tech lead should then be to ensure that other team members: 1. Are aligned with the project’s current goal and 2. Contribute as efficiently as feasible.

This indicates that the expectations for the tech lead will be highly context-dependent. Change the makeup of the team and the expectations for the tech lead will also change. Change the types of projects the team has to complete and the role will change too. For instance, in a relatively inexperienced team, emphasis should be placed on knowledge sharing and individual contributions to foster momentum, whereas a greater focus on problem identification and exploratory work would benefit a more seasoned team. A tech lead operating within their domain of expertise will most likely become the go-to person internally to assist colleagues and externally to convey progress, whereas a tech lead tackling a new subject will likely concentrate on establishing procedures to empower those with specialised knowledge to effectively prioritise initiatives.

With this “well, it depends” perspective on the tech lead role, I personally find it easier to understand the veil of mystery that obscures what a tech lead actually does. To return to my former classmates, I would also spend time delving into insights about Electricity Maps rather than inquire about a role I recognise as ill-defined. I am not suggesting that we cease attempting to define the position altogether; however, I comprehend that it is more comfortable not to do so during an informal social gathering.

Tentative definitions are useful (I can recommend that of Camille Fournier in Chapter 3 of her book The Manager’s Path

“My job as tech lead was to continue to write code, but with the added responsibilities of representing the group to management, vetting our plans for feature delivery, and dealing with a lot of the details of the project management process”

that of Patrick Kua, in Talking with Tech Leads

“A leader, responsible for a (software) development team, who spends at least 30 percent of their time writing code with the team.”

or that of Tyler Hawkins in DEV Community

“Tech leads are responsible for helping drive the high-level architectural discussions regarding the work that the team is doing”, “Tech leads help organize the work by breaking down feature epics into stories and tasks”, “Tech leads help remove blockers”, “Tech leads also help mentor their teammates and are responsible for helping level up the team”

But they will never alone define precisely what a given tech lead should prioritise.

I cannot aspire to do better, but I’d nonetheless like to shed light on two concepts. Two concepts which I have never seen discussed in any definition of the tech lead role I have encountered in my journey to define my own role, and yet which have been essential to making myself more effective as a tech lead.

Understanding Leadership

I’m fairly certain that most tech leads are promoted to their position without having a comprehensive grasp of what leadership truly entails. Quite ironic for a position with “lead” in the title, isn’t it? Extrapolating from Randall Stutman remarks on The Knowledge Project, Leadership is the manifestation of messages and symbolism that translates into actions and routines that elevate everyone’s performance.

In our case, this general definition could be simplified to “understanding how to enable every team member to contribute to the fullest extent of their capabilities”. That’s the essence of it. It’s crucial to recognise that leadership behaviours are not exclusive to the lead, but can rather be exhibited by any individual on the team. The lead’s responsibility is to foster a cohesive environment with consistent structure and efficient communication, encouraging the emergence of leadership behaviours among team members. This, in turn, will inevitably enhance overall team effectiveness. In my experience, I have found the following behaviours to be essential in achieving this goal: nurturing feedback and pair-coding routines; being a symbol for championing change and effective prioritisation of one’s time; and, finally, providing clear and effective communication regarding direction, priorities, and expectations.

Some might recognise these responsibilities as what should be expected of an engineering manager. Managers being in a leadership position, it is only natural that they must also exhibit similar leadership behaviours. All leaders should! But where should one then draw the line between the manager and tech lead responsibilities?

The blurred nature of that line motivates a confusion between the two roles, and motivates the existence of tech lead managers; tech leads which are also expected to act as engineering managers for their teams. It is essential to recognise the existence of that line. Not doing so results in setting unrealistic expectations for tech leads, and can be a cause for stress or burnout, as exposed by Will Larson in his post Tech Lead Management roles are a trap. Not doing so is also a failure to recognise the role managers have in the organisational structure of an engineering team. In the line of what Charity advocates for in QUESTIONABLE ADVICE: “MY BOSS SAYS WE DON’T NEED ANY ENGINEERING MANAGERS. IS HE RIGHT?”, I see the role of the manager as externally focused, as opposed to the internal focus of the tech lead.

A manager should focus efforts towards enabling the team and its members to operate effectively within the broader context of the engineering team. A manager should for example nurture feedback to encourage a bottoms-up flow of information throughout the engineering organisation, while a tech lead should nurture feedback as it’s essential for effective collaboration within the team. A manager should provide clear and effective information around the priorities and direction of the engineering organisation, while a tech lead should communicate clearly how the team’s priorities fit into that vision. Managers should source the required external resources to staff the team, tech leads should make sure that the exisiting resources of the team are correctly allocated.

Ultimately, it’s crucial for both tech leads and managers within the same organisation to clearly define the scope of their respective leadership and thus avoid a detrimental overlap.

Emotional fluency

Technical fluency underpins technical leadership. While an effective tech lead might not be the fastest nor most experienced software engineer in the team, they must have a clear understanding of the technical context in which they operate. Without this understanding, impossible to quickly understand trade-offs and objectively balance different solutions to the problem to solve.

Nevertheless, it is crucial to remember that emotional fluency complements leadership. A common emotional foundation must be nurtured with the intention of creating psychological safety and ultimately, trust. Cultivating a culture of trust among team members is essential for any of the aforementioned actions and routines to be well-received and perceived without friction. For instance, implementing a feedback routine is akin to talking to deaf ears if the recipient does not trust that the feedback is being provided with the intention of helping them grow.

Throughout my experience I have identified traits that are important to setting a common emotional foundation. I have notably found that reserving time to prepare questions for regular one-to-one discussions sets a solid foundation for others to honestly share their perception of their own situation. Others have more often shared concerns and issues if they deemed that I could provide support. That implies that it has been necessary for me to keep time aside to be disturbed and help others when necessary, as well as receive requests without being dismissive. Furthermore, it has been important to also be consistent in the way I share my own perception of problems to solve and thus allow others to trust my decision process and judgement. That means in practice ensuring communication around the reasons,feelings and intuitions that motivated me to take key technical decisions. Lastly, setting such a common foundation is a shared responsibility. That means that if one expects others in the team to open up about how a problem the team is facing makes them feel, others will expect the same in return.

Conclusion

Having written down these thoughts has helped me refine and structure my own understanding of what being a tech lead encompasses. I’ll be content even if that’s the only thing this post achieves. While the meticulous definition of the tech lead responsibilities might be helpful in making tech leads effective, I’ve come to realise that the definition of latent traits underpinning effective technical leadership is even more helpful. This, in my opinion, is worth sharing. Ultimately, I’ll be even more satisfied if readers of the post only absorb that a technical leader can only be as successful as everyone else around them.