Summary : Can the management innovations we can see in middle-sized structures work into larger businesses ? The question is worth being asked and, at first sight, the answers seems to be no. If we have a closer look at some successful cases, it appears that scaling up may not be the right wat to follow and, on the contrary, that large businesses should rather scale down and adopt smaller and more responsive units. As a matter of fact, most of the dysfunctions we can see in large business are caused by the will to scale up things that work in small units. The only concept that can scale up is communities, what often fails because of too much manipulation. But these two approaches are not antinomic. One works for operations, on a small scope, and the other for learning on a large scale. What’s at stake is being able to joint the approaches.
In a previous post I started wondering if the organization models that works successful in middle-sized organization and are very close, by their nature and results, to what many businesses would like to implement, would work in larger businesses. As a matter of fact, it’s legitimate to wonder if what works for 1, 5 or 10K people could work for tens of thousands employees.
1Â°) One should not try to scale coordination and execution models up
A part of the answer comes from Ricard Semler. Semco keeps operational units smaller than 140/150 people. When more people are needed, units are split. After a small period to adapt, it appears than two units of 150 people perform better than a single one made of 300 people. Dunbar’s number seems to be still relevant so.
Similar thoughts at Morning Star. They think their model can work for larger organizations. Why ? because that’s not because an organization is bigger that the size of units should grow accordingly. Consequently, it’s better to have more smaller, autonomous and agiles units that cooperate efficiently. Moreover, not all units need to have a high level of cooperation : sometimes a lower one will be good enough.
Is it an heresy regarding to economies of scale ? Not at all. As Hamel said in his post about Morning Star, management is the least efficient part of the organization. Bigger units may help to share resources (even if it’s also possible with smaller ones) but causes lower management efficiency and quality. What leads to ask the question the reverse way.
If highly hierarchized pyramidal organization were borne, that’s precisely to address much more employees with only a little bit more managers, by cascading. The system quickly shows its limits, making anyone do nothing without the approval of one’s superior, what paralyses management and slows the whole system down. A couple of weeks ago, a piqued manager told be : “Me ? A manager ? Once I have approved the change of lights in the toilets and the (free) reparation of the coffee machine, I’ll see if I have time to take care of my staff and their projects”. What looks like the now famous story of Ben Verwayyen, Alcatel-Lucent’s CEO.Alcatel-Lucent needed to hire an assistant in Poland. Each person involved in the recruitment process said “ok…but I prefer to ask my boss for validation”. So the request climbed the organization hierarchy, 16 people asking their boss if it was ok. The request ended on the desk of a 17th person : Verwayyen himself. What made him fly into a temper and tell the whole organization :”I don’t want this kind of thing to happen again. Take you responsibilities and make the decisions you have to make at your level”.
What would be needed to make the system work again ? Closeness, trust, membership feeling, engagement, cohesion on shared values and goals…what leads us to the need for smaller units. That’s not contrary to the need for getting rid of silos. It’s possible to work with both smaller, agile, close and permeable units,Â and organize learning and exchange at a larger scale (read the next Â§). Execution and learning logics are complementary and happen in specific contexts that need their own rules and practices.
In the end, the point is not anymore about scaling a “Semco-like” organization up but scaling typical large businesses organization down to build smaller and more responsive units.
2Â°) Learning and exchange logics scale up easily…in theory
We started with systems focusing on decision and execution. But what about those aiming at improving exchanges and learning at a larger scale, what usually refers to things like knowledge management and learning organization.
That’s supposed to be the role of communities, which are known to scale very well and work in very large businesses. At least in theory. I already mentioned it there but it’s worth summing things up. Community works very well…until organizations try to manipulate them. Consequence : we can see vibrant communities working very well, relying on the only will of employees, sometimes out of any enterprise program. On the other hand, at the moment enterprises decide to build employee communities things get complicated for a reason : employees see the initiative as more work to do, out of their flow of work and their job description, a work that will benefit more to some other people than to them. That’s often the case with communities aiming at crowdsourcing ideas to sustain a program owned by another corporate entity or team that will make the community work without anything in return.
The issue may be fixed with thoughts on the evolution of the work=pay equation to contribution=revenue. But we’re still very far from that. Meanwhile, the big misunderstanding between enterprises and communities will last a long time.
3Â°) Joint is more important than scale
So it appears that the “scale” issue is about two logics : operations and exchanges. Production and learning. Each logic needs a dedicated plan that works on a specific scale.
â€¢ Production (coordination, decision making, execution) : small scale, strong ties, intense interactions, most of time synchronous, little latency.
â€¢ Learning (exchange of practices) :large scale, weak ties, loose interactions, most of time asynchronous, much latency.
What was wrong these last years is that enterprises thought they could solve all their problems with exchanges and learning, what lead to say “don’t change anything and add communities”. But communities do not contribute much to coordination, work, day to day executions. That’s not the relevant place for getting things done even if they can contribute. Communities are rather a long term investment on knowledge than a tool to improve instant execution.
So what matters is to joint the two logics.One will work at high speed, intensively, for day to day work while the other will work more slowly, in the background, for long term achievements. But what many organizations still call enterprise 2.0 or social business used to focus on only one of these logics, neglecting operational effectiveness. Even if communities work, if nothing changes at the execution level, a bottleneck forms that annihilates any effort made to turn the organization into a learning one. Making knowledge more accessible and shared has few value if the work using this knowledge is not made more effective.
So, the relevant question, was not to question scalability but address very targeted and operational issues, a global approach to be implemented at the team or unit scale, one after the other.
From a very practical standpoint, making knowledge exchanges more easily between facilities or business units is key to agility and time to market. But if nothing is done to improve the way it’s put at work, in the way decisions are made and executed, only half of the job would be done. And this half with hardly create any value because of the bottleneck that will remain downstream.
PS : some still wonder if the cases I mention in this post deserve the enterprise 2.0 or social business case. A legitimate question because we’re far away from social tools adoption…but I don’t think such a debate will have any interest for businesses. What they need is a clear understanding of how it works and the impact on day to day operations and created value, whatever the name.