The idea for this note came to me during a discussion with someone from the Direction Générale de l’Armement several months ago. To the question “Do you know what our job is?” I replied, hesitantly, “Hmmm…choosing the weapons to be used by the army…?” “A little…but it’s more complex”. ” Huh?”.
I innocently thought that weapons were bought to equip and arm arm armies. My interlocutor goes on to teach me, without realizing it, something very useful.
My initial idea was that an army was made up of different types of forces (land, naval, air) that needed to be equipped. Which, I later realized, meant that armament was dictated by structure, by the fact that there were functions that existed and that they needed to be equipped.
The reality is quite different.
In fact, we start by identifying the issues at stake (projecting ourselves onto such and such a territory, responding to such and such a threat) and then we respond in terms of systems. And what is a system? A modus operandi, people and equipment. If the DGA’s role is more specifically to deal with weapons, it can only fulfill its mission by taking the other components into account, as weaponry is meaningless if it is chosen in isolation from the issue at stake, the operating mode to be implemented and the men who will serve it. I therefore deduce that the same applies to the choice of men and the determination of operating methods.
This led me to draw an interesting parallel with business.
On the face of it, the army seems to act like a business. But I see a number of differences that make this not so.
As you can see on a day-to-day basis, business doesn’t think in terms of systems, or in a piecemeal fashion. When we think in terms of operating methods or tools, we train people, or at least we try to. We try out new tools, enabling new things to be done, while keeping an old operating mode. But the three are never considered together as the three equally important components of a response. In general, we focus on one of the aspects, which becomes the “driver”, and try to align the other two (and I do mean “try”), and more generally only one. Whereas the “driver” is the issue on which the three must be aligned jointly and coherently.
The “driver” is the other fundamental difference.
Paradoxical as it may seem, the business equips a structure (top-down design), whereas the army responds to a challenge (bottom-up). In one case, the system is designed to equip a predefined structure; in the other, to meet the challenges of a fast-moving ecosystem.
In concrete terms, this takes place on a daily basis. The employee is caught up in a downward flow, part of a totally planned process. But when something unexpected happens (an internal or external problem), he or she can only remedy it by fighting against this flow. Since this flow is designed to maximize the individual’s productivity, it “loads” the available work time as much as possible. In other words, they have to fight against an organization that is designed to carry out what has been planned at the top, but in no way to find solutions to problems arriving from the bottom. Add to this the time wasted when response time is an essential performance factor.
As the knowledge economy is characterized by its disruptive nature, and consequently by the fact that the unexpected is becoming the norm, the traditional “top-down” system is less and less able to be a competitive factor – quite the contrary. Quite the contrary, in fact. Quite simply because it prevents the implementation of ad-hoc systems to meet the challenges of the field.
Let’s get back to our original point: whatever people may say, the army of 2008 bears no resemblance to the army of 1950. This is logical, given the evolution of the issues at stake. Note that the business of 2008, even in the service sector, even in the intellectually-intensive sectors, is far from having buried Taylor, even though the stakes have changed radically. It’s as if, believing itself to be its own stake, the business had forgotten that it was part of a competition whose rules it didn’t set. A living organism that uses its own resources to feed itself (self-digest?) rather than learning to eat. In short, the system has become its own end, the means has become an end.
Perhaps this explains why the CIA was the star of the enterprise 2.0 conference in Boston last week, and why the business seems to be marveling at an internal sabotage mechanism.
In the years to come, the challenge for the organization will be to successfully reconcile the need to fulfill its mission, to deliver, within the framework of the top-down flow we mentioned, and the need to allow ad-hoc systems to be put in place to resolve problems when they arise. After all, the job of most employees today is to solve problems and provide answers to questions.
Such an ad-hoc system consists in identifying and mobilizing the skills needed to solve problems in a business that is so dispersed and granular that they cannot be dealt with by one person alone. It’s an ephemeral system based on interaction between two, three…ten individuals, lasting as long as it takes to solve the problem (an hour, a day, a week) and disappearing as quickly as it was created, based on exchanges that are usually asynchronous (due to the structure of the business and the availability of people). It takes the form of upward, diagonal or even ricochet flows, thanks to the intervention of internal facilitators.
In a few words (my thoughts are still in the embryonic stage… I’ll give you a rough outline):
– Such a system enables business to be driven by operational issues
– Is an excellent example of the subsidiarity principle
– Saves the time of the employee, who doesn’t have to fight against the top-down flow, as well as that of his or her manager.
– Corresponds to the reality of a distributed, collaborative business in the context of the knowledge economy: a business where everyone supports everyone else, and where problems are solved collectively.
– Brings the adhocracy needed for business at the start of the 21st century
– Is not incompatible with hierarchical functioning; it’s not one or the other, but both, depending on the context.
– Corresponds well to the “think global, act local” principle
– Allows you to adopt an agile approach, focusing more on the “what”, people and interactions, than on the “how”. But more on that later.
To conclude, I know we can’t escape the question of cost and ROI. Here are some answers
– who questions the business’s support functions (finance, hr, etc.)? They are necessary because they support everything else. Here, everyone supports everyone else
– leads us to think differently: the gain is in the person who solves the problem to create value, the cost is the 10 minutes given up by others. By giving time locally, we’re contributing to an optimal global solution. But more on that in a moment.
– a system that would benefit from being supported by an approach similar to innovation made in Google: we consider that everyone gives x% of their time to the collective. This settles the question of “we don’t pay them to give a hand to people in other business units”.
Sounds a bit like wirearchy, doesn’t it? In fact, that’s exactly what it is, the reasoning being that this mode of operation is the only one likely to cope with the unpredictability that is the daily reality for employees, and to enable the dynamics of collective intelligence to be used for problem-solving, a performance (or even survival) factor if ever there was one in the knowledge economy.
In bottom line terms, we’re talking about a form of organization which, without calling into question the traditional hierarchical model, enables everyone to mobilize the skills and access the information they need to solve their day-to-day operational problems. All this is supported by an appropriate software infrastructure, with only a business social network enabling the necessary interactions across the organization.
Schematically, it could look like this. Each red star represents a person with an operational problem to solve, the yellow dots the resources mobilized, the lines the interactions and the downward arrows the downward and structuring flows.
By the way. Why SOO. A nod to SOA, because I find the principle of service-oriented organization very meaningful. But as I’ve exchanged ideas on the subject with various people, I’ve also heard the term SPO, for solution providing organization, the organization that provides solutions to everyday problems, that provides a framework, a structure that encourages problem solving. Which would make the manager a “solution provider”, the one who brings solutions, who makes others succeed?
What do you think?
