In an earlier post, I discussed an alternative to hierarchy and anarchy that I called dynamic linking—a way of organizing that combines a sharp focus on the client, autonomous working conditions and disciplined execution.
One commentator asked whether there weren’t other alternatives. What about the matrix organization?
A matrix organization is a setup where you have not one boss, but two or more. It is really a form of expanded hierarchy, rather than an alternative to a hierarchy.
How does it work in practice? In my new book, The Leader's Guide to Radical Management, I try to remind people of just how unproductive these working arrangements are by telling stories. One of the stories that I tell is is about a matrix organization—the story of Nathalie, the software development
The Software Developer
Nathalie, a software developer, is the head of corporate Internet solutions for a major insurance company.
When she inherited the software development team it was facing a typical set of problems—software was late, over budget, and full of bugs. So she set about fixing the problems by introducing practices known as Scrum and Agile. She placed confidence in self-organizing teams that performed work in an iterative fashion, and the team rapidly became more responsive, efficient, and effective. After six months, the team had proved itself increasingly capable of delivering whatever software management wanted.
It gradually became apparent that the bigger problem wasn’t in the team at all. Rather, the organization could not make up its mind what it wanted.
The firm provided a full range of financial services. As a large conglomerate, the varied product lines and distribution channels would have presented a challenge for any team charged with improving customer experience across the board. For many years, the operating model had been a loose federation that provided each company with a great deal of autonomy. At one time, scores of Web sites were associated with the firm.
Nathalie’s team was charged with consolidating and improving the user experience of the firm’s Web site. Although things began well, she could see problems. Under the Agile and Scrum methodologies, management was supposed to specify what software it wanted developed in the next monthly work period. But the various departments found it difficult to agree on what should be done. The implementation period would often start without the organization having reached agreement on what precisely should be developed. As a result, the software development team would begin working on something, only to find that the signals changed when it was halfway along with the work.
The group responsible for setting priorities was composed of representatives of interested departments. But the individuals in the group had no mandate to make decisions on behalf of their departments, and if they did, they were likely to be second-guessed. Time-consuming checking back with their constituencies slowed decision making to a crawl, and often a halt.
Compounding the problem was the fact that a duo of senior managers affectionately known within the firm as the Gruesome Twosome weren’t happy. The Gruesome Twosome insisted on signing off at certain critical decision points, and during their reviews, they would often second-guess the instructions that had been given to the team of software developers. As their interventions became more frequent and disruptive, the group charged with setting priorities became less willing to make decisions for fear of being reversed upstairs.
Nor were the Gruesome Twosome’s decisions entirely clear: the group setting priorities had no way of getting clarification from them and was unwilling to substitute its own judgment. So like the oracle at Delphi, the group deployed an ambiguous dialect that enabled them to be on the right side of the winning decision whatever it turned out to be.
Nathalie came to see that no one was held to what they had said in a previous meeting because everyone knew that decisions were provisional. The only constant was deniability. The more troublesome a problem was, the vaguer the language became.
Nathalie knew that her team of software developers was working well, but it wasn’t productive because the firm couldn’t make up its mind what it wanted.
Nathalie and her team are unproductive, not because they don’t know what to do or how to do it. It’s because they are embedded in a matrix where it takes forever to get the decisions needed for the work to proceed.
The matrix at the World Bank
I spent many years working in a matrix organization in the World Bank. It took around a year to process a development loans that financed complex multi-million dollar projects in developing countries. The projects were complex but most of that year was spent negotiating with the matrix—the various fiefdoms within the World Bank, i.e. the macro-economic department, the technical department, environmental department, the procurement department, and so on, as well as the bosses of these departments, who sometimes had different views from their own staff. In the meantime, the clients would be waiting for a year or more for these internally focused discussions to be completed before they could get their loans. Within the World Bank, time was almost irrelevant: it was more important to placate the various fiefdoms of the bureaucracy.
Paradoxically, there was also a procedure for “emergency loans”. When there had been a crisis, like an earthquake or a flood, the World Bank would put together a team to process an emergency loan. With this procedure, each department would nominate someone to the team, and it would be accepted, given the urgency of the situation, that their representatives on the team were fully authorized to make the best decisions that they could and their “home” departments would accept whatever they decided. As a result, the members of the team were fully empowered to get things done. And so the emergency loans would be processed in about six weeks, rather than one year. This was because the people doing the work could actually get on and do the work, rather than spend their time negotiating with the tentacles of the matrix. The clients were happy because they got their loan in six weeks rather than a year. And the people doing the work found it exhilarating because for once they were free to get on with the job, without being second-guessed.
From time to time, I would propose to the management: why don’t we process all our loans using the emergency procedure? Then all our loans would be processed in six weeks instead of one year. Reviews showed that emergency loans processed in six weeks were not of lower quality than “regular” operations that took a year. In any event, even if there was the occasional error, since we would be moving so much more rapidly, we would have plenty of time to correct the error in a subsequent operation.
My suggestion was always greeted with horror. Unthinkable! And why was it unthinkable? It was unthinkable because that change would have revealed that all of these reviewing departments and managers were not adding value to our clients. It was the people actually doing the work who were creating value for our clients. The reviewing departments were, as Vineet Nayar has said in another context, nothing but a shell, layers and layers of management and aggregators who had nothing to offer to our clients. These layers were not creating value. Instead they were wasting the time of the people doing the work, by requiring them to make endless presentations about irrelevant things and write reports about what they had or had not done. But this was the way the work had always been done and this was the way it was always going to be. End of discussion.
If my suggestion to process all loans on an emergency basis had been accepted, the World Bank would have effectively adopted a version of dynamic linking.
“Dynamic linking” means that (a) the work is done in short cycles; (b) the management sets the goals of work in the cycle, based on what is known about what might delight the client; (c) decisions about how the work should be carried out to achieve those goals are largely the responsibility of those doing the work; (d) progress is measured (to the extent possible) by direct client feedback.
The most complete articulation of the practices of dynamic linking in software development are set out in Mike Cohn’s Succeeding with Agile, and as applied to general management in The Leader's Guide to Radical Management, where I describe around thirty specific practices needed to make it effective.
As The Power of Pull points out, one proceeds “by setting things up in short, consecutive waves of effort, iterations that foster deep, trust-based relationships among the participants… Knowledge begins to flow and team begins to learn, innovate and perform better and faster.… Rather than trying to specify the activities in the processes in great detail.., specify what they want to come out of the process, providing more space for individual participants to experiment, improvise and innovate.”
Dynamic linking is productive and fun.
By contrast, the matrix organization is a variant of a hierarchy, and usually not a very productive one.
In fact, the matrix organization is like Kafka's Castle, and the natural home of the Dilbert-style manager, the manager who focuses on procedure not substance, communicates by ambiguous signals, never takes a personal stand on any issue, and plays for time, hoping to survive.
Having one boss second-guessing you is bad enough. Having multiple bosses doing that is hell.