Cloud Prefers Squads and Tribes Over Taylor’s Silos and Towers

It was over one hundred years ago that Taylorism, or scientific management, reached its peak of influence as the go-to management and organizational theory, with Frederick Taylor himself using a term that’s very familiar in today’s IT service management (ITSM) industry – “process management.”

One hundred years since that peak, ITIL and similar IT management frameworks are today’s embodiment of Taylorism, with their focus on efficiency of labor through division of labor and processes – where teams of people are organized into function-oriented units that are, in effect, a cog in a larger process wheel. A practical example would be a change management team as part of a larger ITSM operation.

Taylorism in Practice in 2016

Talk to people who have worked in this structure for some time and you will find someone who is fed up of working in seemingly dysfunctional, impersonal Taylorist organizations; structured into process-oriented silos and towers that consistently deliver failed IT projects no matter how much hard work goes into them. The growing Wikipedia list of failed UK government IT projects alone, which I imagine to be somewhat prudent, is commonly blamed on organizational failures, not necessarily on the individuals working in the system.

The decades of IT improvement programs have had organizations squinting their eyes to focus harder and harder on their process and the organization, but the issues never seem to be resolved no matter how many IT frameworks are thrown at them. As Albert Einstein once said, “We cannot solve our problems with the same thinking we used to create them.”

So, if Taylorism is “the problem,” or at least a big part of it, where does the solution come from?

Start-Ups Disrupt the Silos and Towers

Start-ups by their very nature have no legacy (nor baggage) – in terms of people, process, and technology – to deal with. Their young founders have never passed through a Taylorist-system and they have no inherited Taylorist structures to maintain. Instead start-ups frolic gaily in pristine greenfields as opposed to living a donkey’s life of drudgery tied to a stake in Taylor’s brownfield.

Spotify is a great example of a start-up that dared to create their organization differently. In 2012 they wrote a paper called Scaling Agile @ Spotify with Tribes, Squads, Chapters & Guilds that describes their experience of “dealing with multiple teams in a product development organization which has kept an agile mind-set despite having scaled to over 30 teams across three cities.”

Their model looks like this, starting with the smallest of teams:

• Squad – the lowest common denominator, a small “start-up,” sits together, shares two pizzas, etc.
• Tribe – multiple squads totaling 100 people or less (approximate to the Dunbar Number); the goal is to eliminate dependencies between squads (effectiveness over efficiency).
• Chapter – designed to share learnings and increase economies without dependencies on topics like testing and security.
• Guild – so that, on a wider level, individuals can share a wider community of interest across the organization.

This model has spread to organizations such as Sky Betting and Gaming and the ever-growing list of companies that “do” DevOps and continuous delivery.

So what does this organizationally-based disruption look like?

Comparing and Contrasting Squads and Tribes to Silos and Towers

At first glance, the Spotify model is a still a matrix organization just like a silo and tower structure. Each individual is a member of a “home” team but is additionally associated with more than one group to share skills. So what’s the real difference?

The biggest difference is a subtle one. A squad, as part of a tribe, is oriented towards delivering a product or feature to a customer; whereas a silo, as part of a tower, is oriented towards performing a function as part of a larger process. Think of a squad as an autonomous machine and a silo as a cog in a larger machine. So, a:

• Squad is subservient to the needs of the product.
• Silo is subservient to the needs of the process.

This difference is measurable and is seen in research such as Puppet Lab’s State of DevOps 2016 report, but even how the two groups are measured is different:

• Squads are measured on effectiveness (delivery).
• Silos are measured on efficiency (cost).

Why Clouds Work Best with Squads and Tribes

Amazon Web Services (AWS) is perhaps the most famous, and oldest, proponent of this model – exposed by the now-famous Steve Yegge 3,700-word rant of 2011. Autonomous service units work together in a loosely-coupled manner, with only dependencies on a public API, very much like the Spotify model.

Amazon’s front page is made up of hundreds of services, which we can visualize as hundreds of squads focused on their piece working in harmony, without blocking dependencies (a dependency on an API is okay).

Cloud services per se need much less process than traditional IT because much of the work is done on your behalf by the service provider. There’s no provisioning of servers. No complex storage expansion. Little network management. In essence, all you need to care about is the API of each service, how they work together to provide your service, and the service delivery characteristics such as security, scaling, and billing. Plus, enterprises that use these cloud services are now imitating the model back to their clients. Banks build a tribe for their mobile banking application that has squads for each important function.

Are Old-School IT Professionals Doomed?

No. If you are a seasoned change manager, or another flavor of IT professional, used to working in a silo and focusing 100% on the (change) process, it’s still possible to work at a progressive company like Spotify.

We are in a period of transition where operational teams still use change management while adopting such new structures. And it’s ultimately beneficial for a tribe, and for specialist overlays like guilds, to learn from seasoned change management professionals.

Long term however, the irony is that the change managers will need to embrace change themselves. As will most other IT professionals who have spent years, maybe decades, trapped in IT silos and towers.

So, are you stuck in a silo, looking at tribes from afar and wanting in? If so, what are you doing about it? I’d love to know.