Does SDN, DevOps and Agile Infrastructures Require an Abandonment of Taylorism?

I posted last week about a sales call gone wrong and an innovator’s dilemma moment. Since that time I have had additional customer and internal engagements that caused me to think about what I call institutionalized impedance, which might be more familiar to a broader audience if I called it Taylorism or scientific measurement.

I found myself in a conversation with our CEO regarding a potential channel partner. I was opposed to engaging with the partner because I viewed them as rooted in the past. The potential partner we were discussing is a classic platform 2.0, best of breed technology integrator that requires all the traditional go to market sales materials, tools, and messaging. My point to our CEO was that Plexxi is selling hydraulics and the partner we were discussing sells steam shovels and expects the steam shovel sales kit. Then I had a second thought.

Does SDN, DevOps and the evolution to an Agile Infrastructure require an abandonment of Taylorism to facilitate broad adoption?

The beginning of that thought probably started in mid-2012 when I started making Plexxi sales calls, but I think only completed in past week. We had been calling on a prospect for about a year. Only recently did we break through from the technology scout or architect to the operations side of the house. It was clear me that the team looking at emerging technology trends had no real interaction with the operations side of firm. There was a gap between functions.

If we read the descriptions about hyper scale data center design and open compute projects, it is profoundly rooted in Taylorism. The over arching message in these articles, papers and presentations is about efficiency, standardization, process and cost. All of these objectives and focus areas are logical when your objective is to build at very large scale or build for continuous production. The efficiency methodology called out by Taylorism is rooted in process fragmentation, precise cost measurements, standardization and continuous performance measurements.

Taylorism has been a fundamental foundation of the post-19th century modern company. We see that it is deeply embedded in our daily life with the message of “do your job” and job specialization. A hundred years after the introduction of Taylorism, there has been an anti-Taylorism movement developing. From a high level, the thinking within the anti-Taylorism field is about the reduction of the separation that exists between conception and execution. Anti-Taylorism thinkers embrace broadening of skills sets away from siloed specialists. Work teams have autonomy and co-determination empowerment to make decisions and accelerate the business. That is the specific change I witnessed at the customer mentioned above. We had been engaged with the conception (architecture and technology) side of house, but we could not get investment from the operations side of house.

It was over a year ago that I read the Phoenix Project and wrote about it. If we read Wikipedia definition of DevOps it states that it is a “…concept dealing with, among other things: software development, operations, and services. It emphasizes communication, collaboration, and integration between software developers and information technology (IT) operations personnel.” On numerous occasions I have heard people conflate DevOps with industrial production using Taylorism analogies and stories of the Toyota production line. There is a difference between building agile infrastructures, creating a collaborative development environment and running efficient industrial production lines.

In the vast majority of IT organizations there is still a legacy Taylorism structure in place. It is still common to find IT teams divided by technology siloes: apps, storage, mobility, servers, network, security, etc. That makes perfect sense to the CIO rooted in Taylorism: fragment the organization by function, develop precise cost measurements, standardize the process and provide continuous performance measurements. There is nothing wrong with that methodology, but it has nothing to do with DevOps, SDN and agile infrastructures. When the process barriers collapse, that is when the agility and IT velocity of the organization begins to change.

/wrk