What do we do with all the managers now that we’re all meant to be self-managing teams?
‘Leader’ and ‘manager’ are often used interchangeably but they really aren’t the same thing. Theoretically, all Agile teams are small, self-managing units that have end-to-end ownership of the full value chain of the product they work on. Servant leaders guide the team but do not manage or control it in the same way as a traditional project manager might.
Becoming a servant leader isn’t easy. Many leaders are inflexible about their leadership style and do not vary it to account for factors in their followers’ ability or desire to follow. Traditional leadership training may also advocate for a narrower set of appropriate leadership archetypes and this training will be difficult to unlearn.
Nonetheless, I want to talk about managers instead of leaders. Leaders can be anywhere and everywhere in an organisation — they don’t have to be given a title or authority over others. Managers have both so it’s worth giving some attention to how they should operate in Agile organisations.
Agile suggests that there should be no managers on the team to avoid some of these challenges as well as to promote autonomy and self-management of the team. In principle, this makes sense. In practice, what exactly should one do about the hundreds of delivery, test, quality, project, program, change, ops, FA, BA and other miscellaneous managers that big organisations accumulate over time? Natural attrition through retirement, promotion, and other exits may help reduce the headcount of management slightly but often not substantially. What happens in a big bang implementation when everything’s meant to change overnight? What happens to the managers when the team is meant to be managing themselves?
There are a couple of options: 1. Change nothing. 2. Get rid of managers. 3. Redefine the role of a manager.
Change nothing
The teams are reorganized into small teams of 6–8 or 10–12 people; developers and testers worked alongside each other. With functional and business analysts peppered in the new structure, organisation silos are meant to break down. All feature teams work across components and systems and are able to own and deliver a product end-to-end. Except that they aren’t. The teams have changed but the organizational structure has not. Developers still report to their delivery manager, testers still report to the testing manager, and FAs/BAs still keep their reporting line to the head of FAs/BAs. While there are no handoffs between team members, silos ae still created as different managers pursued slightly different and occasionally contradicting priorities.
Reporting lines create specific incentives that are not altered by ways of working. For the delivery manager, the goal is to deliver the product at any cost. Of course working sustainably is an admirable ideal, no one would disagree with that. Practically, however, in the weeks just before a critical release or at the end of the year with a company-wide code-freeze looming, no delivery manager is going to tell teams to slow down or take a break just because their mad rush to deploy on time is unsustainable. The testing manager, faced with a headcount and budget being squeezed on all sides, is doing all she can to create time for her team to work on test automation. Getting to 100% automation to be exact. She is frustrated by development sprints that bring new requirements fortnightly and force a change in test cases just as often. Adopting TDD also presents a challenge for testers. With developers writing their own tests, does this not make testers, especially manual testers, redundant? The head of functional analysts has seen Agile try and fail in the organisation before. The last time a transformation was stillborn, it left business users irritated and disengaged. It took months to rebuild trust. Now, the delivery manager is talking about removing intermediaries between business and technology. Fas are considered unnecessary buffers. The head of FA knows better. Business won’t commit product owners full-time and certainly will not deploy front-office or value-creating employees to IT. Analysts will still be needed to collect the requirements and write the user stories. If the transformation fails again, analysts can make sure that business product owners are shielded from the worst of the instability and chaos with dev and QA. The delivery manager and testing manager will thank the head of analysts for his foresight in keeping his team active as the voice of business in technology.
Faced with these complexities, who is the arbitrator? Business is an option but they may have a vested interest in getting the product as fast as possible with the minimum time investment in non-value adding work. This may mean that they deprioritize refactoring and test automation in favour of doing manual testing that in more expedient in the immediate term. Programme and project managers would be coordinating across teams and across different silos but their incentives would be similarly biased with tight deadline, scope, and budget requirements for a project with a definite roll-off date.
Get rid of managers
The question of what to do with the many roles that Agile essentially makes redundant is part of the reason that some transformations choose to restructure teams but leave the organizational chart untouched. In a country with sufficiently flexible labour laws, the answer might just be to “right size” by firing and/ retrenching all excess managers.
Professional services firms like consulting companies, law firms, or investment banks often attract “rainmakers”: confident, opinionated people who thrive on winning. Rainmakers don’t like to follow. Team leads are selected based on a combination of expertise, availability, and relationship with the partner. Teams leads then select their own team and for the duration of the project act as line managers for those team members. When the project concludes, so does any management relationship. Rainmakers like this model — it’s almost like “followership as a service”.
Human Resources (HR) handles concerns such as recruitment, compensation, vacation approval, dispute management, disciplinary procedures, and performance management are centralized functions conducted by a department called Professional Development (PD). When unassigned to a project, a consultant has no manager or oversight and is trusted to contribute to work that is not related to a unique project but may contribute to their practice or office.
The lack of line management was a powerful incentive for me as a consultant given my aversion to traditional ‘command and control’ models of leadership. When I was promoted to team leader and senior team leader roles, this became an even greater motivator because then I did not have line management at any time. The relationship between partners and team leads is a peer-based partnership towards mutually beneficial goals. Both play the role of leader and follower at different times during a project.
It’s clear that this model probably won’t suit most employees at a more traditional company. Not everyone wants to be a rainmaker and not everyone likes the idea of being left in the wild to fend for themselves. But it is a legitimate option.
Redefine the role of a manager
So we’re left with one more option: redefine what being a manager means.
Flex the manage style to match the team’s competencies and motivations
Agile frameworks tend to assume that all teams were competent and motivated by default and all managers should be coaches/servant leaders by default — unless you break the model somehow and let waterfall start creeping in. In real life, both managers and teams are more diverse than Agile or waterfall ways of working tend to account for.
To reflect this reality, I believe we should consider two components of the redefined role of an Agile manager: a certain set of traits and behaviour for the manager, and a certain set of motivations and competencies for the team.
I think that there are four archetypes for behaviour for a manager of an Agile team:
1. The Commander with an authoritarian style who instructs teams on what they should work on and how they should work. This type of leader is often more transactional than transformational by necessity and may favour managing process over managing interactions.
2. The Conductor with an orchestration role who coordinates and guides how teams should work. This archetype may also be described as a Coalitional leader given how she is able to bring potently unrelated followers together into groups that work to collectively achieve a common set of goals.
3. The Collaborator with an inclusive style who leads as a member of the team with joint accountability for what the team works on
4. The Coach who removes blockers and enables the team to work optimally but does not have accountability for what the team works on. This archetype can be viewed as transformational leadership given that the Coach needs to inspire teams and change the way that they think about their work and its meaning.
The Commander is not going to be suitable for most Agile set-ups but let’s park that bit of obviousness for a few paragraphs given that most organisations have raised their managers to be Commanders. Here’s where the motivations and competencies of the team come in. For the sake of simplicity, I consider characterize teams based on only one of four options:
1. Incompetent and unmotivated (low-skill/low-will) — this team will need explicit instruction as well as interventions to safely increase intra-team trust and explicit motivation
2. Incompetent and motivated (low-skill/high-will) — this team requires clear task guidance and upskilling to keep levels of motivation high while not putting project delivery or quality at risk
3. Competent and motivated (high-skill/high-will) — this team can be coached towards continuous improvement but does not require other targeted interventions as motivation is considered as a driver for teams to exert more effort in the pursuit of organizational goals
4. Competent and unmotivated (high-skill/low-will) — this team may be resentful of attempts to micromanage them or take control and needs additional ownership and autonomy to feel empowered and motivated
This differs from previous models of Agile leadership that assume that all teams were competent and motivated by default and all leaders should be coaches/servant leaders by default.
When faced with a team with low levels of competence but high levels of motivation, the team needs training and structured tasks to be able to perform well. The Conductor, and Coach become valid models. The Conductor can provide guidance to the team through coordination of their activities. The Coach can provide support to this kind of low-skill/high-will team to remove obstacles to their performance such as lack of training or experienced team members, while also keeping them motivated and engaged.
The Commander might provide sufficient guidance on tasks for the team, but trust and psychological safety will often be at risk in teams with a Commander. There are often negative consequences for failing to complete tasks in the way specified by the Commander. When employees feel unable to work, share ideas, experiment, and collaborate without fear of the negative personal or professional consequences of failure to do as the Commander instructs, the team will not have the requisite levels ‘psychological safety’ to enable agility of the workforce.
Diversity of approach, lived experience, and personality in the leadership team gives followers more opportunities to resonate with the values and behaviours of a broader range of leaders. By making space for all four archetypes of leadership, the organization can retain heterogeneity in the management of the workforce without experiencing the negative impact of assigning the inappropriate type of leader for the team’s level of skill and will. At the same time, even Commanders need to stick to four basics to be good Agile managers.
Direct the flow of work towards a clear set of outcomes
When we think of managers, we often restrict this to the direct reports that the manage has under them in the organisational hierarchy. In real companies, manager often have influence over people who do not report to them. The lines and boxes mean something on the nice PowerPoint decks but relationships and power dynamics play out differently when you’re dealing with real teams. And, importantly, you are not always the manager of all the people you manage.
A manager’s ability to manage the work of multiple people, departments, or divisions towards a measurable set out outcomes can make life much simpler for followers. It enables them to see the ‘big picture’ of where the organization wants to go but also frees them up to be able to work towards that goal without unduly worrying about whether they are working towards what the organization needs.
Remove blockers
The ongoing process of removing organizational blockers or obstacles to results is an integral part of the process of managing the flow of work to followers. There are often exogenous factors that will prevent a team or individual from being able to achieve their stated goals. Many of these affect multiple people or have an impact that is felt across many teams. It is often impossible for one individual or team to solve a problem that is so cross-functional or cross divisional. A manager has a role with potential reach across these organizational silos by virtue of their positional or relational power or networks. They are often better placed to collaborate with other leaders to remove these blockers and create an enabling environment for their teams and co-workers. For high-performing or conscientious followers, this removal of blockers helps them be more effective and efficient by creating a working environment conducive to achieving results.
Create opportunities for growth
All people want to achieve their goals and have the opportunity to pursue other goals in recognition of their initial achievements. This opportunity can be generally understood as the opportunity to grow. The nature of this growth may be personal or professional. It may also be understood in a different way. For one employee, growth may equate to a promotion and increased responsibilities while for another growth is the opportunity to work on projects that they are personally invested in with people they like. Part of the manager’s responsibility is to understand what growth means for each person or team they lead and create opportunities in line with the subjective definition.
Give and accept honest feedback
A short feedback cycle of honest and actionable feedback helps followers learn faster and quickly adapt their behaviour, approach, and goals for better outcomes. Without this feedback, teams may not have the requisite guidance or insights into both what is working and what is not. More importantly, they may not understand why and that understanding is crucial to being able to action insights and make changes. This feedback also needs to be bi-directional such that the manager is not only giving feedback but also receiving it and using it as an input into improving her leadership approach and ambitions.
And, finally, stop calling people resources
When pitching to me for a contract to supply Agile coaches in India, a premier consulting company told me that it could not leave “offshore resources out there by themselves” and would have to add a manager based in New York or London to the bill to compensate for this shortcoming in their resources. The notion of Agile coaches unable to self-manage while they supported teams to learn how to self-manage did not strike them as contradictory. When challenged, they dug in. It wasn’t in their business model to let their resources self-manage. Resources need a manager.
In one sense, the consulting company was correct — resources do not self-manage. Resources do not get thanked or rewarded for thinking for themselves, only for following instructions quickly and correctly. Resources don’t care about your business or your values. Resources do not feel invested in its success. Resources do not experience the purpose, autonomy, and mastery that fuels feature teams to deliver breakthrough impact for business. People do.
The wave of de-personalisation and institutional detachment we brought on in the heyday of offshored never quite wore-off even when companies realized the unsustainability of the model. We repackaged human beings as commodities and the impact went beyond political theory and hit the economic bottom line. Most people do not want to work in a place where their humanness should be left at the door. When they could be a leader, an innovator, or part of a team of people who care about each other, the next tech maverick is not going to settle for being a “resource”. And at the rate demographic and societal changes are sweeping through the workplace, soon, no one will. Get ahead of the wave now, Agile managers — stop calling people resources.
