Category: General MWT Page 3 of 4

Manager veto and the management team cartel

On May 18, 2009

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.

No wrong way to slice the pie? (and do you even know?)

By mdegeorge

On May 7, 2009

In Collaboration Architectures, Enterprise Architecture, General MWT, IT Management, Multisourcing

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’)

Again, what is MWT?

By mdegeorge

On May 5, 2009

In Current Events, General MWT

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.

Not what, how

By mdegeorge

On April 20, 2009

In Current Events, General MWT

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 (and should be) boring!

By mdegeorge

On April 8, 2009

In General MWT

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.

Economics still isn’t a formula

By mdegeorge

On February 26, 2009

In Austrian Economics, Current Events, General MWT, Personal

Everybody is citing the article in Wired on the Gaussian copula function. Apparently, everybody had been applying some clever maths to finance decisions so they thought they had a mathematically valid way of making accurate predictions while eliminating most variables. It probably was mathematically valid. But was it ever economically valid?

The Austrian economics folks at the Mises Institute are basically saying that it’s difficult to imagine an Austrian economist, a reader of Human Action: A Treatise on Economics, to fall for the idea that a simple formula can predict the future. Boingboing, similarly, has suggested that the moral of the story is ‘STOP MATHS NOW!’ Which isn’t to say maths is bad – it’s just that it’s not really economics.

My take is that the Misians are right (again) and this is a failure in the understanding of economics, not a failure in maths or the creator of the formula. But I don’t have to make any comments on this because ‘Andrew’ has already said all I want to say in his comment on Boingboing:

#7 posted by Andrew, February 24, 2009 1:19 AM

Economics is not formulas. Economics is not higher math. Economics is not experimental science. Economics is not even quantitative. Economics is logic applied to the choices that people, and business, make constantly. The logic of marginal value, opportunity cost, uncertainty, and all the rest is as good as it’s ever been — it’s universal as long as time and resources are finite. It’s when you start to say that the demand elasticity of natural gas times the velocity of money, minus the consumer price index, is correlated to the relative humidity in china with r^2=.83, that you’ve fucked up irrevocably.

What’s this got to do with management? In management terms, applying a formula is never the basis of a capability. Like another great ‘Andrew’ said in a comment to my last post, the banks appear to have been saying ‘yes’ to anybody who asked for money – and now they are saying ‘no’. This itself is the simplest of all formulas – and it doesn’t in itself give you that all important capability of being able to differentiate between good and bad risk. And if you use a formula long enough you’ll loose the capability itself (if you ever had it).

I’m becoming convinced that the financial system is completely broken. One of the reasons that managers didn’t put the breaks on use of the formula is sighted in the Wired article:

In hindsight, ignoring those warnings looks foolhardy. But at the time, it was easy. Banks dismissed them, partly because the managers empowered to apply the brakes didn’t understand the arguments between various arms of the quant universe. Besides, they were making too much money to stop.

(See also comment here)

Note that they were ‘making too much money to stop’ and yet you might ask the intelligent questions raised here:

And one question:
I’d like for the knowledgeable people here to tell me what would have the banks done with all the money they had to lend if they wouldn’t have gone for the bad risk? Isn’t everybody so loaded with debt right now that there is very little good risk left? Was this crisis even avoidable?

These raise an interesting point – what do you do with ‘too much’ money? How, or why can there even be ‘too much’ money? If you are expected to make a certain return, to create a certain level of growth in any market conditions, then you need to spend or lend your spare money.

This is the obsession with growth that I think must end. We even define a recession in terms of a lack in growth – why does there always need to be growth? Also, if the government is fiddling with interest rates and indirectly providing cheap loans how do you as a business deal with sort of price eroding competition? Your forced to make dumb / risky decisions I guess – but perhaps you also start getting the wrong signals making it hard to make the right decisions.

The other point it raise is the different between earning money and creating value. The money that was risked on risky loans is now gone. Never mind the details but that value has been whipped from the economy. But the destruction of value coincided with the making of money. Again, something is wrong here. In this sense people were being paid for taking risks. This shouldn’t ever be the case – people should be paid for either creating value or because the risks they take paid off.

But there is more than one agent here. There are the employees of the banks and the banks themselves. Of course, you have to pay employees for turning up – even if they are risking money and eventually driving your business into the ground. So it’s not the financial folks themselves that are taking the risks. It’s the organisation. It’s the bank itself. It’s the process, structure, culture – in short, all the capabilities that make the organisation what it is – that by its very design choose the wrong people, had the wrong controls, gave incentives for the wrong behavior.

And yet – it’s the Banks that are getting bailout money! I can’t understand this. People don’t appear to realise that the institutional structure is temporary. The exact nature of who owns banks, who runs banks, the boundaries between banks, and the intermediation of different agents (existing or potential) is all we have when it comes to a financial industry. The only way a solution can possibly exist for any financial crisis is for the institutional structure that is overlaid over value to change. The only process that will cause universal (or at least, on average) improvement is to change this institutional and agent structure so that it works more effectively and so that more capable ownership and control exists.

Bailouts to banks will effectively allow the current owners of banks to continue to own the assets -despite- the fact that they have proved they can’t managed them effectively. This doesn’t stop at direct ownership – it also include the investors. If people have invested in banks that are not managing value correctly they have failed to invest wisely. A bailout helps them retain ownership -despite- making bad investment decisions.

If investors are investing in the wrong things, and if owners or corporations are managing assets ineffectively, or if risk is not being managed by a corporations capabilities the investment needs to not provide a return, the assets need to be moved (naturally, through sales) to somebody who can manage them, and different capabilities need to be engineered or given resources.

But – what is the magic formula for deciding all of this restrucing? Well there isn’t one – it just has to be allowed to happen doesn’t it?

PS. I’m not an economists so I don’t really know what I’m talking about.

TRIZ as a pattern language for problem solving

By mdegeorge

On February 7, 2009

In Christoper Alexander, General MWT, Personal

After watching Merlin Mann talking about the idea of creativity patterns today, I started reading through volume 16 of Make magazine. On page 57 there is a brief but interesting article about TRIZ.

TRIZ is an evolving set of patterns for problem solving which was first developed in 1946 by Russian Genrich Altshuller. It doesn’t appear to be fully available on-line. In fact, it doesn’t appear to be fully developed into a single definitive framework at all. Nevertheless it appears to have some interesting things to say about problem solving.

From the Make magazine article:

…Altshuller observed that the same problem types appeared time and time again, and yielded to corresponding generic solutions…

This echos with what Merlin was saying about creativity patterns in his Macworld talk. But how is this different to just knowledge? It isn’t, I guess, but these sort of endeavors open up the scope of what we believe it is possible to have organised knowledge about. They also standardise how knowledge is organised. Standardisation is important (in the sense that it allows efficient communication).

The essence of the TRIZ system appears to be utilising a number of patterns of interventions into a system in order to remove a constraint (or ‘Contradiction’) without compromising the system. To me this feels similar to the generative sequence approach of Christopher Alexander.

Alexander’s generative sequences unfold using a standard set of interventions into structure (which is system-like, I guess). Also, when the intervention is made you effectively check for ‘compromise’ when you re-evaluate the degree of life / wholeness in the resulting structure before moving on.

This idea of removing ‘contradictions’ in TRIZ also has echos of all that Ayn Rand ‘check your premises‘ talk.

Interestingly, I have always found the idea that contradictions don’t exist as very helpful in problem solving. Basically, I see them as a signal to break something up into smaller and / or different parts. I see disagreements between people as similar types of problems – and the breaking down of concepts into more elementary components usually means agreement can be found.

Of course, it doesn’t really matter if contradictions do or do not exist – the question is whether acting as-if they don’t exist is a useful problem solving tool. And I think it is.

So, patterns can help problem solving. And patterns are a ‘just‘ a way of organising knowledge. And problem solving is about making system or structure interventions and then making sure you haven’t destroyed the integrity of the whole.

Management of knowledge work is a lot like problem solving. So it’s likely to be pattern-based too. MWT Collaboration Architectures are patterns…

Traceability in enterprise architecture

By mdegeorge

On January 27, 2009

In Collaboration Architectures, Enterprise Architecture, General MWT, Technology-Enabled Business Transformation (TEBT)

Whenever I read about enterprise architecture I’m always struck by how technical the conversation seems. I’m not anti-technical; but in my mind architecture is more important than what we generally call management. This is also implicit in the principles of the MWT Model. It is in fact architecture which I see as the centrally coordinating mechanism of organisations rather than management.

This means that at the specific level at which you are coordinating the architecture needs to be understood by all participants – not just technical people. If the level of coordination is the executive team making IT investment decisions the particular architecture is the enterprise architecture.

Now I’m the first to complain when IT Management becomes a race to the bottom and when IT Managers wear the statement ‘I’m not a technical person’ as a badge of pride (isn’t management ‘technical’?) but I’m talking about something different and specific here. If enterprise architecture has an intended audience that includes so-called non-technical people it cannot be technical.

The problem is, I find that enterprise architecture is always defined as something too all encompassing. It is always defined inclusively of all the business processes, goals, objectives, technologies assets, etc of an organization. It’s almost defined as something that isn’t valuable until it is complete at all of these levels.

However, this causes immediate problems that are reflected in every analysis of enterprise architecture (or failures in EA effort) that I ever read. It always appears to be that EA efforts fail because they are not maintained, through ‘lack of governance’, or that they are misunderstood or ignored by senior management.

Analysis of EA effort actually spent is one thing, but other field reports indicate that the effort never even officially gets off the ground before it’s too difficult to define the ROI of the investment. Nobody seems to question the ROI of dedicating resources to blocking and passively obstructing enterprise architecture efforts but that is another issue altogether.

I think the solution to these problems is very simple. It’s a solution that eliminates the high-cost of enterprise architecture initiatives (and therefore the issue of ROI), it also helps incorporate enterprise architecture efforts into the rest of the organisation (therefore making alldesign effort enterprise architecture effort), and it takes enterprise architecture to the board room (or at least the CIO’s office) where it belongs.

The three fifteen step plan for solving your enterprise architecture issue is as follows:

Hire a real enterprise architect
Establish only ‘dotted-line’ reporting to the enterprise architect
Use the phrase ‘enterprise architecture’ only to refer to ‘enterprise business architecture’
Establish ‘planned traceability’ from the EA to project documentation
Establish ‘planned traceability’ from the EA to system documentation
Establish ‘planned traceability’ from the EA to software development life-cycle (SDLC) documentation
Hold a workshop to established a baseline enterprise [business] architecture
Schedule reviews of traceability each 6 months for each application system
Include traceability reviews in the organizations project methodology at each phase gate
Schedule a review of the baseline enterprise [business] architecture yearly
Report, monthly, all EA traceability analytics
Publish a quarterly analysis of EA traceability analytics
Publish a whitepaper on how to interpret EA traceability analytics
Co-sponsor at least one project concept / idea per year with a business growth outcome based on EA-level transformation
Sponsor at least one project concept / idea per year with a IT efficiency outcome based on EA analysis and / or improving one or more measured based on traceability analytics

The most important step here is that you are no longer defining EA as a complete, integrated, end-to-end, endeavor. You enterprise [business] architecture is complete by step 7 above. It’s done. The assumptions about how value in the enterprise is generated are defined. The definition of enterprise architecture is also re-defined as only the enterprise [business] architect + the planned traceability to other key assets. In this sense, your EA is complete.

Steps 8-10 ensure that your enterprise architecture is always up-to-date. But up-to-date shouldn’t be read to mean complete. The EA is up-to-date in the sense that the enterprise [business] architecture is up-to-date and you know the status of all traceability. Within the status of the traceability is the key to understanding how complete you understanding of systems is – including the completeness ‘alignment’.

Steps 11-13 ensure that the information in the EA is known, understood, and utilised for decision making. Steps 14-15 ensure that the enterprise architecture (and the enterprise architect) delivers value. It also allows for additional specific, targeted EA effort to be managed through the normal project approval processes.

If the following steps are followed – and this of course depends on you finding a ‘real’ enterprise architect to hire – you will be well on your way to best practice in enterprise architecture. More importantly, the communication and organizational engagement issues will be solved. If you have hired correctly, the enterprise architect will also be an enthusiastic and invaluable member of the IT management and / or executive team.

As far as EA becoming more valued than ‘management’, I’m not sure when this will happen. But if we can stop whining about how difficult it is to get EA established and get on with the job (see above process) we at least won’t need to defend our failed efforts anymore.

Structure of the MWT Model

By mdegeorge

On September 11, 2008

In General MWT, MWT Components

In the last post, we looked at the Context of the MWT Model. In this post we will look at the structure of the MWT Model. The diagram below shows the major components of the MWT Model; with the exception of the management transformation required to implement the model.

The components of the model are introduced on the main site here. Blog entries relating to each of the components can be accessed via the Categories list on the right-hand side of the blog.

An alternative view of the model can be seen in the figure on the right. This view begins to show the flavor of each component via the symbols that are used to identify each component.

The MWT Model is a management model. Therefore, like the management model it replaces, it must scale to any level within the organisation. While the model is presented here within the context of the entire organisation, the organisation actual contains multiple levels of the model operating in a fractal.

Powered by Qumana

Context of the MWT Model

By mdegeorge

On September 10, 2008

In General MWT

The MWT Model is a replacement for the standard management practices of an organisation. It is based on the same premises that recognise that market-based economies create value more effectively than planned economies.

In this sense, the MWT Model is the natural conclusion of applying the forces that drive globalisation, such as ICT (information and communication technology) advances and market liberalisation, inwardly. Rather than looking at how these effect and enhance the market outside the firm, the model provides opportunies to expliot them inside the firm (and across supply chains, of course).

MWT is also the natural extension of how more sophisticated, value-driven, collaboration and ownership is enabled by technology advancement. This is the same force that gave rise to national (and increasingly, competitive) stock exchange systems when information processing technology improved sufficiently to support such exchanges.

However, the MWT Model is not simply a vague regurgitation of the wonder of self-organising systems. At the level of the firm, globalisation and the relative freeing up of markets already provides a mechanism of self-organisation. Firms grow or decline through an increasingly effective (and sometimes harsh) market of self-organisation.

Instead, the MWT Model provides practical mechanisms for managing organisations – and for taking advantage of the very technologies which could otherwise threaten the organisation through increased and more nimble competition.

So while the MWT Model is a market-based management model, it is not a laissez-faire management model. Such a model would ignore the important structural elements of the economy which are already the result of the effective self-management of the boundaries between the market (the outside of the firm) and the organisation (the inside of the firm).

Rather than take the approach that their is no effective way to add value to firms via intervention, the MWT Model recognises that organisations must manage and maintain a specifically constructed competitive position, an effective relationship with targeted customers and partners, and deliver targeted value.

These elements represent the context of the organisation, and the context of the MWT Model. Because the context of the firm and the context of the model can be defined in the same way, MWT Model exists within a familiar context. This can be shown by the accompanying figure which shows the scope of the MWT Model in the context of the organisation:

Competitive Position
Competitive Value
Customers
Partners
Customer Value
Customer Life-Cycle
Customer Groups
Capabilities

This list represents areas of enterprise strategic analysis which are not part of the MWT Model, but rather they provide the context under which the model operates. The exception is ‘Capabilities’ which is significantly effected by the MWT Model’s capability engineering processes and focus on service-based management.

Now it’s time to drill down into what the MWT Model actually is. The following blog post, on the Structure of the MWT Model, will decompose the model into its main components: Operationalised Brands, Technology-enabled Markets, Collaboration Architectures, The New MWT Hierarchy, and The MWT Management Transformation.