"This isn't to say that alternative approaches to management are dead, or that they have no future. It is to say that in the absence of serious upheaval - the destabilization / disruption of established organizations, or the formation of countervailing power to the trends above - the alternatives to the Freds will thrive only on the margins (in pockets within organizations) and in the emerging (e.g., equity-funded tech start-up firms)."-- Me, September 2013
I wrote that nearly 5 years ago. That previous summer I cracked the spine on some management books I had last read a quarter of a century earlier. When I first read those books in the 1980s, there certainly did seem to be a management revolution afoot. In the late 1970s, large industrial firms in the US were plagued with quality and performance problems, a rank-and-file that was fully aware of but apathetic to them, and management that was clueless about what to do. The epitome of the industrialized era in western nations turned out to be a company that would systemically disappoint both customer and investor alike. The long dominant organization-as-machine model was commonly perceived to have matriculated to a state of intellectual bankruptcy. Out went command-and-control, in came employee empowerment and team autonomy. Meet the new boss!
Yet when I read these management books anew in the early 2010s, it was clear that the revolution had been stopped dead in its tracks somewhere along the way. Same as the old boss!
I have had reason to re-visit this recently, this time in the context of enterprise technology platforms. A company that develops recomposable, atomic components that can be consumed in a self-service manner by other developers can help to yield more coarsely-grained solutions more quickly. Making those coarsely grained solutions recomposable components as well should enable an organization to create with both greater ambition and speed.
The objective of a platform is not to build both big and small things more quickly or to build more efficiently, but to create more effectively. A platform should allow for a greater number of experiments and more comprehensive feedback. Employees closest to an opportunity - current and potential consumers, technology, competitors, people and capital - are the ones best positioned to pursue that opportunity through exploring, learning, and adjusting. In an emerging area of business or tech, a local team muddling through stands a better chance of success than a distant management imposing its will over a market. In practice, muddling through experiments and feedback requires some degree of authority devolved to the team level, so that a team can decide and act for themselves.
The notion of authority devolved to the team level brings up the question of the autonomous organization yet again. Plus ça change...
The same old idea comes with the same old questions. What does an organization of autonomous teams look like? Can it work? How does it scale?
Before we ask, "can an organization of autonomous teams work?", we have to ask, "what does autonomy at team level mean?" Does it mean the authority and responsibility for what they do and when they get it done? Does it include design and architecture? Can they act on things that are nominally the responsibility of other teams? Do they get to pick and choose the people on their team and the providers they source people from? Do they have to secure their own funding? Who do they answer to? How are they measured?
It may mean all of these things, or it may mean just a few. Autonomy is in the eye of the beholder. To some, just having operational autonomy - authority over what, when and how a team fulfills delivery goals - is sufficient. To others, operational autonomy without owning the P&L and balance sheet - everything from capital to compensation levels - is merely responsibility without authority under the guise of self-direction.
Every firm that has gone down this path has come face to face with the same questions and challenges. Every firm of any scale that has achieved any degree of success has ended up with some hybrid implementation: some things are decentralized, some things centralized; some for a short period of time, others for a longer period of time, and some permanently. For example, we want teams to be responsible for the production operations of their creations, but we must first incubate an ops capability; once we are comfortable that ops has completed its gestation period it will be broken up and absorbed into the line teams. However, to alleviate administrative burden and to avoid violating labor laws we will have a centralized HR function, but we do want ideas to compete for funding, so we will have utility and risk capital allocation processes.
One question, many different answers, and answers that change at different points in time as circumstances require or allow.
When there are many different answers to a single question, it is the wrong question to ask. Looking for specificity where there is none will only sow seeds of confusion and ultimately doubt. And, while there is plenty to be learned from the experiences of others, self-reported testimony must be taken with a grain of salt, and the success of others comes with no guarantee of portability.
A better question to ask is, how convinced are you that team autonomy is a solution to whatever challenges you face? You need to be overwhelmingly convinced that it is, because you need a high tolerance for the ambiguity, uncertainty, and constant adjustments and experiments you will have to run to find and maintain the right balance - that is, construct the right hybrid - for your set of circumstances. You also have to be comfortable without a lot of hard evidence that it solves whatever you had hoped that it would. Even had you not devolved a greater degree of decision-making to the team level, that product might have been a success, that innovation might have emerged, those employees might still have joined your firm. Can't prove the counterfactual.
If you are convinced, and decide to add your name to the list of those that have elected to crack this nut, the operationalizing questions are much different. The one that you will ask again and again and again is the obvious: how do we strike the balance: what do we think that hybrid should be today? what do we think it could possibly be? how do we go about figuring that out?
In addition, given the cyclical love-hate relationship with devolved authority, you must also ask: what makes it more likely, and what makes it less likely, that it will have staying power in your organization?
