Widgetized Section

Go to Admin » Appearance » Widgets » and move Gabfire Widget: Social into that MastheadOverlay zone

Should Government Agencies Have Dual “Operating Systems?”

The views expressed are those of the author and do not necessarily reflect the views of ASPA as an organization.

By Bill Brantley
September 1, 2015

handoff - brantleyPeople demand more innovation from the government, but they also want dependability. As I often heard in meetings when I was a federal employee, citizens want government services that are as easy to access as buying something from Amazon.com.

Starting with the personal computer revolution in the 1980s and the DotComs of the 1990s, people are used to receiving quick, personalized service and products at an ever-increasing rate and with greater innovation. Government agencies are working hard to provide innovative services in a customer-friendly way. Even so, as recent news stories have shown, many government services are still hard to obtain.

The problem is not lack of innovation. Several agencies—from the General Services Administration to the Office of Personnel Management to the Department of Health and Human Services—have groups that provide highly innovative solutions. Either in an innovation lab or through 18F, there is no lack of groundbreaking ideas for better government services.

However, having a great idea is only part of the solution. Implementing the innovation into the agency’s existing business processes is where most innovations fail. According to some authors, it is because of the difference in the innovation “operating system” versus the execution “operating system.”

A Startup Connected to a Mature Organization

John Kotter introduced the concept of dual operating systems in his 2014 book, Accelerate: Building Strategic Agility for a Faster-Moving World. He describes how organizations start as a network of individuals where communication and innovation flow freely in a flat, highly-connected small organization. As the organization grows, it becomes hierarchical so as to deliver efficiently products and services. This is necessary so that organizations can build and scale up business processes to deliver to a larger customer base. Except, in the pursuit of efficiency, innovation becomes lost.

Kotter suggests that hierarchical organizations build a startup network inside the organization. Employees would periodically cycle to the startup operating system to develop new services. Then, employees would come back to their jobs in the hierarchical operating system to help integrate the innovations into the hierarchy’s business processes. The advantage is that the handoff between the operating systems is a smooth transition for the innovation.

Running the Performance Engine While Rebuilding It

Kotter was not the first to suggest the dual operating system. Vjay Govindarajan and Chris Trimble discussed dual operating systems in their 2005 book, Ten Rules for Strategic Innovators. They expanded on this concept in the 2010 book, The Other Side of Innovation: Solving the Execution Challenge, by describing how to use an innovation team to perform innovation experiments. The successful experiments are carefully integrated into the organization’s performance engine (the collection of business processes that handle delivering the organization’s services and products). Again, the key lessons are how to conduct the transfer of the innovation from one operating system to the other without severe disruption to the organization’s delivery of services.

Staying Out of the Garbage Can

Eventually, adding new business processes while retiring the old business processes will result in a completely new Performance Engine. This risks building an unfocused and inefficient Performance Engine that is a collection of contradictory business processes. This is Cohen, March and Olsen’s “Garbage Can Model” embodied as the organization’s new performance engine (read the original 1972 paper). How does the government agency plan the implementation of their innovations so that the performance engine evolves to better deliver the strategic mission?

As I have written in a previous column, government agencies can use three techniques from lean startups to help tune their performance engine. The first technique is to focus continually on the customers’ needs while also aligning all business processes to the agency’s mission. The second technique is to build metrics into all of the processes to track the performance of the business processes and the alignment with the agency’s mission. Relentlessly focusing on carving away processes that do not focus on the customer and the agency’s mission is the third lean startup technique. These techniques should guide both operating systems as they collectively build and implement innovations.

Why Government Agencies Need Dual Operating Systems

Government agencies are under great pressure to be more innovative in delivering government services while dealing with smaller budgets and fewer resources. Agencies are and have always established dedicated teams to innovation. Nevertheless, as the garbage can model demonstrates, agencies can do a better job of implementing innovations into their business processes. Many agencies already have dual operating systems. Realizing the existence of dual operating systems can help agencies improve how innovations are handled between the two operating systems. Dual operating systems, when coordinated effectively, can generate great innovations and implement those innovations for better government services.

Author: Bill Brantley teaches at the University of Maryland (College Park) and the University of Louisville. He is also a former federal government employee. All opinions are his own and do not reflect the opinions of his employers. He can be reached at  http://about.me/bbrantley. 

1 Star2 Stars3 Stars4 Stars5 Stars (1 votes, average: 5.00 out of 5)

One Response to Should Government Agencies Have Dual “Operating Systems?”

  1. Julie Ann Racino Reply

    September 2, 2015 at 10:56 am

    Government efficiency by weeding out the old and bringing in the new (modernization and upgrades) must be “executed” in the context of quality of life values and cost-benefit outcomes.

    “Carving out programs” needs to involve describing the initiative, the purposes, funding and the outcomes to date, and projections for upgrading, replacement or growth.

    The 1970s community groups, however, do not appreciate that the programs often have remained categorical in disability fields, before further “carving out” occurs.

Leave a Reply

Your email address will not be published. Required fields are marked *