Public infrastructure and government IT have a lot in common
Our public infrastructure is in bad shape. A federal report from 2006 deemed 70,000 bridges “structurally deficient,” the American Society of Civil Engineers gives our infrastructure a “D+” grade, and the issue has even been featured on popular television programs like 60 Minutes and The Daily Show. But when it comes time to spend money on this vital infrastructure, our governments are reluctant to open the pocketbook until we reach a time of crisis.
Government IT is no different.
After four years building software that works to improve how government manages its day-to-day operations, I’ve started taking note of the parallels. Instead of falling bridges, we have catastrophic cybersecurity incidents like the recent data breaches at OPM and the IRS. Instead of crumbling roadways that rob the public of fuel and maintenance costs, we have IT systems that rob citizens of benefits and drive public servants to insanity. It would be myopic to only acknowledge the high-profile systems like Healthcare.gov that fail to launch. Our focus should also be on the systems that are already in place, costing the taxpayer millions of dollars in maintenance and support, but delivering terrible results. But despite the hand-wringing, government is not making enough smart investments in IT. Instead of fixing the broken existing systems, government keeps doubling down on new initiatives. Why are we investing in the internet of things, when over and over again, we fail to ship basic, functioning CRUD apps.
This reality has significantly impacted how we sell Screendoor, our product that helps government publish and manage online forms. Forms are the perfect example of IT “infrastructure.” They’re ubiquitous, each one is more or less the same, and the current experience for both citizens (print a PDF, fill it in, and mail it) and government employees (send the paper form to three departments for signatures, then file it) is awful, not to mention the monetary and environmental costs of doing business on paper. In an ideal world, government IT departments would realize that this is a shared need across all agencies, and procure a scalable, modern solution for government-wide use.
But when we go out to sell Screendoor, this isn’t the strategy we use. We don’t go to the head of the IT Department and say, “Here’s a piece of software that’s going to make your agencies love you.” The IT department has no interest; they’re already overwhelmed with supporting the crumbling infrastructure they have, and when it comes to implementation of new systems, we’d be contending with their backlog of issues, their budget and implementation cycles, and any existing enterprise contracts that they might be locked into. To work on these terms, your company needs to be built to win government contracts, not to deliver great software.
At DOBT, we’ve mitigated this problem by going into an agency and trying to find a single isolated, high-profile use case. Do you need to hire some innovation fellows? Screendoor can help create a site that’s a lot friendlier than your current jobs portal, and if it works out, we can start the long process of expanding its use. Do you have a high-profile RFP that you want to advertise to the community? Do a pilot of Screendoor, and if it goes well, we can make the pitch to replace your citywide RFP system. Unless we attach ourselves to an issue with political priority, it’s impossible to achieve the momentum required to address the infrastructure issue.
We’ve managed to grow our business this way, but it’s limiting and frustrating. I’m worried that while we’re busy working on problems that have PR and marketing value, beneath the surface, legacy technology is eating away at government’s ability to serve its users.
If you work in government, I’d love to hear your own struggles with this issue so we can work on it together. You can email me directly or respond in the comments below.
Header image used under a CC-BY 2.0 license.
Adam Becker is a co-founder of The Department of Better Technology.