An Insider’s Take on How to Focus on Government's IT Strengths

For Ed Mullen, a designer who has been around government tech for more than eight years, two things could fundamental change the way governments deliver social services: APIs and a focus on user experience.

As his term with 18F comes to an end, Mullen shared six strengths he sees in the current state and federal tech ecosystem and how he believes these should be leveraged to improve service delivery at every level.

“Much of the technology that people use to access safety net programs and that states use to administer these programs is aging and crumbling, despite significant spending and effort to modernize,” said Mullen, who began working on federal tech issues during the initial rollout of Healthcare.gov in 2011.

Mullen did a two-year stint with Health and Human Services Department before the creation of the U.S. Digital Service and other similar programs. He later joined one of those programs—the General Services Administration’s 18F—in 2016.

The main problem with government’s modernization efforts is the process, Mullen says.

“We ask over-stretched, insufficiently technical state staff to modernize massively complex computer systems by adhering to federally-provided checklists and oversight regimes, working with massive vendors through multi-year contracts worth tens or hundreds of millions of dollars,” he wrote on GitHub. “Federal agencies are not well positioned to quickly drive change in the market or provide technical oversight that accelerates modernization rather than impedes it.”

Following these processes forces agencies to rely on their weaknesses, rather than their strengths, he argues.

Through his post—a sort of self-administered exit interview—Mullen attempts to highlight government’s strengths and areas where those can be leveraged to support modernization and, more importantly, the delivery of quality services to citizens.

Mullen lists six strengths, though some are targeted more toward state governments. However, as the first strength notes, creating a dividing line between state and federal is often a problem.

“Today's rigid separation between federal program/policy design and state technical implementation has bred an ecosystem characterized by stagnation, duplicative effort, system failures, waste and poor outcomes for our neighbors involved at each level,” he writes.

Mullen points out that while federal agencies generally set the standards for the kinds of social services states are required to provide—including for whom and the manner and the kinds of data to be collected—it lands on state governments to build and maintain those systems. The current state of software development makes it easier to create barebones solutions at the federal level that can then be distributed among the states, as needed.

Mullen describes this as a “loosely-coupled ecosystem” and offers an idea of what that would look like:

This loosely-coupled ecosystem would have new pieces that are operated by the federal government that states can integrate with and use. It would utilize inexpensive commodity tools offered broadly in the private sector. Microservices from companies would be employed where appropriate to provide functionality the companies are uniquely positioned to offer. Custom development would be reserved for situations where other options are not available. Application programming interfaces (APIs) would assemble all the pieces into user-centric products which would be deployed on cloud infrastructure.

Similarly, he argues that federal agencies with the responsibility to set requirements around who is eligible for services should digitize those criteria. Rather than force states to develop individual algorithms to determine eligibility, Mullen suggests feds should build those as APIs that can then be integrated with state-level applications.

In his post, Mullen lays out a five-step process for how this would work.

This suggestion dovetails in the third: collect citizen data once, where appropriate, and share relevant information with other systems.

“We know people are frequently eligible for multiple programs designed to address different need. They need the ability to determine eligibility and apply for multiple programs all in one place, in as few steps as possible,” he writes. “Data should be entered in aggregate for all relevant programs in the most intuitive way for the applicant … and then used to determine individual programs behind the scenes.”

Mullen also suggests taking the customer experience focus further, citing work done by his colleagues at 18F, as well as the U.S. Digital Service, Code for America and others. The lessons those teams have learned about improving user interfaces and the overall process can be used at the state level, as well.

Mullen’s fifth point turns the previous suggestion on its head, focusing on the usability of the apps from a state employee perspective.

“States don’t have the resources or expertise to make these systems modern, usable and empowering,” he writes. “It’s unreasonable to ask states to continuously improve their systems based on continuous user feedback loops with their current mix of staffing and skill. And we’ve learned incumbent vendors are not incentivized to build great experiences for workers.”

The post includes a link to an unfinished prototype of what that employee user experience could look like. Mullen notes this is incomplete and said he is actively looking for feedback on how to improve the prototype.

Finally, Mullen looks at the unwieldy task of modernizing legacy systems. Here, he focuses on the state-level, suggesting governments should “unwind their legacy systems through a series of incremental improvements,” rather than just ripping and replacing.

While Mullen offers some concrete steps and prototypes for consideration, he admits this is only a starting point that will create as many questions as answers.

At the end of the introduction, he includes a caveat: “Grandiose concept pieces like this are always wrong. Or rather, they get a lot of things wrong. The point is to move the conversation along and attract participation in rethinking broad assumptions and conventions.”

In an email with Nextgov, Mullen also asserted that his thoughts are not necessarily representative of his employer—GSA—nor does he claim to represent the entire government technology field.

“But as a person who has worked on the issues, I've formed perspectives that I've wanted to share as the ideas of an individual for consideration by the people I have come in contact with,” he said.