Category: General MWT (Page 2 of 3)

Dan Pink: Management is a television set (i.e. technology)

From Dan Pink’s TED talk on “The Surprising Science of Motivation”:

“In the 20th century we came up with this idea of management. Management did not emanate from nature. Management is not a tree it’s a television set. Okay? – Somebody invented it. And it doesn’t mean it’s going to work forever… Traditional notions of management are great if you want compliance. But if you want engagement self-direction works better.”

Pink also introduces parts of his “new operating system for our businesses” based on autonomy, mastery, and purpose.

The specifics of Pink’s new operating system are interesting – but I think as values they are almost universally accepted. More interesting is the acknowledgment that you might install a new operating system into organisations to replace ‘management’ itself. This idea has been the premise of MWT from its inception (see here and here for example).

The general principle of the MWT Model is to replace planning, monitoring, and controlling with collaboration architectures, technology-enabled markets, and operationalised brands. The MWT Model also positions management as a technology rather than a class of individuals.

In a sense, Pink’s new operating model fits into the MWT Model by acknowledging management as a technology, replacing it with something else, and operationalising an internal brand based on the values of autonomy, mastery, and purpose.


Watch the full video below:


David Heinemeier’s ‘Unlearn Your MBA’ talk at Stanford

This is nice.

My favourite section:

“There’s no management when we’re three people. There’s no management when we’re 15 people. We still don’t have any managers hired in 37signals. Every single one of us are producers.

I’m still a producer. I still write code. Jason still designs. We still do all the stuff and management is sort of the offshoot of, “Oh, yeah. Sometimes we have to deal with issues that they come up.”

Problem is when you have actual managers, whose sole job it is just to manage, they make up [stuff] to manage because you’ve got to fill an eight-hour day.

And in the beginning, there’s 40 minutes of management every three days. That’s what you need for management. You do not need eight hours of management, which is how you get policies and all this other bull that crops up when people don’t have anything to do.

Idle managers are absolutely the worst.”

(this is cut-and-paste from the transcript so I can’t remember what particular exploitive they are editing when they say [stuff])


If an employee presses a green button and then an alarm goes off you’ll soon have a motivation problem.

– Posted using BlogPress from my iPhone

We should probably all read “The Capitalist and the Entrepreneur” by Peter G. Klein

I owe some of my interest in organisations to a guy called Peter G. Klein.

Over 10 years ago, when I first decided that there was going to be a shift in the skills required to be an effective manager in an environment of cross-organisation coordination and open information, and when I was developing the initial ideas around ManageWithoutThem, it was in part driven from something Klein had written.

Specifically, I was skimming through an article call ‘0530 New Institutional Economics’ that Klein had written for some sort of encyclopaedia of economics. (It’s still available here)

The article opened my eyes to the possibility of a deep understanding of organisations and the fundamentals of why they exist. Something told me that this was the fundamental economics of the firm and that the ‘managed organisation’ (in the sense that piles and piles of management books that I was reading at the time assumed) was an anomaly.

I’ve since learnt some more of the political dynamic that keeps organised managed; but I still believe the ideas introduced in the original NIE article by Peter G. Klein are the fundamentals.

I even found myself, when often disagreeing with something a manager had said, saying ‘you don’t have a valid theory of the firm’ – until I realised how completely ridiculous I was starting to sound…. 🙂

Though I never actually finished reading the article. To be honest I went on a 10 year tangent. But with the release of Klein’s new collection of writings I’ve decided I’m going read every word. I’d also recommend managers do the same.

Links to purchase and download for free are available on the blog: Why Klein’s Book Is an Event to Celebrate

Breaking down innovation accountabilities

I’m attending an ‘innovation workshop’ today.  I’m looking forward to it but it also feels a little bit dirty.  Innovation is important – but I’m not sure it can be managed directly.  Management of anything politicises it; but with vague notions like ‘innovation’ it’s hard to establish the accountability required to balance the politics.

The session today will interesting.  I’m sure we will have the inevitable ‘what is innovation?’  discussion.  But I’m sure the normal process of people wondering how this might help their career will interfere with that.  Also, participants come from multiple vendor and client organisations so this will limit the sorts of ideas that can be discussed.

I’m not lamenting this dynamic –  it’s a natural part of work life.  But the trick will be to quickly convert this forum into a set of processes that ensure value is directed towards the sponsoring organisation.  I believe breaking up ‘innovation’ into a number of separate processes for which accountabilities can be established is the answer to this.

My first cut of the breakdown is as follows:

  1. Idea management process (capture, rate, sponsor, formally reject, and reward/recognition)
  2. Scanning (internal and external scanning of practices, technologies, and trends)
  3. A formal approach to analysing the organisation
  4. Initiative delivery process (to manage sponsored initiatives)
  5. Slack for brainstorming and black-market idea generation

Some of these, such as scanning, may have separate accountabilities for each organisation (to create competitive tension).  The idea management process may be owned by the sponsoring organisation (to ensure transparency to the sponsoring organisation).  Items 3 and 4 are likely to be tendered.  Item 5 may be measured by the innovation forum but be considered an accountability of business units.

Explicit collaboration

MWT Collaboration Architectures are a critical component of the MWT Model.  In short, a collaboration architecture defines how individuals collaborate on a particular task.  As with most architecture work, the focus is on what needs to be shared and what needs to be standardised.

Collaboration architectures are not sequential (though there my be some shared sequences for some collaboration architectures) and importantly these are not collaboration processes.  Rather than roles and responsibilities their is just enough of a shared framework where the right roles and responsibilities emerge.  There is also just enough of a shared understanding of risks so that their is reward in putting effort into risk mitigation rather than an incentive to avoid working on activities with inherent risk.

It’s a simple concept but effective collaboration is not something the management discipline currently guarantees.  General management provides a mechanism for defining roles and responsibilities; project management provides a means of managing costs, schedule, and risks; and there are of course disciplines of around strategy to get things started, and conflict management when none of this works are it should.

But ultimately there isn’t a lot of focus on how individuals need to actually collaborate around a set of shared artifacts in order to get something done.  It’s been over-stated already – but this situation is not acceptable in the information age.  But nor has it been corrected by the information age.  Business process management (BPM) technologies are rarely implemented –  and when you look at the types of processes they are able to support (i.e. Non-collaborative) that’s almost certainly a good thing.

What’s more, managers themselves are currently facing increasing pressures from the communication technologies that could otherwise support more effective collaboration.  Management disciplines are sufficient if the right information gets passed through the manager.  But communication technologies, resource mobility, and distributed workforces mean this simply doesn’t happen.  Managers are left in a situation where they don’t know what is going on but are still responsible for it.

I’m seen managers response to this challenge in precisely the wrong way.  For example, consider the phrase ‘I only need to make sure my direct reports know what they are doing’.  I’ve heard this before and it drives me crazy.  This is like saying ‘I’ll just manage myself, not the organisation’.

In addition to the above sort of reaction I also see a lot of cases where managers simply refuse to integrate communication & collaboration technologies into their management process.  In this case, there is potential for transparency and technology-enabled collaboration but the managers don’t want to use the tools.  If the tools are then used in this environment the whole management process can break down because sufficient information isn’t passing through the manager.

I can already hear ‘tools wont solve this’ echoing in my head as I type.  This is partially true but the management discipline itself is a tool.  All those catch-phases like ‘we need to work together’ and ‘I don’t want to get involved in the details’ are tools.  Similarly the phase ‘make sure you CC everybody in the team on every email’ is a tool.  But they aren’t tools that help the organisation!

Introducing Human Interaction Management

As I’ve been working through MWT Collaboration Architectures I’ve come across some work on Human Interaction Management (HIM).  I’m please to note that work in this area has a lot of similarity to the MWT Collaboration Architecture approach.  I’m sure it also has adoption challenges as per the discussion above.

If you’d like to read more about HIM try the following links:

‘The First Step for BPM is HIM’:

A ‘Human Interaction Management’ portal:

Google Docs isn’t the answer:

Work 2.0:

“Why Workflow Sucks”:

Presentations and podcasts for people who don’t read good:

The book:

Project Managers Should Not Fear the Baseline | CIO – Blogs and Discussion

There is some wisdom in Jim Vaughan’s article and the related comments:

The poor performance of the project usually has less to do with the project manager or the project team and more to do with the systemic failures of the organizational culture to provide the proper tools and governance to allow the projects to succeed. These systemic issues really become the moose on the table that no one wants to talk about. As a result the PM and/or the project team are blamed for the failure.

via Project Managers Should Not Fear the Baseline | CIO – Blogs and Discussion.

The Professional Mess

There is a very interesting interview with Dr. Thomas Dorman on the Lew Rockwell podcast entitled ‘The Medical Mess’.

Dr. Dorman talks about how placing an intermediary between a professional (the doctor in this case) and their customer (patient in this case) destroys the relationship between the doctor and the patient.

I think anybody, not just Doctors, who considers themselves a professional will recognise the sentiments Dr. Dorman highlights as common to the experience of being over-managed and under-lead in many a large organisation.

In summary:

  • The intermediary breaks the clear ‘point of transaction’ at which point the consumer owns the service provided – creating arguments and errors which then require regulations
  • Regulations require the professional to ‘code’ medical conditions and categorise medical conditions based on the codes specified by the intermediary
  • Because payments are made based on these ‘codes’ it forces the professional to spend considerable intellectual effort on the management of codes – at the expense of spending intellectual effort on the service
  • Also, ‘if there isn’t a code for something there isn’t a service’. So ‘codes’ must be manipulated to order to produce ‘a fair outcome’. This creates mistrust amongst all parties.
  • Professionals then spend time ‘documenting things to the satisfaction of the inspectors’ rather than working on services. This amounts to ‘costs escalating exponentially’
  • This intermediation process is ‘known not to work’ in that it doesn’t create a more effective services. So ‘there must be an agenda’
  • This agenda is ‘control, rather than providing quality services’

Sadly, Dr. Dorman passed away earlier this year before I even listened to this podcast.  The ideas, as always, live on.

Technocracy and Politicisation

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…

Manager veto and the management team cartel

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:

The 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.

Page 2 of 3

Powered by WordPress & Theme by Anders Norén