policyOS: Policy as the Operating System for Business

Countless technology companies are trying to build the next killer app - a new platform or program that will revolutionize the way people interact with each other using cutting-edge devices and systems. When renowned companies unveil a new feature or service, it can become headline news as loyal users rush to try it when it goes live.  But some may take for granted the fundamental layer of code that their favorite apps sit on top of: the operating system - a deeply embedded set of code that enables and regulates the capabilities of the applications. What was once a quiet, uninteresting, but necessary software update is now a grand unveiling by tech executives to auditoriums packed with developers and fans. They recognize how important it is to be attuned to the latest and greatest operating system architecture because it serves as their platform and toolkit for innovation.

Now imagine a company as a literal app downloaded to that ubiquitous device. In this framework, the embedded operating system regulating its capabilities and interactions would be government policy. Far too often, people see an adversarial relationship between government and business - two opposing forces pushing against each other to set the bounds of control. But once you envision them as layers in the stack, it becomes apparent why the word “code” is used in technology and law in similar ways. Both app developers and business leaders provide innovative ways to connect and serve users while policymakers establish and update the underlying capabilities for those valuable services.

As legislators, regulators, and other officials write that foundational code, they rely on input from stakeholders, through mechanisms such as hearings and public comment filings on proposed rules.  In a sense, policymakers use beta testers, crash reports, and developer feedback to debug and validate code before deploying it across the entire system or jurisdiction. Think about how much less your smartphone would do if its manufacturers never collaborated with people outside of their own engineering department. More importantly though, if that collaboration only comes from a small subset of voices, the final code will only reflect the needs of the most vocal groups - leaving the unengaged stuck with a system that doesn’t take their needs into account, or worse, disables their product.    

Not only can issues arise from a lack of system familiarity, but technology can also run into interoperability issues when trying to operate in multiple systems. A product development unit can devote massive amounts of resources towards designing and building something to work perfectly in one domain, only to have it slow or completely freeze in another. These are the same concerns that businesses face when they cross borders; a different set of code changes the behavior of a function and introduces new bugs that must be addressed for users to have the best experience possible with the product. Interoperability concerns emerge from city to city, between states, and across oceans -  different jurisdictions with different sets of code create more complexity, demanding that “policy engineers” develop awareness and fluency in each region and at each level to make the product a success.

This is not insurmountable with the right strategy and strong allies. Just like the collaborative standards bodies continuing to develop Bluetooth, USB, and Internet Protocol (IP), businesses can motivate public officials to come together and codify agreements that streamline unnecessary complexity instead of burdening providers with different versions for different users in different places. This was the intention of agreements like NAFTA or the foundation of the European Union - common, widespread code designed by consensus. However, the recent phenomena of Brexit and US trade re-negotiation reveal that this trajectory is not inevitable. Members of associative bodies can re-prioritize features of governing code for their user base and reverse prior collaboration among policy makers built on compromise of nuanced needs for the sake of operating under a single system. With disruptive changes like these, businesses need their policy engineers even more closely involved in the code-writing process as complexity increases.

Ultimately, technologists need to promote an evolution of policy that keeps pace with  technology itself in order to bring next-generation solutions to market as effectively as intended. To achieve that, private sector leaders need to determine if their policy “engineers” have the proper tools and internal support to strategically reform “policyOS”, in turn providing optimized services to improve the lives of consumers. As users understand those benefits and the impact of policy on their lives, they too will be packing the halls of government buildings to help develop the most powerful operating system we have and enable the future that technology promises.

Contributors: Antonio Sweet