Autonomy vs. Standardization in Digital Enterprises

In the early years, standardization was the starting point for IT cost cutting and gaining efficiency. Fewer tools, fewer versions, fewer programming languages, fewer frameworks and fewer processes — all as a guarantee for less spent on maintenance, upgrades, security and talent management. But since the Agile Manifesto movement, companies realize that standardization kills not only innovation, but leads also to more frustration for employees.

In 2017, I was invited to a newly founded branch of a company in the Financial Service sector. The company is the counterpoint to its mother company, and can be described as an Agile enterprise. Since its founding, this agile branch of the company was growing step by step to a few hundred people. Our point of discussion was further optimization in the Agile and DevOps area. When I was invited to the discussion, their minds were already made up. Most people in the room were fighting for full autonomy for the teams with all its consequences. They wanted the full autonomy that the teams had had since they had started; they didn’t want any standardization. Their teams should be allowed to decide about all important aspects of their work, having total freedom, so to say.

Most of the companies I worked for as consultant are handling autonomy differently. They have a different background, all had global initiatives and cost cutting programs after the Dotcom bubble burst.

Start-ups are different then Fortune-500 enterprises, but all are building their legacy

In an early stage, autonomy is for sure the right way to go, that’s all they know. But companies are changing. They grow, change their organizational structure, building up competence centers, competition is getting stronger, numbers are getting more serious, investors are getting more pushy.

But what all companies have in common, is that with each decision, they are building on their own legacy. It’s easy to choose a new hyped programming language or framework and write some fancy software. But after a while, no one in the market is using the chosen framework anymore. The company finds no one in the market to implement changes. The support for the framework has been set. There is no more support available for the framework. That leads to serious security concerns and increases the maintenance costs. And after some years, someone decides to rewrite the module in Java or Python. You think that’s not so common? So check out how many days have passed since the release of a new JavaScript Framework: https://dayssincelastjavascriptframework.com/. Or think about all the apps on your smartphone you are not using anymore and perhaps never have.

Tools, libraries, frameworks are one side of the coin. The other are processes, methods and ceremonies — the daily way of working. For example, a company decides to be an Agile Enterprise with all its implications. Companies decide to go this way because of specific benefits they see instead of following the old Waterfall mode, for example. But how does a company still know that they are following the Agile idea if teams can decide on all aspects, including how Agile they are. For example, can teams decide to stop doing daily standups or retrospectives?

Solve the dilemma between cost reduction with standardization and driving innovation by autonomy

Should a company give teams the freedom to choose their own way of working? It depends … Different aspects have to be considered. Especially in a modern Agile Enterprise, that decision should be made for each team. That decision depends on the product they are working on, on their own maturity and their past performance. The following table indicates the grade of autonomy in an Agile organization for teams:

Autonomy leads to high motivation of the employees, higher costs for the enterprise and faster innovations

Standardization shows higher burnout rate for employers and lower costs, but also higher trust from the management and external auditors. In the years of change, where companies are changing from Waterfall Enterprises to Agile Enterprises, the management must learn to let go and trust their people. Thats a process and trust has to be earned. That’s why we align the autonomy of teams in our solutions strictly to the team’s self. Depending on the maturity of the team, more autonomy can be owned; because immature teams don’t know what they don’t know.

Start with a standard and tailor it down to the team

Deciding the grade of autonomy on a team level leads to a fine-grained structure and should be balanced out and should reflect diversity across the portfolio. To decide that a team has less autonomy can be temporary. For example when we start a new DevOps team, the team has to implement our standard technology pipeline for Continuous-Integration, Deployment, Delivery and to follow strict all processes. This makes for a fast start and the team can learn the new culture, way of working and processes from other teams. When they get comfortable and show that they have some maturity, they can replace some tools and find their own way. They tailor our standard pipeline to their own requirements. First at high standardization, later at high autonomy when the risk for errors is lower.

How is your client or your team handling the dilemma between autonomy and standardization?