Insight

When policy is created without technological considerations in mind, it can often be convoluted and unnecessarily complex by the time it reaches the implementation phase. The result is systems that may deliver immediate requirements, but fail to offer flexibility and scalability to adjust to ever-evolving policy and user needs. Changing these patterns isn’t easy, but it is necessary if we want to improve how we deliver digital services, and ultimately govern effectively.

Injecting technological thinking into policy making from the start to finish of the policy lifecycle will ultimately deliver more robust, flexible systems that serve people’s needs.

Through Nava’s collaboration with the Centers for Medicare and Medicaid Services (CMS) on the Medicare Quality Payment Program (QPP), we’ve been promoting technology-minded policy to make the largest change to Medicare since the program’s inception, impacting 34 million Medicare beneficiaries and $178 billion in payments to doctors. To do this successfully, we have a two-pronged approach that bridges the gap between policy makers who define requirements and the product development teams who implement them.

Understand the policy behind technical systems

Engineers need to stay educated about the legislation our government puts into action and how technical decisions may have downstream impacts on users. Decisions cannot be made in silos. Policy and user needs must hold the same weight as technical architecture considerations. If we fail to do this, we risk creating systems that exacerbate policy complexity and don’t allow for iteration.

This can involve a pretty significant culture shift — from digesting requirements verbatim as they are written in legislation, to thinking critically about the features your team implements. At Nava, we have a strong practice of writing technical specifications before diving into feature implementation. Engineers on our team have the space to ask questions about the background of a feature and flesh out alternate implementations.

We utilized this critical thinking approach when we defined the interface of the QPP Submissions API. We were told the rough shape of the data we were required to collect and our engineering task was to define the schema that the API would use to accept that data. We did not stop there, though. We asked questions to understand what this data meant and how it would ultimately be used. We wanted to know what outcomes policy was trying to drive and if there were any engineering choices that could help make for a more efficient solution.

The answers we found were that some of this data was being collected purely as relic of a legacy system and that it wasn’t going to be used for analysis. Not only does this require engineering work to support and maintain, this also leads to a poor user experience when the data you submit to an API is being ignored. With the policy context in hand, we advocated for certain fields to be omitted from our API, thus simplifying the system and reducing compliance burden for our end users.

Find common language for technical tradeoffs

Equally important is making sure that our policy partners are educated about technical decisions. It can be tempting to come up with vague explanations when working with folks with non-technical backgrounds, but our work on QPP is a success story of what can happen when we don’t shy away from walking policy folks through hairy technical issues.

We frame technical decisions in terms of the things that both our teams care about: user impact and developer productivity. For example, instead of saying a piece of technical debt is important because our proposal is the “right” way of doing it, we focus on how prioritizing this technical debt will improve the speed of our API and thus create a better user experience. We show that it will also save time for future feature development since tests will be easier to write and maintain.

By finding this common language, we have been able to better explain the reasoning behind a recommended technical approach, and get buy-in from our key stakeholders to prioritize that work in our product roadmap. In fact, we now have policy stakeholders who, when triaging incoming feature requests, will seek out the engineering and product team to better understand technical implications prior to making a decision.

This upward stream of knowledge, from engineering to policy, is a gift that keeps on giving. And it shows — the Quality Payment Program CMS exceeded its first year participation goal.

By taking the time to thoughtfully explain technical tradeoffs and answer policy questions about them, we’ve empowered our policy partners to make choices with engineering in mind, even when we are not in the room.

We hope that this is the start of a greater movement in policymaking and service delivery, where engineering solutions are considered not just when finalizing details, but as legislation is being drafted and passed. In the process of shipping the largest change to Medicare, we’ve demonstrated how a successful partnership of policy and engineering can help create a stronger technical system and drive better outcomes right now and in the long term.

Shoutout to our government partners at CMS, Manoj Nagelia and Chris Reinartz, and at USDS, Lucas Merrill Brown and David Koh, who have been steadfast champions of this approach.