In a previous post, What is the leadership style in your software teams ?, I discussed about four key types of leadership and their evoluation, and how it could possibly relate to software teams. In this blog post, let’s dwell on this topic further, and explore how to decide what leadership style suits a given situation. The assumption here is that there is no such thing as an “all-weather” or a personal favorite leadership style – each tool and method has pros and cons depending on why, how, when, what and where they are applied. The value one derives depends on how well a given style ‘fits’ the context – to that end, it it highly imperative to identify the ground conditions and only then decide what could work here more effectively.
Our industry has a difficulty articulating with what type of leadership we want to have. We surely don’t like the ‘Great Leader’ or the ‘Command and Control’ leaderships (discussed in my previous post). We believe this leads to a highly autocratic or centralized organizations which is the not the best way to manage highly educated, unapologetically assertive and fiercely independent knowledge professionals. We feel empowerment is the way to go, and eventually want to be able to manage own destiny by ourselves. There is a fair amount of consistency in these thoughts among young professionals cutting across countries and cultures. This should make the task for managers easier, because they kind of know what is expected of them, and all they need to do is to just do it! However, like every management advise, it is easier said than done. For one, most managers from the shop-floor era of management might not be skilled or ready for the new-age management mantras. They might feel insecure letting go of almost all their authority, or might feel underconfident about younger professional’s competence, or some other reasons. So, that’s one part of the issue.
Second part of the issue is how young professionals want their leaders to support them. Contrary to most people’s beliefs, everyone does want someone ‘above’ them to support them when they are need help, give them some directions when they are doing something for the first time, give them feedback when they have done something, shower them with praise and recognition when they accomplish something, and (surprise ! surprise !) even pull them up when they mess things up (of course, not in a way that kills them, but in a way that lifts them).
Most managers understand these intuitively or learn them from the school of hard knocks. First-time managers often have the tendency to either overcontrol the team (by using management tools such as “death by process” or “death by compliance”) or the other extreme end to overappease the team. We have seen them in all shapes and sizes. What I found is that people generally tend to overcontrol because they don’t want to fail, and want to do everything possible to ensure that projects stay on tracks. It is not so much about them not trusting their teams, but more about whether the project will be completed successfully if they are not involved. They want to look good to their seniors that by making them the manager of this project, they did not make a bad decision. Some managers share their solidatiry by following every process to the hilt, some will overstuff their plate full of every possible requirement because they don’t want to be seen as the project manager who says ‘No’ to a customer, some might make the team work extraordinaliy hard over weekends so that upper management sees their ‘commitment’ to the project and the organization. They probably believe that overcontrol and being a tough manager can solve all people issues on a project.
Other type of extreme behavior is about turning the team environment into an Osho commune. The idea is to ‘buy’ motivation to the task, commitment to the organization and loyalty to themselves by ’empowering’ the teams. Most people will never admit that they are ‘buying’ motivation, commitment and loyalty from the team but that’s what it is more often than not. After all, the are not ’empowering’ their newly assigned teams on the basis of their merit and performance just yet, so that else could explain their motives? I have seen managers who were technically or managerially weak buying their team’s respect by trading their authority. I have seen managers who do not want to spoil their relationship with team members (especially low performers) using this strategy. They are trying to ‘please’ everyone on the team. Obviously they haven’t heard “I cannot give you the formula for success, but I can give you the formula for failure: which is: Try to please everybody” by Herbert Swope.
Surely, this is a continuum with these two being its extreme ends, and the right way is somewhere in between. However, what might be the ‘right way’ for some might not be seen as the ‘right way’ by another. To illustrate what I mean, look at the same behavior but which could mean entirely different things to different people:
Behaviour 1: A manager is heavily involved working with the team in discussing and resolving every single issue, looks into the details of every single decision, participates in all estimations and commitments, sits and writes code and reviews it, etc.
Interpretation 1: She is a great leader. Supports us in all our problems, gets involved, and an eye for details. By getting involved in the commitment-making process, I feel more secure that I won’t be blamed for any issues, and that my manager is in it with me. She still knows the entire code by heart!
Interpretation 2: She doesn’t trust us, and gets involved in every single issue. There is no freedom to do what we want to do. I would say she micro-manages us. If she also contributes as an individual performer, she should be one of the engineers and not a manager
We have a manager here who might have felt her involvement with the team will be welcomed. She might have had her own reasons to get involved (maybe new project for the company, very critical, high expectations, her own views about team being capable of executing it, etc.) but different team members are likely to view it differently. Similarly, let’s take another case on the end of the spectrum:
Again, the behavior of this manager is likely to be interpreted differently by different people in his team, irrespective of what and why he thinks about it.
Clearly, these trivial and overexaggerated examples do highlight the fact that a singular style won’t serve all needs well. The need is to identify an approach that individual people could relate to personally, and feel that their concerns and needs are addressed individually by the leader rather than being met with collectively by the leader (which essentially means that no one’s needs are being met, because an ‘average’ by definition is at best a numerical compromise what falls short of numbers higher than it and scores higher than number below it, thus matching none of the numbers).
Hersey-Blanchard Situational Leadership model serves as a great example to address this dilemma:
Essentially, this recognizes the fact that ‘followers’ undergo development in stages when following a leader, and based on where a follower is in the stage of development, a leader must modify his leadership style. As we see in the Situational Leadership model, a leader adjusts his style (from quadrants S1->S2->S3->S4) from ‘Directing / Telling’ style when his followers need very high direction but not so much of support. This is pretty much a one-way, centralized leadership that realizes the fact that followers are not skilled enough to decide for themselves, and hence must be clearly guided on their tasks.
As the team matures and is able to understand much of task requirements, they require lesser direction and are able to contribute to tasks in terms fo ideas,knowledge and skills. This turns the communication into two-way and requires the leader to get into a ‘Coaching / Selling’ mode.
As the team matures and requires lesser of directions, the leader changes gears again and gets into ‘Supporting / Participating’ mode where more responsibility has been handed down to the teams but the overall control still remains with the leader.
Finally, when the teams have grown to the stage where they are self-directed, they assume decision-making from the leader, who is only involved when the teams want him to get involved. At this point, the leader is in ‘Delegating’ mode and has delegated responsibility as well as authority with his followers or the team.
As we can see here, the ‘power’ of a leader is gradually shared with the team as they develop. This model is cognizant of the fact that no one behavior could suit every situation – it all really depends on where the team is at this point of time. Of course, the leader is also responsible for developing the team from R1 through R4 and in that process, he must be prepared to ‘lose’ his traditional power and authority to the teams. In a way, he must work towards making himself redundant! But that is what transformational leadership is all about.
Some interesting and important observation from this model:
However seasoned a leader might be, she can’t always start operating in a particular quadrant in which she is currently operating, or is proficient in. When being part of another team, she must analyze the follower preparedness and readiness before directly getting into the empowering mode lest that be midsunderstood and create a chaos.
There is nothing good or bad about a given leadership style. Like a right tool in the right hands, it must be seen as the right response to a given problem. So, if some manager comes across as a ‘Telling’ manager, that might not necessarily be a bad thing.
Leadership style mismatch typically happens when the leader opens the floodgates a little too early for the team to handle. This could result in a chaos, as the team has not yet had the opportunity to transform itself into a high-performing self-organizing team. On the other hand, other leadership dysfunction is about not letting it go even when the team has demonstrated its ability to manage its own fortunes. We took those examples earlier in this blog.
There might be individuals with high competence in their functions, but what matters in our context is the preparedness and readiness as a team. There will always be individuals in any team in any stage who will either be very self-directed (and hence, not very open to being directed) or highly dependent for directions. A leader’s job becomes difficult because she must not only maintain a particular leadership style to suit the team development stage, but also make adjustments as per the individual differences.
To be a good leader, one doesn’t always have to be in S4 quadrant. One could be in S1 quadrant and still serve the team with excellent results. Similarly, a bad leader doesn’t always have to be always the one who is seen as wielding control over the team, say, in S1 quadrant. A leader operating in S4 quadrant could come across as an incompetant leader.
Finally, (a) organizational culture for decision-making (centralized vs/ shared), (b) risk apetite and (c) the task under question will also determine how much ‘allowance’ a manager has in developing his team and sharing decision-making with them. This model dosen’t factor-in those external environment factors that will often have an overriding influence on the development of leadership, often even when the team has (or has not) matured to a given level of readiness.
We have barely scratched the surface with this discussion. Surely, there are many more critical factors that will eventually determine (a) which leadership style an organization will let a manager decide, and (b) how successful would that be. Some of these might help us understand better why Agile adoptions don’t always work in some organizations, or why some organizations prefer a formal project management method. At a team level, this model could also help us understand what type of team members are likely to be motivated and productive and what type of team members are likely to become disenchanted and eventually leave the team or the organization.
How do you go about determining leadership style on your software teams ?