24 Jun 2008

‘Managers and Minions’ or ‘Talent and Admins’

It seems in software development, and in the general world of work there are two views of how best to structure organisations. At one end there is the ‘Managers and Minions’ view and at the other the ‘Talent and Admins’ view.

In the ‘Managers and Minions’ view, managers orchestrate the world of work, they establish what needs to be done, when it needs to be done by, and then assigns that work to interchangeable minions. In this world, the ‘doing’ job is a rather junior role within the organisation, and the career objective is to progress from a minion implementer to a ‘big picture’ manager. Successful workers in these organisations spend only a few years of hands on work before progressing to more hands off senior role.

In the ‘Talent and Admins’ view, those that do stuff (i.e. the talent) are the valued players who take the initiative, establish what needs to be done, when, and then does it. They are assisted in doing this by their admins who take care of the bureaucracy and the talent focus on their work. In this world, the ‘doing’ job is the first class role within the organisation, the career objective is to progress from an apprentice to a master. Successful workers in these organisations can spend their entire careers mastering their craft and being rewarded for that mastery.

Increasingly, I am of the view that organisations need to towards the ‘Talent and Admins’ end of the spectrum to fully take advantage of Agile principals and practices. Those tending toward ‘Managers and Minions’ will struggle with challenges that simply do not exist in the world of ‘Talent and Admins’, for example:

  • ‘Managers and Minions’ oriented organisations are by nature bureaucracies. They will struggle more with fundamental agile values such as “Individuals and Interactions over Processes and Tools”. They are more likely to attempt to mandate the “adoption of agile processes” rather than simply “be more agile”. Techniques and practices that may normally be adopted experimentally or as a means to an end and then discarded become locked in as ‘the process’.

  • In attempting to control both process and the architecture landscape there is the tendency to enforce standardisation, regardless of consequences. This can be seen in the amount of red tape to get anything done. Practices and technologies become locked down, requiring infrequent high risk overhauls rather than a continuous evolution. Because of this risk, these decisions tend not to be made by the minions but by their superiors. Processes and tools imposed on the minions are often poor when important decisions are made to insulate the decision maker from blame.

  • By treating their minions as “interchangeable units of work”, it becomes attractive to push for economies of scale. This leads to the establishment of standard pay grades, locked down desktops, outsourced tech support, and single supplier agreements. At best these act as barriers to change. In cases where that change is inevitable they can easily force diseconomies of scale.

  • It is hard to attract good individuals to work as minions. Good people like to choose their own tools, to ‘own’ their process, and to work with appropriate technologies. They need to able to negotiate financial and non-financial rewards based on what they are worth; in the same way as senior managers; and not what standard pay grades dictate.

  • Organisational values ensure good individuals will be quickly promoted from minion positions into hands off management / architect positions, leaving only junior and less able individuals in the hands on roles. This perpetuates the ‘minion’ perception, while keeping the appreciation of the craft within the organisation at an immature level.

However, bureaucracies are a fact of life for many organisations. How can these organisations achieve success with the odds stacked against them?

A good option may be to fly important projects outside the corporate structure. This approach was perhaps most famously taken by Lockheed Martin’s Skunk Works. A small team of engineers led by “Kelly” Johnson created the first prototype of the United States first operational Jet Fighter in only 143 days. Kelly’s 14 Rules for Skunk Works included a very high degree of autonomy, small teams of good people, minimal bureaucracy, early testing, and high levels of mutual trust. That sounds pretty agile for 2008 never mind 1943.

Fast forward to 1986 and the seed of the Scrum approach: the Harvard Business Review paper “The New New Product Development Game” (Hirotaka Takeuchi and Ikujiro Nonaka) which describes empowered teams working outside the confines of the organisation, given vague directives and invited to be innovative in response:

  • “Top management kicks off the development process by signalling a broad goal or general strategic direction. It rarely hands out a clear-cut new product concept or specific work plan. For example, Fuji-Xerox’s top management asked for a radically different copier and gave the FX-3500 project team two years to come up with a machine that could be produced at half the cost of its high-end line and still perform as well.”

  • “The Honda team, for example, consisted of hand-picked members from R&D, production, and sales.”

  • “Headquarters involvement is limited to proving guidance, money, and moral support at the outset. On a day to day basis, top management seldom intervenes; the team is free to set its own direction. In a way, top management acts as a venture capitalist.”

A potentially catastrophic approach would be for key managers and architects to get together and dictate to the minions yet another process, especially an inflexible process, dumbed down by inexperience, and an aversion to anything that could lead to any blame being targeted at the decision maker. Try that and you may end up with something like this.