Following Up on Federal IT Modernization

Questions for Hana Schank, Director of Strategy, Public Interest Technology, New America Questions from Chairman Gerald E. Connolly regarding the July 20, 2020 hearing,How the Coronavirus Exposed Outdated Systems. 

Chairman Connolly: Did the federal government do a good job of ensuring a continuity of operations during the pandemic? 

Schank: It is hard to say exactly what a good job would look like in these circumstances. The federal government did not do a good job ensuring that the funds from the [Coronavirus Aid, Relief, and Economic Security] CARES Act could reach all intended recipients, or even that the people and companies it did reach were those with the most dire needs. Some of the blame for the failure to reach people falls on the IRS, whose site crashed and who also were then on the hook to create new tools so that non-filers could request money. To date, some money still has not been delivered. 

However, I wouldn’t classify this as a failure to continue operations. The IRS––and most federal agencies–– would have struggled to meet any new policy needs in a timely fashion because (1) the fast implementation of policy is traditionally kept separate from IT operations, (2) most agencies lack senior staff who can call attention to areas where policy cannot be implemented due to technical constraints, and (3) most agencies rely on contractors to make technical changes, which adds a layer of complexity and time.

Chairman Connolly: What impact do legacy systems have on the delivery of government services, especially during national emergencies like the coronavirus pandemic? 

Schank: It is not the existence of legacy systems, per se, that affect the delivery of government services. The fact that ancient systems are in place doesn’t help matters, but it is not the primary problem affecting government service delivery.  Legacy systems can be difficult to maintain because the workforce who knows old languages is ever-shrinking. They can be difficult to quickly modify because they are not written in the flexible languages we use today. But more importantly, legacy systems do not have the standard functionality the nation has come to expect from their interactions online. It can be impossible to track where your application is, for example, not because the system is written in an old language but because the idea that people might want visibility into where their applications are in a system didn’t exist as a concept when many of these legacy systems were created. To add this functionality on to an old system whose designers never expected people might want to do this can in some cases mean completely rewriting how the system works. So the best way to think about this is not that legacy systems negatively impact the delivery of government services, but that non-user-centric systems negatively impact the delivery of government services.

What that means is that it is difficult to quickly add on new functionality, or open systems and processes up to the public in the way the private sector does -- the way we have come to expect. But the larger issue is that not only is the federal government working with legacy systems, but those systems are typically administered by outside vendors, which means that there is very limited technical expertise in house. There are few federal employees who are well-versed in modern software practices, modern delivery practices, and how to ensure a smooth rollout of a new policy that relies on a technical infrastructure.

Chairman Connolly: You mentioned in your opening statement that “all policy decisions must include a tested delivery plan.” How can Congress incentivize agencies to think through IT investments that prioritize service delivery? 

Schank: Both Congress and federal agencies need to rethink the metrics that are used to judge IT projects as successful. Currently IT projects are monitored and judged based on self-reported data (i.e. project dashboards that are all green all the time, indicating that everything is going swimmingly) or judged purely on speed, budget, and whether something launched. 

But the metrics that should be in place to accurately judge a project’s success must be user-focused. Did the technology effectively and efficiently serve the people it was intended to help? Are wait times for a service within the acceptable range? Do end-users clearly understand what they might need and how to get it? What does the call volume look like on help lines? Have calls overwhelmed the system or decreased since a new service launched? These success metrics need to be clearly articulated, with plans for measurement in place, to weigh how well agencies executed past tech-related efforts and assess whether an agency is capable of running new projects.

Chairman Connolly: In your report, “Getting the Work Done: What Government Innovation Really Looks Like,” you discuss the need to “pivot the IT team to an innovation team.” How can federal agencies reenvision their IT workforces as innovation teams? 

Schank: The city-level IT teams who have been able to pivot to innovation teams were able to do so in part because they were run by people who understood the value of human centered design and service delivery. These people knew how to bring basic IT services like email up to speed, but once they had established a solid IT backbone they also saw that there was an opportunity to be involved in working within agencies to solve more complex problems. At the federal level this would mean bringing on agency CTOs who have a background in modern technology, but more importantly a vision for improving service delivery. 
For federal agencies to set themselves up for this pivot, the CTO role needs to be adjusted to encompass not only basic IT and cybersecurity, but also product development. This might mean splitting the role into two, or having someone just below the CTO who is responsible for keeping IT running, and freeing up room for the CTO to take on innovation projects. 
As a side note, this is something that wouldn’t be too hard to research by conducting interviews with current and past agency CTOs and existing IT staff. It would be really interesting and probably enlightening to develop a playbook on pivoting IT teams. I’d be happy to think more on how to make this happen.

Chairman Connolly: How important is it not only to consider technical skills but diversity in building a robust federal IT workforce?

Schank: Particularly when it comes to IT, diversity is critical to effectively understanding problems at their root and developing service delivery solutions. In interviews for my forthcoming book on public interest technology, my co-author and I heard story after story that illustrated the need for people with diverse backgrounds and experiences to be at the table when interpreting user needs and data, and when solving for big public problems. One woman who worked on the ELIS team at USCIS discovered that her background as a Spanish-speaking first generation American gave her insight into her immigration policy work that the rest of the team didn’t have, and led her to argue convincingly for the team to make the site bilingual. A data scientist from New York City told us he knew the city’s data on rat infestations was wrong because it didn’t correlate with his own experience growing up in a rat-infested neighborhood in Brooklyn. And a team in Durham, North Carolina working on reducing recidivism saw huge benefits in bringing a justice-involved resident with technical skills onto their team.

Diverse backgrounds have always been important in public problem solving. When a cholera epidemic gripped 1830s London, the source was a mystery. Dr. John Snow was an unlikely person to locate the source. He was a big shot doctor who attended to Queen Victoria during several of her births. The cholera epidemic was largely confined to poor neighborhoods, so most doctors blamed the outbreak on the perceived filthy habits of the lowest classes. But while Snow’s work had taken him to Buckingham Palace, he had grown up, and continued to live, just a few blocks from the center of the epidemic. Snow went on to map the outbreak data and traced the source to a contaminated well. Being “from the neighborhood” was as relevant to problem solving in Victorian London as it is now.

As the scope of technical expertise expands across the federal government beyond getting email to function and into policy delivery, it is essential to have people who are “from the neighborhood” ––whichever neighborhoods, cultures and backgrounds a given project touches –– on any technical project team.