Teams come in many shapes, sizes, and configurations. One team feature that is a fixture in nearly every corporate and governmental environment is the team lead. The role doesn’t have a standard definition. Even though it is common, the role is rarely addressed in any agile framework. I have seen team leads play an important role in facilitating agile teams to deliver value. Sometimes the “important” role is not very positive.
In practice, the team lead role is a combination of four common variants. The four variants are:
1. Manager. This version of the team lead role is responsible for the execution of work, establishing and maintaining culture, and administrative aspects of the team. A team leader as a manager will also typically set up and enforce standards for development. While all versions of the team lead role will have administrative duties, a team lead with a managerial focus will spend a more substantial portion of their time with those duties.
2. Straw Boss. A straw boss is a role that manages the flow of work through a team that someone else prioritizes and accepts. The expression is drawn from the days when farmers would manually thresh hay. The farmer would lead the team and the straw boss would make sure the hay was smoothly cut. The role, while important, had little real authority. The Straw Boss version of a team lead is a stepping stone between technical and managerial layers; it is a transition point. I have heard this version described as a junior leader. Because the straw boss is still a “doer” they are intimately aware of the skills and capabilities of the team. They use this knowledge to ensure team members are loaded with the right amount of work to ensure efficient flow. People management and development do not take center stage in this role – a manager deals with these issues. This role is often called on to set the tone for the group, organize work and manage the process the team uses. The efficiency of delivery is often a key measure of success. This role almost always includes doing the work of the team.
3. Enabler. An enabler, often identified as a servant leader, focuses on helping team members operate as effectively as possible. Tools and techniques used include mentoring, teaching, and motivating. An enabler will view roadblocks as personal affronts and seek to remove them. The role guides and motivates others.
4. Solution Architect. A solution architect provides the team with technical acumen and guidance. This is a specialized form of an enabler.
In real-life scenarios, most team leads are not perfect representations of the most extreme definition of a variant. For example, a team leader can manage the flow (straw boss) and facilitate the growth of team members (enabler). That said, there is little overlap between the straw boss and manager aspects. When the role drifts into delegation and assignment of work (manager and straw boss types) the agile mindset becomes tenuous.
The role of team lead is nearly ubiquitous which means that any agile adoption must make peace with the role or tackle organizational redesign. The latter is probably the best approach because organizational design often collides with getting work done. Problems with how teams are structured generate friction which causes all manner of problems.
No one goes out of their way to make things difficult, however poor operating metaphors and one size fits all solutions are never optimal (I hear the complaint that absolutes are never true). There are typically three options: quit and find somewhere else to work, try to change organizational structure, or compromise and muddle through. The latter approach is the path most organizations adopting (or re-adopting) agile in 2022 take.
There are all sorts of reasons, including that this late in the agile adoption cycle, organizations and leaders are looking for the safe (no pun intended) approach coupled with the hot mess the world finds itself in for the past few years. Very few people are looking to fight the whole entrenched power structure (most firms bring in consultants for that chore :)) to adopt agile. Rationalizing the impact of organizational design on effectiveness and efficiency is a cottage industry that exists just outside of the HR Department’s line of sight.
Let’s presume a typical large organization hierarchical structure:
- C-Level Executives
- Functional Area Leadership (senior managers)
- Application Managers
- Team Leaders
- Team Members
Your structure may differ or the titles may differ, however, hierarchies are as common as dirt in most organizations, except in small or startup companies. Every level in the hierarchy represents a rationalization about how information is disseminated and how group behavior is controlled. Hierarchical structures are just one approach based on one set of assumptions.
There are lots of different approaches; Scrum and any other agile frameworks make differing assumptions. Self-organization is one of those different assumptions which collide with hierarchies. Any term prefixed with “self” in the context of team structure and behavior gives believers in the hierarchy as a form of control heebie-jeebies. Understanding the concept helps defuse the fear of anarchy.
Self-organizing teams collectively control how they will accomplish the work required in any specific sprint. The team does not get to decide the organization’s strategic or business goals or the projects in which they will be involved. Management owns the environment, which provides the boundaries of direction and composition the teams operate within, thus preventing chaos and anarchy.
The role of the Team Lead is the hardest to rationalize when we are framing self-organizing teams in this matter. The fit of the role gets even worse when leveraging Scrum with a Scrum Master; it can render the role irrelevant.
As noted earlier, the four focus areas team leaders exhibit.
- Manager (often a proto-manager working on moving up the hierarchy), who is responsible for the execution of work, establishing and maintaining culture, and administrative aspects of the team.
- Straw boss who manages the flow of work through a team that someone else prioritizes and accepts.
- Enabler who focuses on helping team members operate as effectively as possible.
- Solution Architect that provides technical leadership and guidance to the team.
While it is easy to accept that most individuals often exhibit attributes of two or more of these, one focus will predominate based on the culture of the organization.
Scrum teams with a competent Scrum Master don’t need two people playing the enabler role. Agile teams striving to be more self-organizing will tend to chafe with a team lead playing a classic managers role. Both of these scenarios reduce the role to that of a straw boss who has little direct authority.
A team lead in a self-organizing structure works best when it provides an interface between the team and outside management structures (the product owner is a key business interface) – something we might attribute to the manager role. AND, more importantly, the team lead has technical acumen deployed as something akin to a solution architect and guide. Their technical acumen provides guidance and leadership to the team which adds a fourth focus area to our team lead model.
As with everything in agile, there is no one size fits all solution for how to integrate team leads into your agile approach EXCEPT that it can’t be ignored and the role can’t stop the adoption of an agile mindset. How are you tackling this organizational design problem?