When I was a student at IIT Madras, my dream place to work was Bell Labs. Eventually, after a PhD, I ended up there. One of the preliminaries was getting a phone instrument. They told me that it would take a week to get a phone assigned. A world class phone company, taking that long to get a phone? If it was left to me, I reasoned, I would get the phone under a day.

When I co-founded Savera, a telecom interconnect billing company, I had the chance to put my theory to action. I was in-charge our IT and phone systems. I had fun getting an UnPBX. I also managed to get the phone ordering under a day. After a few employees, I let others handle the ordering. Soon, we ended up with many different models of phones. Sometimes we got the phone under a day and sometimes it would take many days. It was frustrating for our HR — they could not plan the on-boarding process. Eventually, I relented and had our professional IT manager, who setup a process for procurement of phones. Even if the procurement time increased to a week, it was always guaranteed. I learnt a valuable lesson.

Now, to standardization.

We are sent conflicting signals throughout schooling. On one hand, we are supposed to follow rules: school rules, arithmetic rules, L’Hospital’s Rule, whatever. On the other hand, we are constantly exhorted to think outside the box. We are asked to break out of the crowd. Only in the later years, we see how this dichotomy shapes our world. Unless we manage both sides — standardization and innovation, we will not succeed, as a species.

Case for standardization

We all understand the need for standardization. Despite what all the fiction books or movies tells you (“Be yourself”, “Work out your own way” …), standardization is a good thing. It is the difference between a proof of concept to scaling to millions. It is the difference between a startup and an enterprise. It is the difference between a small group of brilliant people and a large group of people working as a team.

Standardization helps in many ways:

It leads to predictable outcomes: Standardization aims for measurable, clear outcomes. For instance, if we standardized the process of getting a new phone, we can assign responsibilities, SLAs (say, how long to do what and what number of mistakes allowed), then we know what to expect and when to expect. That increases customer satisfaction (Imagine being told that the cable person comes between 10am-2pm and you need to waste a whole day waiting for them. Or, if they say 3:45 pm, even if it is late, you feel more empowered.)

It lets us plan better: The predictability of outcomes lets us plan better. We can set the expectations for the customers. We can plan the next steps and dependent tasks better.

It lets us build a large supporting system: If we have predictability, we will not mind spending effort in building a support system. This is how ecosystems are built.

It lets us create complex systems: People who build complex systems understand that variance in a system increases with the variance in constituent parts. If there are 10 steps, and each step could take +/- one week, on the whole, the final system ends up taking +/- 10 weeks. That degree of variance makes the system unviable.

It reduces costs: The cost reduction shows up for many reasons in many ways.

It reduces variations: Instead of several options and choices, by standardizing on a few, it reduces the costs.

It lets people spend least amount of energy for reasonable outcomes: Standardization allows us to create standard operating processes, tools, and templates to reduce the costs.

Let us look at different examples, including information technology on how standardization helped progress.

Growth of cities: The growth of cities became possible with standardization of different services. In fact, these shared standard services, from security to sewer cleaning, from transportation to trash removal service, from piano tuning to patio furniture let people specialize and scale up the services for large masses. All of these services made for the megacities of the day.

Standard money delivery: In the medieval ages, sending news or money from place to place was difficult. The Templar order made it possible to send money to different places: Say you need send ransom for your uncle’s release in Turkey. You give money to the local Templars in Birmingham and the agent in Turkey pays locally. The guarantees and the timelines they offer lets people plan the rest of the actions. (I am thinking . In fact, one argument against bribe is not the cost, but the unpredictability of service.

Standard containers: In the book Box, the author shows how standardization lead to the support systems like mechanical loading and unloading. All in all, this standardization pretty much created the current global supply chains and the globalization. A shirt can be made in china and button sewn in Thailand, and label put in Japan. All of this is possible only with standardization.

GUI Programming: I remember the days of early 90s, when GUI programming in X-Windows and Motif were very difficult. Once people figured out the standard way to build applications, tools like TK and VB drove the price down. The myriad choices of Motif became standardized with fewer ways in the modern toolkits. That led to easier paradigms of programming making GUI programming within the reach of mere novices.

All in all, standardization plays in many ways in spreading innovation to the masses. It is how industrialization succeeded, by creating a large class of working class as well consumers. It has a direct bearing on the success of software industry. It created the entire software development outsourcing, where offshore development companies came with standard tools, processes, and methodologies to deliver software with expected quality, cheap price, and predictable timelines.

Case against standardization

Yet, standardization hinders us in many ways. In fact, its success is the cause for its failure. By creating a standard way to work, it creates a tradition that robs incentive for innovation. This problem shows up in many ways:

Standardization is resistant to change and innovation: There are many reasons why standards are resistant to change:

The sunk costs: They are already here and everybody already are using the standards. For instance, moving from qwerty to alphabetic keyboard does not happen because of this inertia. Think of all the keyboards and the training costs.

The risk factor: They are cheap enough that any change, even if was cheaper, carries a risk. The risk of change deters most organizations to experiment. For instance, in the early days, moving to cloud was considered risky — even if it was cheaper.

The interdependencies: The collective interdependencies make change even more difficult. For instance, the size of the shipping container depends on the width of the train, which itself depends on the width of the tracks; and of course, the established trains and tracks. Nobody wants to be the first one to change.

Standardization removes choices: Ultimately, in the name of standardization, we end up serving common denominator — of tastes, of choices, and of creativity. Remember the old saying: “You can have any color car, as long it is black”? It leads to monoculture of technology, culture, and aesthetics that are susceptible to viruses, exploitation, and systemic biases. For example, the standardization on windows in front offices led to the current spate of rampant viruses and other malicious threats.

Standardization is difficult to improve: Any incremental improvements to standards need to support the existing setup. That restricts the kind of improvements we can make. Besides, the enemy of the best is not worst, but “good enough”. Standards are good enough. For example, consider the USB-A port. It is not reversible; and it ends up costing humanity untold number of man-hours.

Standardization naturally degrades over time: Even though standards work reasonably well, they degrade over time. Specifically, it happens with training of people. Instead of the spirit of the standards, people follow them to the letter. An orthodoxy encourages blind application of standards, which ignores changing realities and people preferences. For example, as the windows GUI programming became popular, as more and more people entered the field, the quality of GUI design went down.

[Consider the fireplace in a house. Nobody uses fireplaces anymore. Yet, almost every house has a fireplace. Instead of its functional use, it became a part of the cultural icons and a part of aesthetics. Ironically, it ended up with a different utility value, as a place for people to gather and an informal place to sit. We are constrained to keep the original designs and innovate around it.]

Overall, we see the trend: Standardization does not play well with innovation or change. It has lot of implications to the software industry, especially software services companies. The very attributes that made them a success are going work against them in the coming years.

Why? Let us see:

The change in the ecosystem: The new software is delivered on new channels. They use new technologies. They use cloud. They are built on newer platforms.

The change in the expectations: The new software is built for more digitally savvy users. They are expected to be user centric, with high degree of reliability and performance.

The change in the requirements: The new software changes the requirements often. In fact, unlike before, the requirements come from actual users. Moreover, applications average life is getting shorter and shorter.

While software service companies are grappling with the issues of irrelevancy, the enterprises are facing the same challenges in many ways.

The dilemma for the enterprises

Let us take a typical enterprise: they started with IT department with pay roll in the 70s. The brought in PC’s for client/server programs to create small apps for their customer relationship management. They tried to write lot of apps, but eventually wisely moved to SAP. In the 2000’s, they rewrote parts of SAP in Java on the web. Later in 2010’s, they used mobile and modern web.

All in all, their focus was to take the requirements and use the right COTS application. The only changes were the integration challenges with web and the ERP; and the new channels of mobile and the web in the modern times. The focus was always to reduce the costs and stick to the service levels promised.

For them, standardization delivered. They could reduce costs; They could use average programmers; They could use standard methodologies.

Suppose you are the CIO now. You understand you cannot ride on the cost cutting alone. You cannot wait for the business to send in the full requirements. Sometimes, you work with the business; sometimes, you lead them to new possibilities. You understand that may mean lot of custom applications. How are you going to deliver those without blowing the budget?

Let us be even more specific. Suppose you are planning on delivering lot of front-end applications. Lot of them are going to be short-lived. If you are going to develop that many, you know standardization delivers the right kind of efficiency.

The problem is that these technologies are moving really fast. If you standardize and build all the ecosystem — the assets, the processes, the training, the hiring — then, what happens if the technology becomes outdated? Within JavaScript, on average, there is one new framework every quarter. Even if you choose the right one, it will be outdated soon. You don’t choose — you end up with a dozen. You choose, you still end up with a dozen, but all the ones are outside your governance.

The challenge of standardizing in fast moving world is a problem that most CIO’s, CTO’s are facing now. There are no easy answers. Still, there are lot of best practices, checklists, and ways of working that can help in balancing this standardization that can support innovation. We will look in-depth about those practices in the next article. Specifically, we will look at:

It is clear that standardization offers lot of benefits. Where does it work best? How do we determine where to standardize? Does it depend on the organization?

How do we support innovation through standardization, if they are at logger-heads?

How do we standardize in the fast-paced technology fields?

What kind of standardization should we do? Is there a checklist?

What are the processes associated with standardization? How do we deliver such standardization?

We will look at all those questions in the next article. Feel free to comment with your experiences. Do you relate to this challenge at all?

As an aside, I find this dichotomy play in several different arenas — notably conservative vs. progressive thought. Or, established companies and startups. Yet, I also see a convergence that balances these two aspects. I think that ought to be the goal of any modern enterprise.