What can Legitimate Leadership, and Agile learn from one another?

It seems sensible. If it’s results you want, then that is where your focus needs to be – on results. Further, the more you want the result, and the more important it is, the more single-minded your focus needs to be. In fact, this seems so sensible that it is literally the way which most people and organisations currently operate. It is evident in the way we lead, the way we organise work, the way we design incentive systems, the way follow. For more than 30 years it has also been central to the way we design and build IT systems. But there is change afoot.

For a little over a decade I have worked with the Legitimate Leadership Model (which itself has a history of more than 25 years). Amongst other things, the Legitimate Leadership Model argues that a single-minded focus on the end result is problematic; especially one which fails to explicitly recognise the importance of the actions, motivations and learning which ultimately combine to deliver the outcome. Make no mistake; the result is still important – very – but rather as a means than an end. More on that later.

The other area in which I have worked and studied over the past decade (more like 20 years actually), is Information Technology; primarily as a consultant. I started my career as a firm believer in the power of detailed planning. Treat a project as if it’s just a set of steps towards an end. Understand every aspect of the end-point in painstaking detail before you even start. The better you can predict the future, the better will be your end result. I should have seen the warning signs, especially in that last thought. Predicting the future has its challenges! Today, as with the Legitimate Leadership Model, I have learned that a single-minded focus on the end result in IT systems development often creates more problems than it solves.

So here we have two separate disciplines – leadership and software development – that have reached the same conclusion regarding the result: keep it in mind, but understand that it is actually just the outcome reached because of the incremental contribution made. The contribution, or value adding activities that make up the whole deserve at least as much attention as the end-point. In leadership it is the foundation of what we call the Legitimate Leadership Model. In software development this insight falls under the heading Agile.

What I find remarkable about these two distinct areas of my work, is that they reach the same conclusion, but by very different logical paths. The beauty is that by taking different paths, each holds potential lessons for the other. That is what I think is worth exploring.

The Legitimate Leadership Model

Let’s start with Legitimate Leadership. When we see leadership as an activity centred on achieving results through people (the conventional view accepted by thousands of people in Legitimate Leadership workshops over 25 years), we reduce people to the state of machines. If we were able to programme people, and separate their labour from their “self”, this might be a productive definition. However, as we can’t ask people to come to work whilst leaving their “selves” at home, we have a problem. We need to do more than just tell people what to do. Effective leadership is about enabling people: engaging their hearts and minds as well as their bodies. Legitimate Leadership understands that if it is willingness that we’re after (and it certainly should be!) then the people need to be the end. The job, or task, or outcome, or result, is simply the subject matter we can use to achieve great people. Wonderfully, experience has shown us that treating people as the end, as it happens, also yields the best results.

Agile

Agile software development has a different, but equally compelling argument against a single-minded focus on the end-point. Most Agile-promoting arguments that I have heard centre around uncertainty and waste. Personal motivation of team members is cited, but in my experience more often as a by-product than as a pivotal theme.

The simplified argument goes as follows: the world is so complex, and changes so quickly, that by the time the system you so painstakingly designed is implemented, it is no longer relevant. Or perhaps it’s only 50% relevant to the new reality. Combine that with the idea that often, even with a reasonably predictable future, the people involved in the design and build phases simply can’t deal with the complexity of real-world conditions (this applies in even the most intelligent multi-disciplinary development teams). You might have thought you needed all 100 reports designed into the system, but in reality only 10 of them are ever used. And only 5 of them add more value than the effort taken to generate them.

So, what can we learn?

To answer this question, one can ask quite simply, what if each argument was applied to the other? What if we considered Legitimate Leadership, but applied the arguments associated with uncertainty and waste? Well, let’s start there.

A compelling reason to do Legitimate Leadership is that it delivers a better result because it allows adjustments for uncertainty, and reduction of waste

I would argue that this statement is true. Most organisations that I have worked with have targets which are set annually, and which are perhaps adjusted once during the year. Even when a six-month adjustment is allowed, that is still a pretty long time in most markets. We have all seen market and internal conditions change much more rapidly than that. In addition, one must have some level of clairvoyance to anticipate exactly what contribution will lead to what results. For the sake of argument, let’s say that you do possess such clarity about the future. Have you ever considered what happens to initiative, innovation and constructive risk-taking when your managers claim, or pretend, to have all the answers in advance? They all but disappear. And so does your competitive advantage.

Reduction of waste is an obvious one. How many of those “100 reports” could be eliminated, and how many hours of number-crunching, if we weren’t on a continual mission to ensure that our results-based incentive systems accounted for every possibility. Incidentally, much of the incentive system tinkering which we try is quite literally futile anyway. The reasons that the result might not reflect someone’s contribution include: collective impact on results, “black-swan” events, inappropriate contribution in the first place, time lags, new appointments, resignations, market conditions, economic conditions, etc. As soon as we think the list is complete we think of another scenario – another reason that Freddy in sales managed to hit his target without doing any work. Or vice versa. When will we accept that the world is simply too complex to fully describe, and too uncertain to accurately predict? When one thinks about it, it is hard to get around the idea that contribution simply has to be continually assessed and addressed. In Legitimate Leadership terms, leaders have to Watch the Game (carefully!) and then hold people accountable for what they have actually contributed.

Given the above, it is clear that one could construct a solid argument for Legitimate Leadership on the basis of “better outcomes due to better management of uncertainty and reduction of waste”. Whilst I wouldn’t argue for these as your primary reasons to do Legitimate Leadership, they are certainly worth bearing in mind when considering performance management processes during a Legitimate Leadership implementation:

• Review the standard regularly, allow for flexibility and don’t make the period of assessment too long (i.e. learn from sprints); and
• Assess the contribution made continuously by watching people perform in a “live” environment (i.e. get feedback from their actual interactions with their actual customers – internal or external).

So, Legitimate Leadership can learn something from Agile, but is this true the other way around?

A compelling reason to do Agile is that it promotes willingness in your development teams

I think that this can be true, but it is not necessarily so. Agile talks about valuing “Individuals and interactions over processes and tools” and the necessity of building project teams around motivated individuals. It also talks about “giving people the environment and support they need, and trusting them to get the job done”. But what happens when the job doesn’t get done? How do you go about building trust? Is giving people the support they need equivalent to Care in Legitimate Leadership language?

Agile environments are well-positioned to generate willingness because Agile specifically argues against prioritising control. However, Legitimate Leadership argues two things directly related to control. 1) Control must always be replaced with accountability and 2) control must be incrementally suspended, not removed all in one go according to a methodology change. It is a good thing to trust people to get the job done, but Legitimate Leadership argues that the following criteria need to be considered:

• Does the individual have the means to do their job?
• Does the individual understand why their job is important, and how to do it well?
• Does the person have a level of maturity which is appropriate to this level of trust?
• Am I (or is the team) willing to hold this person accountable both positively and negatively?

If the answer to these four questions is “yes”, and if people in the team genuinely care about the wellbeing of others in the team, then Agile has huge potential for promoting willingness – specifically because it argues against control and prioritises contribution through sprints over the eventual outcome. However, if any of the above four items is not in place, Agile may well be just as good at producing “victims” as any other software development approach.