Don’t Fight Regulation. Reprogram It


Article by Alison Kutler and Antonio Sweet: “Businesspeople too often assume that the relationship between government and the private sector is (and should be) adversarial. They imagine two opposing forces, each setting their bounds of control. But if you can envision government and business as platforms that interact with one other, it becomes apparent why the word code applies to both technology and law. A successful business leader works with regulation the way a successful app developer works with another company’s operating system: testing it, providing innovative ways to get results within the system’s constraints, and offering guidance, where possible, to help make the system more efficient, more fair, and more valuable to end-users.

Like the computer language of an operating system, legal and regulatory codes follow rules designed to make them widely recognizable to those who are appropriately trained. As legislators, regulators, and other officials write that code, they seek input from stakeholders through hearings and public-comment filings on proposed rules. Policymakers rely on constituents, public filings, and response analysis the way software designers use beta testers, crash reports, and developer feedback — to debug and validate code before deploying it across the entire system.

Unfortunately, policymakers and business leaders don’t always embrace what software developers know about collaborative innovation. Think about how much less a smartphone could do if its manufacturers never worked closely with people outside of their engineering department. When only a small subset of voices are involved, the final code only reflects the needs of the most vocal groups. As a result, the unengaged are stuck with a system that doesn’t take into account their needs, or worse, disables their product.

Policymakers may also benefit by emulating the kind of interoperability that makes software effective. When enterprise systems are too different from each other, people struggle with system unfamiliarity. They also run into interoperability issues when trying to function across multiple systems. A product development team can devote massive amounts of resources to designing and building something to work perfectly in one operating system domain, only to have it slow down or completely freeze in another…(More)”.