(Insights into the role of the team lead in software development)
The role of a team lead in software development has been a topic of focus for me lately. I have been exploring the purpose, goals, and responsibilities associated with this position. Additionally, I have been pondering the value that a team lead brings to a team and whether this value can be quantified.
In the Scrum Framework, there is no predefined space for a team lead role in general. However, this does not imply that the role is unnecessary or lacks value in an Agile-based context.
Agile practices emphasize cross-functional and self-organized teams, but this does not eliminate the need for specialization or require every team member to possess skills in all areas, such as programming, testing, analysis, and database management. Hence, there may be a place for a team lead in such scenarios.
To delve deeper into the question of why an Agile team might benefit from having a team lead, let’s review a list of tasks typically performed by team leads in the development teams I have worked with.
This compilation includes the following tasks:
- designing complex technical solutions,
- managing architecture,
- allocating tasks within the team,
- conducting code reviews,
- planning team work,
- designing and managing workflows,
- facilitating meetings,
- clarifying requirements,
- decomposing tasks,
- evaluating work,
- defining and monitoring code standards,
- interacting with external services and other teams,
- providing mentorship and training,
- participating in recruitment and onboarding,
- accepting the team’s results from the customer,
- delivering results to the operational environment,
- reporting on team performance,
- motivating team members.
It’s worth noting that this list may not be exhaustive, and there might be additional tasks that vary from team to team.
Team leads are expected to handle a significant portion of these tasks, often encompassing areas such as architecture, development, and management. In many cases, team leads may also engage in coding themselves. The workload associated with these responsibilities can be quite overwhelming.
Now, let’s examine the tasks from this list in the context of building a cross-functional, self-organizing team of motivated individuals, as advocated by the Agile Manifesto.
Assigning sole responsibility for architecture to one person within a team may hinder participation and engagement from other team members in architectural discussions and decision-making. This can limit diverse perspectives and ideas, potentially leading to suboptimal solutions.
Similarly, if code standards are solely dictated by the team lead, it may diminish their value for individual developers and restrict their sense of ownership and responsibility for the code. It’s essential for the team lead to collaborate and seek agreement from the team on architecture and code standards, rather than imposing their own views. The same applies to code reviews, as having a significant gap between the team lead and the rest of the team can erode trust and transparency, which ultimately affects the team’s overall effectiveness.
Now, let’s shift our focus to the management aspect of the role. It encompasses workflow management, planning, scope and requirements management, as well as handling interactions with external parties. Is it beneficial to consolidate these activities within a separate role?
On one hand, it relieves the rest of the team, allowing them more time for coding and design.
On the other hand, not all programmers enjoy extensive communication with clients, colleagues from other departments, and individuals involved in production. The notion of introverted programmers is not always a myth.
At first glance, the value of a team lead seems apparent and unquestionable. However, this approach can lead to a heavily managed workgroup with an authoritative leader, potentially impeding self-organization and team responsibility. In cases where the team lead is absent or unavailable, dependency on them for critical decisions and contacts can create bottlenecks and hinder progress.
Agile-based approaches aim to grant teams as much autonomy as possible, allowing for decision-making and learning from mistakes. We should provide people with the opportunity to become a team and, through self-improvement, effect change in their surroundings.
When the transfer of workflow ownership to the team is declared, it should not be perceived as a facade, with actual ownership resting solely with the team lead. The team must have the right to make their own decisions about how the work will be done.
It is crucial to empower team members to make joint decisions, even in areas where centralized decision-making is traditionally preferred. The team should establish interfaces for interactions with the external world, and this responsibility should not be limited to one individual.
This may be a challenging journey, but in the long run, it yields improved quality and resilience. Prioritizing shared decision-making and collective responsibility is essential for nurturing a self-organizing team. While highly competent team leads can contribute by validating complex architectural solutions, it should be a choice made collectively by the team.
The team lead should not be the sole repository of responsibility
Nevertheless, as the team matures, the leader’s authority should gradually diminish, and the role of the team lead should dissolve into the team itself. The team should be intentionally guided toward self-governance. A good team should have leaders, preferably multiple leaders, but true leadership does not depend on a job title. Leaders within the team should establish their status through action and not solely rely on management decisions.
However, I am not advocating for the immediate abolition of all team leads. For the teams having the initial maturity levels, a strong team lead can be valuable as both a technical expert and a manager.
What about the career path for developers?
To maintain objectivity, it’s important to acknowledge another crucial aspect. The position of a team lead serves as a tangible step in career growth for many developers. If this position were to be abolished, it raises questions about the career path for top developers. While team values and informal leadership can foster loyalty, we must address the question of how to support individuals focused on vertical career growth.
I firmly believe that this issue merits discussion and a concerted effort to find a solution that ensures everyone on the team feels comfortable, motivated, and able to develop their full potential.