One common problem in Agile/Lean organizations is that after you’re done with creating cross-functional teams and implementing agile planning and prioritization you reach a sort of “cap” of organizational performance and evolution. This can usually be seen in productivity measures as a leveling off and felt as frustration that
we are not evolving as fast as we used to. There is often a feeling of a void.
This “cap” is in my experience usually caused by that you still use traditional pyramidal, top-down organization and traditional management practices and philosophy. These effectively work against the natural evolution of agile organizations which is more about networks and autonomous teams. I won’t go deeper into that here but get in touch if you’re interested!
It’s scary for any company to challenge the traditional way because still most organizations work this way. Also, HR is often working actively against a change. Any sensible manager can see that just breaking down the traditional structures and letting the organization self-organize is too risky. As always taking small steps is the best way.
One proven way to start removing this organizational performance “cap” is to do as I describe below.
One assumption here is that managers are responsible for certain development teams. Usually every manager have responsibility for certain individuals as well, and the same thinking can be applied for that case.
1. Create a management team
Take the managers who are responsible for certain development teams and make them create a team of their own. You may need to work on team-building in this team since many managers are not used to working in teams.
2. Disconnect the manager connection
Make the management team as a whole responsible for all the development teams but no manager is responsible for certain teams.
3. Let the teams choose manager
Let the development teams vote on which manager they would like as support for their team. The chosen manager will be acting as contact/servant leader/coach to the team but the responsibility for the team will still be in the whole management team
4. Redefine management’s role
Managers have a specialist role and often also an expert role in the organization. The management team should now commit to serving the organization with their specialist skills and expert knowledge, just as any other team does.
Note: the specialist skills and expert knowledge should be worked out explicitly and can then be posted as services which the development teams can “buy”.
This redefinition of management’s role equalizes the hierarchical difference between managers and development teams. This simple shift in mindset will help a lot in lifting the performance “cap” of the organization. The most important shift is that we effectively tell the organization that we are all here together and that everyone should take responsibility for the outcome.
I’m sure you have seen that when one group or individual takes responsibility it effectively relieves other roles and groups to take responsibility. When the development teams can see that the management team is working with them on an equal basis, albeit with different skills and some extra legal power, autonomy and innovation can surge.
Note that we have not changed the formal organization nor the legal responsibilities that managers have, we have just shifted the culture.
More on the management team
A great side-effect of creating a real management team is that managers can pursue their individual aspirations and use their strengths in a team setting. For example one manager may be very good at creating strategies and another very good at coaching teams. Now both can use their skills freely and not be confined to a “manager box”. Working naturally in pairs or small workgroups is also much easier.
A development team has a prioritized backlog and so does the management team. This means that any work that the management team does will be a question of priority. For example the management team may say no to taking care of some issue in a development team because they want to work on strategy. The development team may then need to resolve the issue themselves, creating even more autonomy and responsibility taking.
Latest posts by Emil Vikström (see all)
- “Big 5” dangers for your software company - March 10, 2015
- How to produce successful change - November 19, 2014
- Guest blog: Stepping Stones into the Future through Leadership Agility at Ericsson - September 1, 2014
Copyright © 2014 Emil Vikström. All Rights Reserved.