In the past few years Agile took over the software dev industries by storm. Most huge and massively successful companies implement Agile and swear by it. The “self-organizing teams” format seems to be the new de-facto way of running a business. The “Scaling Agile” article by Spotify and similar publications have showed us the way, and we gladly follow. I myself could not contain my excitement when I first found out about the concept.
However after talking to a couple of friends, all coming from amazing companies that implement this in one form or another, I started to discern an unpleasant pattern in this setup. It’s not core to the idea itself, but rather to implementation details of the idea. The problem stems from the belief that self-organizing teams don’t need “traditional” managers since they are…well, self-organizing. Just let the developers pick what they want to work on, and allow them to manage their own processes, problems, priorities, work.
I’ll illustrate the problem using the story of my (fictional) friend Steve.
Steve has a dream, you see. As a young, bright, aspiring professional fresh out of college, he wants nothing more than to join this very successful Company that everyone – EVERYONE – would kill to work at. After all, this Company is famous not only for its major advances in its industry, but also for its culture. It allows its employees self-organize in teams, work on what THEY want to work on, spend a large portion of their time in hackathons, and it doesn’t really care so much for deadlines or budgets. The Company’s org structure is very flat – in fact, they frown upon official titles. It sounds like a dream – and for the most part it is.
One day Steve gets incredibly lucky – he is picked by his dream company over hundreds of other wide-eyed and excited candidates. When he joins the company, he is assigned to a team that, as Steve soon realizes, has a few challenges.
The team’s Product Owner frequently butts heads with the senior engineer Tim, and the rest of the team prefers to stay out of conflict and out of the way of these two strong personalities, and so they keep quiet most of the time. Tim feels that the rest of the engineers on the team are “too weak” and so he doesn’t trust them to code – he does over 70% of coding himself. The engineers are not sure what the goals are, so they just work on their own things, or on emergent requests from other teams. The team doesn’t go to lunches together – everyone has their own “lunch crew” from their previous teams (people frequently move between teams at this Company). The team flies just under the radar of their project’s Product Owner because a) he’s busy and b) somehow the team continues to deliver small increments of value, usually due to heroics of nearly-burnt-out Tim who pulls frequent all-nighters (remember – he doesn’t trust other coders on the team to do the work).
Back to Steve… he has an assigned manger – a guy he has half-hour one-on-ones with every month. Because The Company firmly believes in 360-reviews and self-organized teams, it doesn’t feel the manager needs to spend any more time with Steve. In fact, they assign unrelated work to managers to keep them busy – so they don’t micromanage. The manager’s job is to help Steve draft his “Personal Career Plan” and make sure Steve is doing ok. This particular manager has over 30 other “reports”.
Steve also has an assigned Mentor. This Mentor is a very senior guy on a different project within the company, and he is very busy with… well, whatever it is, he doesn’t have an open spot on his calendar for the next three weeks. The Mentor also has scheduled once-a-month one-on-ones with Steve to mentor him.
At first Steve is at loss. He goes to a few team members and tries to point out the problems. Some shrug, some tell him not to worry about it. Others say that they tried to fix it and it’s now better than it was – baby steps, my friend! A few times he tries to interject between the PO and Tim, he gets caught in the cross-fire. Steve brings this up with his Mentor at the next one-on-one, but the Mentor brushes it off – Tim is a very well-respected engineer in the company, he surely has things under control. He tells Steve to seek further advice from Tim. Steve brings this up with his manager, but the manager tells him that the team will sort it out – “we believe in allowing the teams to self-manage – we are an Agile company after all”.
Finally, inexperienced and new to the company, Steve gives up. He is now quiet during PO-Tim stand-offs, he primarily works on fixing bugs that a guys from QA assigns to him, and after a while he starts going to lunch with that QA guy and his friends. At lunch, he frequently bashes his team’s dysfunctional habits while the QA guys have a chuckle.
A few years later, Steve – now a solid mid-level professional – leaves the Company for greener pastures. He easily finds a job (because he has the Company on his resume!), and is much happier at his new place. He no longer believes in Agile.
I know it’s not fair to generalize. Steve’s experience was probably not reflective of a typical experience of a new employee at the Company. Likely those assigned to healthy teams have much better experiences. But I’ve heard this story enough times to think it’s a symptom of a persistent problem – not having proper management/leadership/mentorship support in place.
“Self-organizing” teams DO need managers (with the understanding that in agile framework, a manager = a servant leader).
- A good manager will be involved in day-to-day of the team enough to be able to see and address the problems without micromanaging
- A good manager will know enough of what’s going on to be effective in training and career growth of everyone on the team.
- A good manager will demand high work standards, accountability and delivery which will keep team on track and motivated
- A good manager will work hard with the organization at large to protect the team’s health by advocating low team members’ turnaround and less task switching
- A good manager will coach the team on proper use of Agile methods and enable the team to mature and become empowered and effective
- A good manager will have strong support network of his/her peer managers to keep him/her honest and provide learning and feedback opportunities
- A good manager will have a good manager of his/her own who is involved, accessible, experienced and has a very strong interest in success of his/her “reports”
- A good manager will avidly subscribe to the “servant leadership” model and his/her primary goal will be to empower and grow (rather than “manage” his/her “reports” and team
I do love the idea of self-organized autonomous agile teams and subscribe to the model famously described in “Scaling Agile” article by Spotify. All I advocate for is that rapidly growing agile companies invest in a strong leadership/management structure to provide sustained and effective career growth support, team coaching and accountability. Please don’t hire more developers if you don’t have a proper mentorship/leadership/management support for them – it’s unfair to new employees and dangerous for the company. If your structure is layered (meaning you organize your teams into “teams of teams” around products, services or features) make sure that you have corresponding layered leadership structure. Yes it will look like (gasp) a hierarchy, but this structure will provide the glue necessary for self-organizing autonomous teams to be effective and work together towards the good of the organization as a whole.