Almost seven years ago, when I began my transition from developer to manager, I asked my mentor for a list of ressources to help me grasp the nuances of management. The first article on that list started with a powerful statement: “There is no way to learn how to manage except by managing.”
Indeed, management is a delicate art where broad principles are constantly challenged by the unique circumstances of each situation. For beginners, there is a comforting crutch: managing through competence.
I started my management career leading a team of JavaScript developers. As a former lead developer in JavaScript, I was able to establish my legitimacy as a manager and run governance decisions based on my technical expertise. While managing through competence can provide short-term advantages and reassurance, as it gives the impression of mastery over all aspects of the team, it can also lead to long-term pitfalls, blurring the lines between the roles of manager and tech lead, which, in my opinion, are quite distinct.
Tech Lead vs. Manager
The primary goal of a tech lead is to provide technological guidance. This role involves setting the technical practices to adopt accross an organization, enabling technical solutions, and continuously raising the standards within the developer community. However, they are not responsible for the nature of interactions among stakeholders. Their focus should be on developing the teams' hard skills, operating within a framework defined by the manager.
While tech leads concentrate on micro-level tasks, managers must have a more structural impact to address the objectives and needs of the team. They need to set a framework and define goals that encompass delivery, quality, velocity, budget, and interactions with other stakeholders. The manager also has to influence the cultural aspects that tech leads can then build upon.
For instance, a manager might focus on Continuous Integration/Continuous Deployment (CI/CD) to improve product compliance and reduce the potential for human error. It is their responsibility to determine the policies promoted within the company, create an environment allowing implementation and maintenance of these tools (through budget, priorization, etc.) Following this, the lead developer will dive into the specifics of implementation, determining best practices and selecting technologies that align with the objectives set by the manager.
The manager does not need to get bogged down in the details of implementation. What is crucial is having a technical culture that allows them to be educated about the possible options for solving the problems they face. This culture is naturally informed by past experience as a developer, which helps in understanding the dynamics within an software engineering team, but it is not necessary to be “hands-on” to be effective.
In fact, being too hands-on can even be counterproductive. In an era where individual contributors are expected to take ownership, they need managers who can take a step back and address upcoming challenges. A manager who is overly involved or engages in micro-management will inevitably create a culture of execution, stifling collaborative leadership.
As long as the technical culture remains strong, managing a team without technical expertise can be a wonderful opportunity to reinforce one’s position and clarify their role.
How to Manage Without Technical Expertise
This approach still comes with its own set of challenges. A manager with a front-end background may face skepticism from a back-end team. Therefore, it’s essential to reassure everyone, including oneself, through effective communication and concrete actions.
Own It and Clarify
“Fake it until you make it” does not apply here. It is crucial to be clear about your background, areas of expertise, and, importantly, areas of non-expertise. This transparency paves the way for a trusting atmosphere and an open culture that fosters constructive feedback.
You can also enhance this dialogue by articulating your vision of the manager role, clarifying its responsibilities and the nature of interactions. By doing so, you create an opportunity to align expectations and clarify any ambiguous points or disagreements.
Finally, it’s important to acknowledge your limits over time by adopting a humble approach when discussions delve too deeply into technical details. Knowing when to step back is a true management skill that allows individual contributors to build confidence in a supportive environment.
Focus on Objectives
Software development is merely a means to achieve product and business objectives. A less “hands-on” managerial approach allows for the distribution of tasks. The “how” is the responsibility of the developers, while managers focus on the “what, when, who, and why.” As a manager, you can engage with the “how” solely to ensure it aligns with the objectives you have set.
Of course, reality is not so black and white; you still need to understand how developments unfold to grasp the challenges the team faces. However, a solid foundation of technical knowledge will be enough in most cases.
Clear and Tangible Career Ladder
The feelings of illegitimacy that developers may experience when working with managers who are less skilled in a particular technical stack often stem from career progression prospects within the company.
While the concept of “two career ladder tracks" is becoming the norm, there is still much confusion surrounding the notion that management is not the only path for advancement. Consequently, when someone lacking the technical skills assumes a managerial role, it can seem unfair.
Therefore, it is crucial that when management is not solely based on technical competence, there is a robust career ladder for individual contributors. The appointment of a manager can serve as an opportunity to reaffirm this ladder to disolves this frustration, or to build/rework the career ladder if necessary.
Upskilling Is Not Off-Limits
Of course, there is no restriction on upskilling to better understand the technical challenges that teams face, broaden personal knowledge, and reinforce one’s legitimacy when necessary.
This can also be a great way to build relationships with teams by asking questions during your learning process and even identifying individuals who are best suited to mentor peers on a daily basis.
Off skills management might be the solution to improve on your leadership posture and vision. It certainly was for me. I may not be able to write production code in Java, but I sure can manage and hire the engineers who do it.