Do’s and Don’ts for Having a Technical Lead on a Scrum Team
Scrum, being a process framework, has little to say about team roles aside from there being a self-organizing and cross-functional development team, a product owner, and a ScrumMaster. But in reality, organizations often impose a structure. A common role that organizations define is a technical lead.
In many cases, the technical lead isn’t a manager, but a technical coach and domain expert. Often the role is a proxy for people external to the team to discuss issues with—product-related or not—in order to protect the majority of the development team from interruptions. This can be useful, but when the lead begins to isolate the team from its customers in the organization, the team can lose an important feedback mechanism.
It’s better that the lead serve as a focal point to facilitate interactions among the team, the product owner, and other stakeholders. In this role, the tech lead becomes a process coach for helping stakeholders work within the Scrum process.
Another argument for having a technical lead is to have someone “accountable” for the work. This seems to be contrary to the idea of team commitment, and often points to underlying problems, such as a lack of trust between the business and the team, and between management and team members. It also is challenging because even the best tech lead can’t do the work of the whole team.
It’s preferable that a lead in this position try to help the team find ways to work more effectively through process, architectural, and engineering mentorship. The lead can also work to understand and resolve the problems behind the desire for accountability beyond the team level.
In some cases a tech lead may be asked to serve as the team’s ScrumMaster. This is possible if you are disciplined about keeping clear boundaries between the process and development responsibilities.
And in some cases a technical lead can even serve as a manager. In these cases, it’s important to avoid directing work and impeding the team from finding the right approaches on their own.
In all these situations, it’s important to be mindful of the time commitment involved. Any responsibility a team member has outside of development takes away from development work, so everyone needs to be transparent about the relative importance of each aspect of the work. It is also too easy for a team with a lead role to lose the self-organizing dynamic and devolve into a command-and-control relationship. This leadership style makes sense for some projects, but not the ones that we would choose Scrum for.
There is nothing wrong with the idea of a technical lead on a Scrum team, as long as the role doesn’t impede the team from being effective. A team might even choose to have someone in that role. The important things are that everyone is clear on what the role of the lead is, and that the person in the role accepts the responsibilities associated with working on a self-organizing team.
