management

Embracing shared leadership

Agile / / / , , , , ,
Shared pizza

I’ve recently made a point of reading up on shared leadership and I’m converted, I think its the way to go. Two reasons really, first it describes better what I see happening in the work environment and second, it offers an alternative to the confusion around “self-organising teams” (or is it “self-managing” ?)

I regularly hear comments like “everyone in your company is a leader” or “leadership is all around you”. I struggle with these sometimes because I wonder “if everyone is a leader… who is doing the following?” or to put it another way: if everyone is leading who does the non-leadership work? In the discussions of shared leadership I find the answer.

Let me dig into both a little further.

Most of the papers I’ve been looking at come from the academic world. That makes for some very dry reading and many of those papers aren’t easy to access – luckily I have access to a University library at the moment. The upside is that it means the field has been researched properly.

Lets start by defining what I mean by shared-leadership:

“shared leadership is a dynamic, interactive influence process among individuals in groups for which the objective is to lead one another to the achievement of group or organizational goals or both” Pearce and Conger, 2003 (this book is referenced in several of the papers I looked at so seems a good starting point)

Lets add:

  • Shared leadership covers influencing peers as well as those who appear higher and lower an org chart.
  • While some authors use the term “shared leadership” to describe determined job-shares (e.g. joint CEOs) most use see it as an emergent state.
  • Leadership is exercised through Influence more often then direct authority, and influence derives from knowledge, ability, technical skills and soft skills.

This describes the way I see good teams work. The Scrum Master leads daily stand-up meetings with their facilitation skills, they may set up the planning meeting and lead the team through the steps. But the Product Owner/Manager steps forward when it comes to nominating and prioritising the work to do. When the conversation turns to technical issues team members my more naturally follow the suggestions of an experienced coder or designated architect.

Outside of set piece events, during the day-to-day work, the person who picks up a piece of work will lead on that work. If get stuck they may call in others while retaining leadership of the problem. Or, they may defer to a more experienced colleague who comes to help.

The idea that leadership moves matches what I see happening. That doesn’t preclude there being a designated leader or, manager. In appointing managers companies expect them to take on a leadership role and in designating them a manager confer some authority on them.

A good manager will respect the abilities of others and allow leadership to flow. So they will let the Scrum Master run meetings, let the Product Owner/Manager prioritise work and let experienced coders lead on the design. They will use their authority to resolve disputes, interface to the company, and use that authority for the good of the team.

Of course, not all managers are good, weak managers are all too common. I recall one in particular, Jerry, who on appointment immediate moved to put the team in their place. He didn’t want team members deciding on priorities, design, team working or even speaking to other managers. Until he arrived the small team were sharing leadership and working effectively.

Shared leadership matches the “distributed and devolved authority” that I’ve been advocating for years. What is needed is for decisions to be made by those closest to the need to the decision and those with the most knowledge.

Distributed and devolved authority has been my formulation for side-stepping the questions of “self-organising” or “self-managing” teams. While I’m all in favour of involving more front line staff in decision making those terms create problems.

For a start, there is little agreement on whether it is “self-organising” or “self-managing” – or what the difference is. Neither term is particularly well defined. Sometimes “self-directed” gets thrown into the mix to complicate things.

Because the terms are poorly defined they bring unwarranted assumption. Even some well known advocates take the terms to mean “No managers” – and in particular no project managers. Now while there might be reasons to reduce the number of managers in such an environment once people think managers might be gone it creates problems.

Then there is the question of who is in the self-organising team and who is outside the team? I remember one developer who took exception to the Product Owner nominating the work to do. He pointed out that the team was supposed to be self-organising – at least according to Scrum – and he saw the Product Owner as behaving like a manager. To his mind that was wrong.

His interpretation gave me a lot to think about, there was a logic in his interpretation. At the time I didn’t know the term “shared leadership” but I was applying the ideas. In my interoperation the Product Owner and Product Manager lead on what commercial, customer facing, work needed to be done. Plus, they were members of the wider team, they were specialists, leaders, in one aspect of the product but not all aspects. When it came to the solution design, and how the work was split up then other team members would step forward.

The problem is that hierarchies tend to develop whether you want them or not. In the absence of a formal hierarchy an informal one often emerges. The one that emerges might be more problematic than a formal one. Consider a team which swaps its designated manager for self-organisation only to see an prejudiced Alpha Male emerge as leader. (See In defence of hierarchy.)

Now don’t get me wrong, I agree there are lots of problems with “Management” but, unlike some, I don’t see Management as fundamentally flawed. Rather what I see is a lot of bad management. In truth much of this is because few stop to take the time to learn about management and how to perform it. Management is a skill like any other – or perhaps, given the breadth of management it is multiple skills.

Herein lies another problem, if a company adopts “self-managing” teams and removes many dedicated managers it does not mean all the management work is magically removed. Sure some will be, but managers don’t spend the whole day talking to other managers. The management work which remains will now need to be done by the team members. In other words, fewer managers means more people managing.

Given that these people have decided not to become managers there is every chance they aren’t interested in management work – much of which can be boring. Neither will these people have spent time, or be interested in, improving management skills which they now need.

The best teams I see practice a form of shared leadership while still having a manager. Sometimes that manager is close, even in the team, other times they are removed. But a good manager appreciates the abilities of the team and lets leadership flow between team members.

I expect to hear more of shared leadership, it is a model I intend to learn more about and help my clients embrace. If you would like to continue this conversation please get in touch, e-mail me or book a call.

Embracing shared leadership Read More »

Fixing agile failure: collaboration over micro-management

Agile, Management / / / , ,

I’ve said it before, and I’m sure I’ll say it again: “the agile toolset can be used for good or evil”. Tools such as visual work tracking, work breakdown cards and stand-ups are great for helping teams take more control over their own work (self-organization). But in the hands of someone who doesn’t respect the team, or has micro-management tendencies, those same tools can be weaponised against the team.

Put it this way, what evil pointed-headed boss wouldn’t want the whole team standing up at 9am explaining why they should still be employed?

In fact, I’m starting to suspect that the toolset is being used more often as a team disabler than a team enabler. Why do I suspect this?

Reason 1: the increasing number of voices I hear criticising agile working. Look more closely and you find people don’t like being asked to do micro-tasks, or being asked to detail their work at a really fine-grained level, then having it pinned up on a visual board where their work, or lack of, is public.

Reason 2: someone I know well is pulling their hair out because at their office, far away from software development, one of the managers writes new task cards and inserts them on to the tracking board for others to do, hourly. Those on the receiving end know nothing about these cards until they appear with their name on them.

I think this is another case of “we shape our tools and then our tools shape us.” Many of the electronic work management tools originally built for agile are being marketed and deployed more widely now. The managers buying these tools don’t appreciate the philosophy behind agile and see these tools as simply work assignment and tracking mechanisms. Not only do such people not understand how agile meant these tools to be used they don’t even know the word agile or have a very superficial understanding.

When work happens like this I’m not surprised that workers are upset and demoralised. It isn’t meant to be this way. If I was told this was the way we should work, and then told it was called “agile” I would hate agile too.

So whats missing? How do we fix this?

First, simply looking at small tasks is wrong: there needs to be a sense of the bigger thing. Understand the overall objective and the you might come up with a different set of tasks.

Traditionally in agile we want lots of small work items because a) detailed break down shows we understand what needs to be done, b) creating a breakdown with others harnesses many people’s thinking while building shared understanding, c) we can see work flowing through the system and when it gets stuck collectively help.

So having lots of small work items is a good thing, except, when the bigger thing they are building towards is missing and…

Second, it is essential teams members are involved with creating the work items. Having one superior brain create all the small work items for others to do (and then assign them out) might be efficient in terms of creating all the small work items but it undermines collaboration, it demotivates workers and, worst of all, misses the opportunity to bring many minds to bear on the problem and solution.

The third thing which cuts through both of these is simple collaboration. When workers are given small work items, and not given a say in what those items are, then collaboration is undermined. When all workers are involved in designing the work, and understanding the bigger goals, then everyone is enrolled and collaboration is powerful.

Fixing this is relatively easy but it means making time to do it: get everyone together, talk about the goals for the next period (day, week, sprint, whatever) and collectively decide what needs doing and share these work items. Call it a planning meeting.

The problem is: such a meeting takes time, it might also require you to physically get people together. The payback is that your workers will be more motivated, they will understand the work better and are ready to work, they will be primed to collaborate and ready to help unblock one another. It is another case of a taking time upfront to make later work better.

Fixing agile failure: collaboration over micro-management Read More »

Is all management bad? Or is it just bad management?

Agile / / / ,

There is an interesting piece in this week’s Economist about the poor quality of management in the UK, “For Britain to grow faster it needs better managers” (paywall). It suggests bad management is a large part of the productivity gap between the UK and other developed nations. Living in the UK, and having seen inside many British companies this rings true with me. I’ve long thought it was less a case of “In search of excellence” and more a case of “In search of mediocracy.”

Now that said, I don’t have an objective point of view: I’ve been involved with many “project rescues” or “turn arounds” (actually I quite enjoy them, call me!) in the UK but my clients abroad are normally more stable. I suspect this is selection bias: because I’m UK based it is easy to ask for help. Flying someone in from abroad is a barrier so only the better managed companies in Europe and the USA would do it. So while I might think UK management is bad it is entirely possible that it is bad everywhere. Indeed, I am sure there is bad management everywhere, and there is good management too; but in the UK the ratio of bad to good is higher.

The international agile movement doesn’t do much to encourage management to improve. All the anti-manager talk (“self managing teams”, “no project managers”, etc.) creates a barrier. It has long been my view that such anti-manager talk is largely a reaction to bad management and it is entirely possible that “no management” is better than “bad management.”

Simultaneously, “good management” can be value adding, people don’t push back on “good management” (even if it gets branded as bad just because it is management). Sometimes, making things better for the many means being unpopular with a few. The few will voice their complaints more loudly than the many will voice their praise, and often it is hard to attribute success to managers anyway.

What we miss

The common agile view of management as “a bad thing” misses two points:

First off: removing the managers will remove some management work but will leave a lot. Removing managers does not remove management work. The work which remains either doesn’t get done (worse still) or is spread around those who remain so everyone’s work gets disrupted. On the whole these people don’t want to be managers, so they are unhappy and don’t have management skills. They do have other skills – business analysis, Java, support desk, whatever – so now they are not using their most productive skills and are unhappy with it.

Second, and more importantly: removing managers does’t do anything to improve the skills of those who do management work. Whether this is managers in place or people who have to step up when managers are fired. In other words, all this talk of “no managers” stops us from improving management skills one way or another.

Yes, I think workers and teams should have a voice in the work they do.

Yes, I think we should make group decisions and take into account diverse opinions.

Yes, managers sometimes need to use authority but good managers spend more time nudging, enthusing, guiding, structuring. Occasional use of authority can help, over use undermines.

Yes, I think people can take more responsibility. Some of what passes for management work is admin that could be dropped, information sharing which could be automated, or managers making work for other managers.

But I happen to think good management recognises all those things and respects the expert workers.

Bad management ignores all those things and subscribes to the “Action Hero model of management”: you do this, you do that, I’ll siege the bridge, if I’m not back in 10 blow it all to kingdom come, move it!

The irony is, those who subscribe strongest to the “no management” meme will say “Let the engineers (or doctors, or designers, or whatever) run things” but when you do that you find a management style cadre arises who are experts in their own field. Being a senior engineer (or whatever profession) often means being a type of manager, they need their original skills but they also need some management skills. If they don’t learn new skills those people become bad managers.

Is all management bad? Or is it just bad management? Read More »