Moltke on leadership

Here's another post I wrote on our internal blog some months ago. I refreshed and updated it somewhat. Enjoy!

Lately, I've been reading a certain series of short stories and novels (Falkenberg's Legion, by Jerry Pournelle). I'm not really a fan of military novels -- fiction or non-fiction -- but I found some aspects of this series quite fascinating.

While software development is perhaps not as lethal as war, we have a lot to learn from the military organizations when it comes to leadership vs. management, unity of command, and organizational theory. Let's face it, armies are subject to heavy darwinistic selection. Survival of the fittest.

Towards the end of the series I found the following quote. Pournelle is in the habit of quoting long passages from various military theory and history books and I got in the habit of skimming those fairly quickly. The following quote is actually one of the shortest in the book and thus one of the ones I actually read, but the implications are worth discussing here:

"The advantage which a commander thinks he can attain through continued personal intervention is largely illusory. By engaging in it he assumes a task which really belongs to others, whose effectiveness he thus destroys. He also multiplies his own tasks to a point where he can no longer fulfill the whole of them."
-- Helmuth von Moltke

Note that Moltke says "intervention" not "attention". The fact is that our most effective leaders are those who pay attention to the work of their subordinates. A good manager sees what is going on and adjusts the system to promote correct behavior (such as distributed decision-making) and dampen incorrect behavior. Or as Ronald Heifetz says, "attention is the currency of leadership".

Our least effective managers (no-one named, no-one forgotten) are those who personally intervene in the work of their subordinates. By continuous intervention the manager is sending one message upwards and another downwards in the hierarchy. Upwards, the manager is saying that he is personally taking heroic action to ensure that the team is moving forward in the face of overburdening technical challenges. To the team, he's saying "I don't trust you to do the right thing". Any initiative taken by team members is subject to review and approval. Self-motivated individuals will search for opportunities elsewhere. The manager becomes the bottleneck that prevents the team from delivering, thereby closing the self-reinforcing loop.

If you were a mid-level manager and had two projects, one delivering regularly and effortlessly and the other subject to continuous difficulties overcome only by heroic efforts from the project manager and the team, which project manager would you consider more effective? Which one would you reward for doing a good job? Would you grease the squeaky wheel and let the silent wheel go uncared for... until it also starts squeaking?

The iron triangle

This is an updated repost of a blog entry I wrote in June 2010 on our internal blog, combined with some material I wrote earlier this week as a result of a good discussion with @duarte_vasco. Enjoy!

An interesting thought occurred to me last Thursday. You all know about the "iron triangle": out of scope, time and quality, you can pick any two. The reason why you can't nail down all three is the unpredictability inherent to software development.

If you have read your Fred Brooks, you know that software is invisible. Walk into a factory and you perceive noise, activity, movement. But walk into a software development office and you perceive silence, inactivity, stillness. A lot of things are happening, a lot of work is being done, but it is invisible to the naked eye. Fred Brooks says in his infamous essay "No Silver Bullet" that software is an abstract construct of interlocking data sets, data item relationships, algorithms and functions. It is "pure thought-stuff, infinitely malleable", complex, changeable, and invisible. These essential and inherent attributes makes software virtually impossible to visualize, model and understand.

Orthodox plan-driven methods attempt to nail down all three parameters. Since quality is the least visible of the parameters, it will be the one that fluctuates. Therefore in a plan-driven project, you set a Quality Manager to "manage" the problem of quality. Unfortunately quality management is a post-facto task; there's nothing much relevant a Quality Manager can do himself to improve the quality of the product. It's not like he's going to go and fix the bugs himself, right? He can try to prioritize change requests and bugs and increase visibility into where the product is. Another problem is that depending on how long your development cycle is i.e. how often you integrate your product and how long the system testing takes, the picture that emerges doesn't show where the product is, but where it was.

In Scrum and other Agile methods, we do it the other way around. We require high quality in a short time and let the scope float. The quality is defined and controlled using automated tests, and the timebox is defined as the maximum time we can keep change out of the project (or even better, as the minimum time needed to make something we can demonstrate and invoice the customer for). But we don't send out the scope to sea to float freely around, oh no! The key is that instead of letting the scope fluctuate randomly, we set a scope manager (actually, let's call him e.g. the Product Owner) to actively manage it. And this must be done ahead of implementation.

You see where this is going? Paradoxically enough, the Product Owner also prioritizes change requests and bugs (read: backlog items) and increases visibility into where the product is going.

So what's the difference between the PO and the QM? The difference is that the QM works in a system based on predictability, while the PO works in a system based on unpredictability. Since software development is fundamentally unpredictable, the QM tries to salvage the product afterwards, while the PO is effectively managing the product one step ahead.

And that, my friends, is it.