When leading training classes or coaching teams and organizations, I often hear the question “what is the role of a manager on an Agile team?”
It’s a very good question and there are quite a few misconceptions. To start exploring this topic, let’s begin with what a manager typically does in a traditional environment. We’ll use Jim – who manages a team – as an example.
Jim The Traditional Manager
- Output: Jim’s main responsibility is the output of the team. Is the team delivering what is expected of them? They better be because Jim is accountable for the work getting done. This paradigm often leads to micromanaging, distrust and an ‘us versus them’ mentality.
- Priorities: Jim is also responsible for assigning work to the team. This often happens based on individual strengths, which does not support skill development and further perpetuates already existing silos of knowledge. It becomes easy for people to sit back and wait to be told what to do and keeps Jim really busy.
- Performance: Jim is in charge of who gets a raise, bonus or promotion. However, Jim is very busy monitoring output and doling out work, so it’s difficult to have an accurate understanding of how well each person is performing. Once again, this approach promotes the individual and not the team.
- Capabilities: Developing people’s skills is important but is often overlooked in a traditional system. When 1-on-1 discussions happen, Jim usually receives a status report about the output and priorities, which feed into performance evaluations. Little time is spent coaching and mentoring.
- System: When it comes to improving the system in which teams operate, Jim does not have the time or authority to lead change. System level issues are often “escalated” to Jim’s manager because that might be “above his pay grade.” In addition, Jim does not have the knowledge of systems thinking and isn’t sure how to connect the dots.
How Do Managers Become Managers?
Now don’t get me wrong, I am not trying to imply that managers are incompetent or bad people. These situations and managerial approaches often stem from good intentions. Let’s see if Jim’s story sounds familiar to anyone…
Jim was great at his job – we’ll call him a Doer. So great, as a matter of fact, that he was promoted to Lead Doer. After excelling in his role as Lead Doer, he was again promoted, this time to Senior Doer. And due to his knowledge, skills, and continued excellence in doing, he was promoted yet again. This time he was promoted to Manager… something he knows nothing about. In addition to not knowing how to manage people, he’ll be expected to do it without any formal training. Jim is happy, but more than a little nervous…
If that sounds familiar, it’s because that is the classic corporate career path of an aspiring professional. It’s not really Jim’s fault. He’s just doing what’ “he’s supposed to do.” It’s a step I’ve seen many friends and colleagues take. And I’ve seen those people take it hesitantly because they knew they’d be giving up what they loved most about work. But it’s a new challenge.
Unfortunately, it’s a challenge in which most new managers are not set up for success. This is because many new managers don’t receive training in management at all. If they do receive training, it is most likely in scientific management theory – also known as Taylorism – which has proven to be ineffective with knowledge workers.
Since Jim is now a manager, but hasn’t been trained to be a manager, he will instinctually work in his comfort zone. When he was a doer, he was very focused on output and priorities. His manager would tell him what to work and follow up to see how it was going. Therefore, that’s what Jim thinks he should do. Unfortunately, he is focused on the wrong issues. What needs to happen is that we flip the priorities on their head, and here’s why.
Jim The Agile Manager
Let’s imagine that Jim took some leadership training, got some coaching and mentoring and understands how an Agile manager should behave…
- Output: Jim is supporting an Agile team. A Scrum Team to be precise. While Jim used to focus heavily on the output, that is not necessary on a Scrum Team. Why? A Scrum Team has a self-organizing, cross-functional group of people called the Development Team. Their responsibility is to develop high quality products that delight customers. They were hired because they are good at their job, and the organization trusts them to deliver. Jim no longer needs to focus his time on managing the output and can redirect his energy elsewhere.
- Priorities: Jim used to let everyone know what they should be working on. They relied on Jim for that. However, on a Scrum Team there is a Product Owner whose responsibility is to prioritize the work. The Product Owner (and Development Team) collaborate with the stakeholders and users to understand what should be worked on next. Again, Jim can focus his attention in other areas.
- Performance: While Jim will still be involved in assessing performance, many others will now be involved as well. On an Agile team, we’d like to see 360 feedback where the most important feedback comes from peers and those working closely with each other. This encourages accountability at the team level because teammates know who is contributing and supporting one another.
- Capabilities: Now that Jim is not focused on the output and priorities, he has more time to get to know what people are struggling with and how he can help them. Perhaps he coaches and mentors them. Perhaps he makes the case to increase the training budget so people can stay on the cutting edge of new technologies. Perhaps he finds some funding to support a community of practice. Jim is helping develop people and the team so that they can be more effective.
- System: Jim is now able to take a step back from the day-to-day details of the work being done by the Scrum Team and look at the whole system and how it flows from concept to cash. Jim learns about systems thinking and organizational design. He collaborates with other managers and executives to break down silos. As a team, they identify the system optimizing goal and work together to eliminate organizational impediments.
Jim is kicking ass and taking names. He has a new outlook on what a manager should do. He now understands that what he was once busy managing – the output and priorities – aren’t the big challenges. The team can figure that out. His energy and focus are better spent tackling the messy issues of politics and structures and policies that get in the way of real change taking place. Where people used to say “that’s just the way things work around here,” Jim is breaking down barriers and helping to change the organization’s culture.
Traditional Managers vs Agile Managers
As you can see, the role of an Agile manager flips upside down the role of a traditional manager. Because the team is empowered to make their own decisions and trusted to get their work done, managers can focus on difficult issues that will lead to lasting and meaningful organizational change. Taking on those challenges requires skill, perseverance and fortitude.
It’s not easy, but someone’s gotta do it. And that someone is Jim, the Agile Manager.