I’ve mentioned one of my theories before:

I have a theory that whenever a single specialisation becomes the dominate or controlling specialisation it turns the coordination into a technocracy.  I might be using technocracy in the wrong sense but I’m using it to mean that a single specialisation (i.e. a single branch of technical knowledge) becomes dominate.

It is in this sense that I believe organisations are largely technocratic if they are run by technical specialists called ‘managers’.  In another example, I think this is part of the process that has occured to create the current ‘crisis’ in the financial services industry:

In this case, rather than financial knowledge acting as just one input into decision making, and as just one service available to individuals, financial knowledge became the single dominate knowledge used in decision making.  This in itself was a problem because it interfered with true and proper determination of ‘value’.  But it would also have the effect or corrupting the body of knowledge itself (perhaps not in the textbooks, but ‘in use’).

Eventually, the knowledge of finance not only supersedes all other knowledge, but the finance knowledge actually disappears as it is replaced with what is convenient or beneficial to those in finance.  This process could be a simple as people entering financial jobs even though they have no passion or knowledge of such things because that is where the money is (literally in this case, but it doesn’t have to be that way).

There are two sides to this coin that should be understood.  The fact that control by specialists is the dominant coordinating mechanism in a society (or an organisation) is bad for the society itself. This is basic technocracy.  On the other side of the coin – this control by a particular specialisation is bad for the specialisation.

It’s not that the people who are part of the elite and elevated specialisation don’t have any power.  They do have power, and they can have certain privledges.  However, the actual specialisation itself is hurt.  The knowledge in that specialisation is corrupted.

Not only is the knowledge in the specialisation corrupted, but the group of specialists is itself politicised.  I don’t just mean it becomes a ‘hot topic’ but that it becomes focused on power relationships.  Now I’m not saying anything new if I’m just say that management is political.  Everybody knows this.  But there are deeper, but related impacts of this politicisation process.

In addition to the corruption of knowledge, the politicisation of a group effects the way the group is entered or exited, the amount of diversity tolerated in the group, and ultimately the ability to make non-incremental impovements in performance.

If you understand that open systems (i.e. low political / legal barriers to entry and exit) are good over time, and that diversity is good (again, over time), and that operational innovation is good (if you can even tell when it’s occuring!) then you can see that politicisation is bad for the group and the organisation it supports.

Example from software testing

To use an example that not simply about general management – let’s look at testing.  I’ve spent some time over the years setting up testing capabilities – either for individual projects or across organisations.  I’ve also watched others do the same.  One of the mistakes that is often made during this process is to not hold the testing team to the same standards as developers.

As background, a testing capability provides an independant verification of the software that has been developed, often also ensuring it works with other software developed by other groups.  The purpose of this process is to find issues with the software, but more fundamentally to manage the completeness of the project.

Fundamentally, test management isn’t so-much about finding defects as it is about continuously asking ‘Are we finished?’ and then ‘If we don’t know if we’re finished how can we find out?’ and then ‘Are we finished finding out?’ and then ‘Are we finished?’…

In order control this process there are a number of rules the testing organisation needs to place on developers.  These rules ensure the software doesn’t change in an uncontrolled manner while it’s being tested.  For example:

• developers should check their own software first, then we’ll check it
• once the testing team is checking your code, you can’t change it
• the testing team will tell you if you have to change your code, and we’ll say it was a defect
• once you fix the defect, you have to check your code again before we check it

These are good rules.  And they work together to provide an element of control and governenace over the software development process.  They provide a gatekeeping mechanism at the end of a project that, if used effectively, will reduce issues with live production systems.  Though the process itself is very expensive (but that’s a different issue).

The problem occurs when the testing team doesn’t hold itself to the same rules.  Examples of this include the case where a defect is raised in error because the test being perform was itself incorrect. This is still a defect – in this case a defect in the test itself – but the testing team doesn’t like to see it that way.

A more subtle version of this is that the defect is never raised but rather the test is changed without a defect being raised.  In this more subtle example the testing team is not holding themselves to the same stardards they hold the development team because they are changing something without a defect.

The testing team sees these decision as ’saving time’.  But the governance issue is that the testing team are not being ‘tested’.  These means that the testing team have no objective criteria for performance management. They have been elevated above the rules.

By elevating the testing team such that they have special privledges – i.e. that they don’t have to follow the rules – the group becomes politicised.  People who want the special prevlidges enter the group, the knowledge of testing becomes corrupted, and operational innovation is restricted as the group uses its power to focus on changing others and not themselves.

All of these ‘problems’ are not problems if you are in the group.  However, the testing group will be different group then had it not be politicised, the performance of the group may not be as it would have been, and the overall performance of the organisation that the group is a part of may also suffer.

This is melodramatic in many ways.  Because these things will only occur over time, and only if all others things are equal.  In reality other groups and specialisations will compete for power and the dance continues…

Interesting:

First, contrary to popular interpretations, the blame for the panic cannot primarily be placed on irresponsible bankers: they responded rationally to the subsidy for credit created by central bankers.

Second, Prime Minister Kevin Rudd is clearly wrong in attributing the crisis to policies that reflect the neo-liberal views of free marketeers. Few if any supporters of free-market policies believe there should be no regulation of monetary conditions. (emphasis added)

There is an interesting lesson about management intensions at the Management Skills Blog.   It serves as a good example of how management teams act like cartels (if you use my analysis approach):

Noble Intentions

Thu, May 14th, 2009 by Tom Foster

In 1948, in London, Elliott began to work closely with the Glacier Metals Company, a manufacturer of precision steel ball bearings. It was a company of some size and technical complication, with different departments, a complement of engineers, a management team and a president named Wilfred Brown.

Like most companies, each week or so, a high level meeting took place, called the Management Team Meeting. It was Wilfred’s intention to purposefully build his executive team by including them in on the company’s largest problems to be solved and decisions to be made.

The executive team responded with enthusiasm to be included in such important activities. By harnessing all the brain power in that room, certainly, they could tackle the toughest challenge and make the best decisions.

The intentions were noble.

As time went by, however, the productivity of the group began to wear thin. In their efforts to reach consensus, to be cooperative and supportive, to be the team they intended to be, the pace began to slow. Discussions became arguments, agendas became political, quid pro quo became active.

And then, the unthinkable. The group would finally arrive at its decision and Wilfred Brown, the President, would invoke his veto.

- from Management Skills Blog ‘Noble Intentions’

My comments are:

May 18th, 2009 at 4:44 amThe problem is the concept of the ‘management team’ itself.

In my analysis a management team is a cartel!

Which means that when a management team come to agreement – meaning they come to agreement on the value of certain actions and decide the most appropriate action based on their combined assessment of the value of each alternative action – then they are in fact breaking the ‘price system’.

In a real cartel this means they agree on a price, bypassing the price system, and hurting consumers.

In the ‘management team’ cartel they are agreeing on the next action, bypassing the planning process, and hurting capabilities (and consumers).

I’m interested to see how this lesson plays out at Management Skills.

Management, as a discipline, has a problem it can”t solve.  It needs to coordinate separate but related activities caused by the division of labour.  And it needs to be able to do this regardless of how labour is divided.

Project management, in particular, has this problem.   I’ve said before that project management is a perfectly reasonable discipline as long as it doesn’t try to cross organisational boundaries.  This is why project management is necessary but not sufficient in managing outsourcing.

Likewise, program management – which the discipline likes to define as the management of multiple related projects – isn’t really a separate discipline because of the scale of the work or the number of projects, it’s a separate discipline because multiple projects have multiple project managers.

Unfortunately, the accepted tenets of management simply do not scale.   Multiple managers causes more problems than they solve – and therefore situations which require multiple managers need other practices to govern them.

The root of this problem is that ultimately, the discipline of management doesn’t in itself offer any useful advice on how to divide labour.   It takes it as a given that labour is divided and then attempts to coordinate that.

Equally, managers – when you switch them on and give them responsibilities – tend to manage to those responsibilities.  Good so far, but if the division of responsibilities isn’t right there is a problem.  The problem might even get bigger if the managers are better.

But there are right and wrong ways to divide labour.  Some activities are autonomous and some aren’t.  Dividing management responsibilities and activities has its own additional challenges.

Only ‘architecture’ (which I define in this context as deliniated shared understanding) can offer any help in the actual division of labour.  However, architecture must be domain specific.   In order to determine correct/incorrect or efficient/inefficient divisions of labour it must take into account the domain and the required outcome.

(by the way, if you think a ’strong management team’ solves this problem check out my article on ‘Management Teams as Cartels’)

Mainstream economics is not the cause of the current financial crisis – rather, the cause of the current financial crisis and the cause of mainstream economics being mainstream are the same.

(article to follow)

Leadership is knowing what needs to be done before you see the ROI calculation

I’ve written a few short descriptions of the MWT Model over the years.  I just submitted the following to ValueBasedManagement.net:

ManageWithoutThem is firstly a theory of how organisations actually behave, rather than how managers should behave.  Secondly, it’s a redefinition of the management process so that it benefits the organisation as well as managers themselves.  It re-intermediates management processes and refactors those processes without the implicit role of a separate management class.

Managers still exist in the organisation, of course.  But the the principles of market analysis are applied to the inside of the organisation to allow greater transparency of operational activities without filtering all measurements through management hierarchies.  Rather than flat organisations, the model allows for the accountability of hierarchy without the politics of hierarchy.

The ManageWithoutThem model redefines management as a technology that collaborating individuals share – allowing for the possibility of improving that technology in terms of efficiency, usability, and integration with other technologies.

Check out ValueBasedManagement.net – it’s filled with managemeent techniques, theories, and models.  This isn’t a critisism of the site at all – but it makes you realise how fragmented and specialised management has become as a profession.

Just like there is always an excuse for more government spending, with such a wide range of management techniques available there is always an excuse to do some more ‘management’.

The term technical is often misused, and used only to apply to engineers, but the management profession itself has become technical in the true sense.  Nobody would argue against the fact that much of that management knowledge, even when it’s correct and useful, is technical in nature.

This means that modern organisations are basically technocratic.

Management is not never having to say “this is bullsh*t”.

I’m reminded time and time again that the problem is not what you are managing it is how you are managing. It doesn’t matter if you add projects, communications, services, risks, etc, etc, etc to the list of things you are managing. All you are doing is increasing the amount of activity that requires a manager – or, in the worst case, increasing the amount of management activity proportional to other activities. You need to change how you manage!

Management is boring!  It, in fact, should be boring.  Not only that – you know something is ‘managed’ when managing it becomes boring.  But the problem is that we all crave excitement and we all want to be the hero.  So managers make management much more interesting than it actually should be.

Imagine, because this might never happen, you have just left work on a six week holiday and you are uncontactable.   There are a number of small projects in flight which you have left behind.  But you know these projects are okay because the management of them is now boring.  When you discuss them with the team the conversation essentially follows patterns which include ‘we are doing the next step in the plan’, ‘we have an issue and it’s with the appropriate owner’, ’some specific task is delayed because we were performing other more important activities’, or ’some specific task is delayed so we are spending more time on it instead of some less important task we were going to be working on’.

Getting to the point were these patterns of communication could be used wouldn’t have been easy – it never is – but getting to that point was the real work, was the interesting work.

When management becomes interesting is when there are no shared understandings of the priority of tasks, so there can be no genuine communication regarding ‘more important’ tasks.  Equally, management is interesting when as issues occur there is no shared understanding of the ‘appropriate owner’ so no communication at that level can occur.  It’s really intesting from a management perspective to have to have a long detailed conversation to find the ‘appropriate owner’ in each individual case – but do we want it to always be that way?

The point I’m making is that when management is clear the actual process of managing isn’t very interesting.  The problem is – when you’ve worked hard to become a manager you want your job to be interesting.  You don’t want to just be shuffling paper, ticking boxes, etc.  

But there are only a few ways to make things interesting: get into the work itself, or make the management process interesting by complicating it.  But getting involved in the work isn’t always helpful, and intersting management, exciting management, frequently changing management, is usually always bad.