Pahlka, a Californian, would end up suggesting to Park that she spend her year-long stint in Washington helping to stand up "the American GDS." The PIFs work bottom-up across federal agencies; they could be met, she thought, with an office in the White House providing top-down support. (Pahlka is quick to note that there were many others having the same idea at about the same time.) It launched on Aug. 11 as the United States Digital Service, or USDS.
But now the question becomes what success looks like for the USDS, and the two dozen or so technologists expected to serve as its crop of in-house experts. It is, explained Pahlka in an interview with The Washington Post this week, is "getting to the point where government can buy and build what it needs" in the way of digital technologies.
The USDS's British inspiration, though, also provides a preview of some of the challenges the new office might face. The U.K. arm of the multinational technology firm CGI has been vocally critical of the Government Digital Service's push to partner with tech start-ups and other small firms. (The company's subsidiary CGI Federal was the lead contractor on the $90 million contract for the troubled HealthCare.gov rollout.) "The government," Tim Gregory, the head of CGI's British operations, told ComputerWorld UK in 2013, "is making life difficult for IT vendors."
Pahlka insisted that the USDS isn't about cutting vendors out of the process. They're a critical part, she said, of figuring out how the U.S. can better handles its technology needs. It's just that they're not going to be the same ones that they've always been, working the same way that they always have.
Pahlka said that she hears the grumblings about the USDS -- along with the team of hands-on federal technologists called 18F that launched in the spring and is housed at the General Services Administration. The criticism starts with the premise that since the U.S. federal government will never be able to build all the technology it needs, it should stick to simply hiring outsiders well-versed in the ways of federal IT procurement. But that, she said, is "a weird logical leap."
How so? Figuring out what to build and what to buy requires more people in the ranks of federal service who truly understand how government and technology can meld, she said. "It's about, 'How does the government have the core capabilities in digital to make the right decisions?'" The British GDS's story thus far, she says, "isn't in-sourcing vs. better outsourcing. It's taking back control, re-crafting their approach in a user-centric way, and recreating the vendor ecosystem away from the big systems integrators and to smaller, more agile vendors."
Indeed, the core assumption baked into the USDS is an embrace of so-called "agile programming," the idea that the best software is built in small teams working in bursts of coding called "sprints," with expectations and features developed along the way. "From a distance," acknowledged Pahlka, "agile development looks pretty sketchy," particularly to a federal procurement official. "It says, 'We're going to contract with you and we don't know exactly what we've going to get.'" But, she said, it's how world-class software in the private sector is built today.
One thing USDS has on its plate, said Pahlka, is helping those responsible for buying technology scattered across agencies to figure how to write contracts that appeal to those sorts of small firms. The trick, she said, is often keeping projects small, and using language that one doesn't need to be a well-experienced 'Beltway bandit' firm to parse. Small, innovative shops might be curious about working with the federal government, but "they're not going to take their best people and put them on a project that's going to make everyone want to put a pencil in their eye," she said.
Gregory, the British CGI official, warned, "The first time one of these SMEs [small and medium enterprises] doesn’t deliver, when something goes pear-shaped, there will be no safety net. There’s no point in a government organization trying to sue them, there’s nothing to sue. It will be gone." (CGI has nearly 70,000 or so employees worldwide.) But in the U.S., at least, the momentum seems to be going in Pahlka's direction. About a month before the U.S. Digital Service launched, the White House Office of Management and Budget reiterated its support for "bite-sized" tech contracts. And the launch of the USDS was accompanied by the release of a 41-page draft "TechFAR Handbook" aimed at pointing out the "flexibilities" in federal acquisition regulations that allow for "iterative, customer-driven software development," as the document puts it.
Pahlka said that one of the breakthrough moments of her year in the White House came when a federal procurement policy official pointed out how little it would take to reconcile agile programming with how government IT contracting is done: line items -- those delineations of software features called for in traditional contracts -- could be swapped out for, she said, "Sprint 1, Sprint 2, and Sprint 3."
That approach is now detailed in the TechFAR Handbook, but is that really enough to change anything? "Change in government doesn't happen because someone writes a memo," said Pahlka. But technological change inevitably happens, even in government. Pahlka recalled that Mike Bracken, executive director of the British Government Digital Service, had a poster above his desk: "It says, 'Show me the thing.'" Translation: The way to make better technology is to demonstrate that technology can be better. Delivering that sort of proof throughout the federal government is perhaps the first task for the new USDS to tackle.
Pahlka has since returned home to northern California and the helm of Code for America, but she's still keeping close watch on what happens next. "A whole bunch of senior people in D.C.," she said, "have to start understanding that this needs to stop being about policy and start being about delivery."