[MUSIC] In this segment, we're going to talk about the shift from bureaucracy to emergence. In other words, we're going to ask the question. As a company, if you wanted to become less bureaucratic, if you wanted to shift as it were from the left to the right-hand side in terms of our overall picture. How would you do it? And the best way to answer that question is to give you some examples. And so I'm going to give you three examples from very, very different business contexts. Of organizations and types of organizations that have made the shift from bureaucracy to emergence. It's quite a complicated story, there's going to be nuances here that suggest it's not just a simple movement from left to right. The first one we'll take is a company called Oticon. Most of you have never heard of Oticon, it is a Danish hearing aid manufacturer. And this story dates back to the early 90s. And it dates back to the period when this company, Oticon, was competing head to head with big companies like Philips and Siemens in the market for hearing aids. And they weren't doing particularly well, because of course, their competitors had much, much bigger pockets, much deeper pockets. So the chief executive at the the time, Lars Kolind, had a a radical idea. He said, in order to compete more effectively, we need to change the way that we work. He used the concept of thinking the unthinkable. And he said, we need to rip up our traditional way of organizing, which is very bureaucratic, and we need to create a method which gives much more power to the people developing the products. So that we can make it much swifter to markets, so that we can bring more new technologies on stream more rapidly. And so he came up with this notion, he called it the spaghetti organization, and this notion was essentially in, in a sentence, a bottom-up resource allocation system. In other words, if you are a team of people working in the, in the development function, and you got an idea for a project. All you needed to do was essentially to get the people together, and to start work on it. And resources would be allocated to you as a matter of court. You didn't have to make a long proposal to the people at the top. They basically said, your job is to self organize, to figure out what projects need working on, and people would welcome multiple projects at the same time. And people would deliberately, shall we say, be a bit more creative than they otherwise would. Did this model work? Yes, it did. Essentially for the next four or five years, Oticon was, was really very successful. Launching a whole stream of new projects, products smaller, smaller hearing aids, digital hearing aids, and so forth, that helped the company to compete at a very high level using this new model. But actually the story doesn't finish there. Because it turns out there was this new model, this bottom up model, this so called spaghetti organization model had enormous benefits. It also had some weaknesses. Some teams found themselves doing overlapping things. So teams found themselves moving into projects which actually weren't that good of an idea. And they weren't very good at killing off dead projects dying projects. So. Gradually over that period, they reinstituted some of the more traditional top-down reviews. And Lars Kolind himself retired in the mid 90s and was, you know, was succeeded by somebody else, who essentially helped to move the company back a little bit, towards more of a so, shall we say, hybrid model. So they went from extreme bureaucracy on one side to essentially extreme emergence on the other side. And then the pendulum swung back to a more of a middle ground. And throughout the late 90s and early noughties they occupied a, a, a space, a manage, management-wise, which was a much more of a kind of hybrid between the principles of bureaucracy and emergence. And is still doing very well today. So interestingly you could argue that it was very successful to move away from their traditional model. But the gradually moving back towards something which is a bit halfway in-between was ultimate, sort of the best place to be. So there’s some interesting kind of tangents we won't get into here about benefits of, shall we say, change for change's sake. Suffice it to say ha Oticon is to this day actually taught in MBA programs around the world as a good example of a company creating a more agile or adaptive form. My second example of emergence in practice is what's been called the beyond budgeting movement. Now, we all I think have lived in organizations where budgeting, as a system, kind of gets us down. Budgeting is a very slow and painful way, essentially, of making sure that everybody knows what each other is doing, and on occasion resources, and budgets and plans accordingly. So there's been a movement over the last decade or so, particularly amongst the financial controllers of, of large companies, many, many in Scandinavia, some in the UK, some in North America, to say that the old budgeting mechanism no longer works. They basically said budgeting is slow, it's cumbersome. And it's actually, ultimately, a compromise. A compromise, if you like, between what the people in the front lines feel they can sell, versus what the people at the top, would like them to sell. So they've come up with an alternative, and they call it the beyond budgeting movement. Now, I'm not going to do into the details of this now, because we've got a couple of readings, which you can take a look at, which will give you a couple of worked examples to play with. Suffice to say that where the traditional budgeting model had an emphasis on top-down control, whereby the people at the top retain authority and accountability, and they essentially allocate jobs to people on the front line. The beyond budgeting process says let us do the other way up. Let us essentially delegate or, or, or, or empower people on the front lines to set their own budget, to set their own targets. And to figure out for themselves how they'll meet those targets. And to engage in a much lighter touch conversation with the people at the top to ensure that what they're doing is accord, accordance with the principles that govern the company as a whole. And so this lighter touch, almost lean budgeting process has been experimented in many companies. Swedish company called Handles was the founders of this movement way back in the, in the 1970s. And there's a Norwegian oil company called Statoil, for example, again, a very famous proponent of this method. And it has now become very much kind of part of the language of many, many companies, in terms of progressively thinking about better ways of budgeting. The third example i'm going to give you, is in the world of software development. And those of you who've got any experience in software, will know that there's been a bit of a almost sort of a religious war underway in software development. What is the best way to develop software? The classical method, we'll sometimes call the waterfall cascade model. And it was very much built on this notion of, of what's sometimes called the capability maturity model, whereby we give companies sort of grades, if you like, for the quality of the specifications and the designs and the systems that they build. So the old model basically said we will design a system at the top. We will create specifications that fit with user needs. We will break that system down into parts and will give each sub-component a job of developing the relevant software for each part. And then we'll kind of build it all together again and we'll do the systems test, and we'll make sure that that system is verified and assured, and we'll give the people behind it a sort of a stamp of approval. It's a beautiful system when you're absolutely confident that user specifications have been well designed and that they do not change. Unfortunately, the reality in the world of software is that, that actually is very seldom the case. So the so-called agile movement over the last 10 or 15 years has really gathered pace as an alternative way of developing software. And it starts with this basic premise. That users really don't know what they want, so what users do in collaboration with the software developers is they get into a discussion about what it is that they think they want. And the software developers come up rapidly with a, an alpha prototype to check with the users, to say, is this what you thought you wanted? And if they say, yes, yes, it is what they wanted, then they develop it further. And gradually, they build the system out in, in order to make something which actually meets the user's requirements. Now the details, again, I'm not going to go into it now. Because there's some, some readings you can do. I want to make a couple of points before, before we, we finish this segment. First of all, that agile is, is better in many respects. It's typically faster, it's typically more user oriented, it's typically much more fun quite honestly, for the software developers working in the agile environment. Because they work on much shorter cycle times, they work in smaller teams. The second point I'll make is that the, the kind of the principles behind it have now been very, very clearly sort of, set out. There was a famous conference in, in Utah in 2001 between a bunch of people who were working with versions of this way of thinking. And they came up with what they call the Agile Manifesto. And you'll see it on the screen here. And it says basically look, we're uncovering better ways of developing software by doing it and helping others to do it. And we now value, for example, individual's interactions, in other words how we work with each other over processes and tools. We're working software over comprehensive documentation. You see the words on the screen. You'll see immediately that this philosophy, philosophy of agile directly maps onto the principle of emergence that I've been talking about. So that is, in the world of software, a way of working which is exactly linking to the emergent principles I've been talking about. And indeed this agile approach to software development is now gradually influencing the way that a lot of people think about management more generally. So, to finish the segment off you'll see on this slide here a chart which we've got two axes and it's got a little bit of a kind of a an arc. What am I saying here? I'm saying, look, we can think of bureaucracy and emergence as opposing principles. But we can also to some degree think of them as opposing principles that can be reconciled to some degree. In other words, if you put them onto a chart like you see on the slide here with bureaucracy up the vertical and, excuse me, emergence on the horizontal, you can imagine a frontier. Represented by the, by the curved line. Whereby some organizations are able to actually kind of get the best of both worlds. In other words, by creating an opportunity for a hybrid model, we end up with a model which is shall we say 70 or 80% as bureaucratic as the traditional model and also 70 or 80%. As, as sort of links to the principles of emergence, as the, as, as, as the new model. And that best of both worlds of course, allows us to shall we say, capture all of the benefits we talked about earlier in terms of bureaucracy as well as the benefits of emergence.
