Managers transitioning from waterfall to Agile will need to renegotiate their relationship with their teams if they are to succeed. A manager cannot simply become an Agile Manager – a big part of a transition requires a rethinking of how job titles are assigned and the leadership responsibility that comes with them.
I was recently approached by a client who asked about effective Agile Organizational Structure. That question spawned these preceding articles:
- Specialists Are Overrated
- How to Cross-Skill and Grow T-shaped Team Members
- How to Be an Effective Manager in Scrum
Scrum Team Titles
The first thing to understand is we need to stop using title promotions to ‘reward’ employees. Leadership is not a badge, it’s a task to be shared.[1] The number of titles in an organization inversely correlates with the effectiveness of the collaboration.
As teams grow, job titles (e.g. Business Analyst, Quality Assurance, Software Developer, …) get in the way of working together to deliver the most value to customers. Many Agile Teams set these titles aside – either by ignoring them or by making the “Team Member” role the label for everyone on the team.
Traditional titles can be toxic at the team member level because they imply a limitation. Can a Quality Assurance Lead help with Usability? Can a Developer contribute to database administration? Of course they can! When people see titles, they see boundaries. When managers don’t reconsider their role and titles, their lack of action implies that Scrum changes the Team but not Management.
Titles are also toxic because they promote specialization. As Noika[2] and others have proven, as soon as we create a special role to solve a problem, the specialist who fills that role has every incentive to ensure that the problem never goes away. They’d be doing themselves out of a job if it does.
Scrum Management Titles
We get too specific with management titles too. For example, “Development Manager” rather than “Quality Assurance Manager” makes the Team members whose background isn’t within that area – in this case, software development – feel a few things:
- they have no career path themselves
- their management team doesn’t have an understanding of their needs and problems
- the Agile transformation is focused on that skillset and department, so it doesn’t include them
In Large-Scale Scrum (LeSS) adoptions, everyone lets go of titles and figures out, as a group, what roles need to be played. For many organizations, that is a bit too radical. However, the underlying principle is solid in the case of managers —you don’t need managers as traditionally understood, you need people, who focus on growing the capabilities of the team members.
So what’s the best way for managers to choose new titles for themselves? Ask the team.
How to Ask the Team
There are obviously a few ways you could go about getting input from the team but, to get you started, I suggest running a short workshop. The focus will be on management reflecting on their roles.
(Assumption: you’re already familiar with the idea and mechanics of a Skills Matrix workshop.)
Exercise Goal: Create some form of a shared understanding with all the team members about the role that management is evolving into.
Time: a few hours if only one team. More if there are several teams involved.
Provide Context: Explain that your goal, as a manager, is to redefine your role and title to better support the Team. Remind the Team of the importance of self-organization. Make clear that this exercise needs to be repeated, perhaps annually, so that relationships are renegotiated on a regular basis.
Framing question: “What would it mean if we all had no titles?” Use this, or a question like it, to start a conversation with your team(s). Start with the premise that we’re all equals. What role can each of us play? Do we need titles? If so, what should mine be?
Activities:
Role Responsibilities
(similar format to the Cross-skilling workshop)
- Using a silent listing style, each team member writes down everything a manager does (Action, Task, Responsibility) today, on PostIts or anything else at hand.
- As a team, they sort the items into who does what in a Scrum world. ScrumMaster? Product Owner? Product Development Team? Not needed in Scrum? or Person previously titled as Manager?
- As a team, discuss significant differences.
Now that we’ve defined the role, we step back and ask: what title best describes this role?
There you will find your answer to what your new management title should be.
Offer Career Paths
As mentioned, moving beyond titles to focus on collaboration is preferred. If an organization has a formal requirement that titles must continue to exist, then it needs to create career paths that allow senior technical people (coding, testing, usability, analysis etc.) to take on more of a mentorship role without having to become managers. In addition, the people who take on mentorship need to come from diverse backgrounds – both in skill area (BA, QA, U/X) and in ethnicity/gender – to represent from a wide range and not just the majority white male so common in technical fields. Agile has a reputation for being developer-centric when its intention was always to be people-centric.
These available career paths need to emphasize the value of mentorship and the importance of growing team member skills, more than the value of individual contribution.
Ask: What do you need? What’s getting in your way? What can I do as your manager to help? [3]
“Titles distinguish the mediocre, embarrass the superior, and are disgraced by the inferior.” – George Bernard Shaw
Stop being a Manager, let go of the title, focus on service to the team and the organization. Then follow through and support the behaviour change with ongoing coaching support.
Whether it’s a formal outside coach or well-trained internal team member isn’t as important as regular, frequent feedback is, to help ingrain this shift to sustainable change [4] [5] [6] [7] in how management and team collaborate.
References
“Titles are Toxic” – https://randsinrepose.com/archives/titles-are-toxic/
[2] “How Specialization, Management by Fear, Complexity and Coordination Chaos killed Nokia” by Ari Tikka
[3] “The 3 questions managers should ask” by Chris Bailey
[4] Why Motivating People Doesn’t Work by Susan Fowler
[5] “Why Leadership Development Isn’t Developing Leaders” by Deborah Rowland
[6] “Leadership Development Should Focus on Experiments” by Ron Ashkenas and Robert Hausmann
[7] “Executive Coaching and its outcomes: What the research actually says” (PDF) by Dr. David Wilkinson, The Oxford Review
Mark Levison has been helping Scrum teams and organizations with Agile, Scrum and Kanban style approaches since 2001. From certified scrum master training to custom Agile courses, he has helped well over 8,000 individuals, earning him respect and top rated reviews as one of the pioneers within the industry, as well as a raft of certifications from the ScrumAlliance. Mark has been a speaker at various Agile Conferences for more than 20 years, and is a published Scrum author with eBooks as well as articles on InfoQ.com, ScrumAlliance.org an AgileAlliance.org.
Leave a Reply