More on this book
Community
Kindle Notes & Highlights
Read between
February 18 - February 23, 2024
having big budgets from the start can be deadly, since they often require an entire megaproject to be planned up front, reducing the ability of the team to learn as it goes.
More outsourcing can help with some aspects of service delivery, and contractors are a valuable piece of the implementation puzzle—but government can work well with these critical players only when it can bring its own basic digital competency to bear as
When all your time is spent answering questions and writing reports for other people inside government, it’s mighty hard to be focused on the people outside government you’re supposed to serve.
alienation and decreased political participation, which in turn lead to poorer service. The implementation crisis threatens our democracy.
WE KNEW THE first thing we needed to do was to define and count the EDD’s backlog of unemployment claims.
The State Department’s Bureau of Consular Affairs has been trying since 2009 to modernize and consolidate the systems that handle visa issuance, passport renewal, recording births abroad, and other services. It first projected a 2016 launch date, then announced a two-year delay. In 2019, it began a limited pilot of one component of the new system at six locations, out of hundreds of its embassies and consulates around the world. As of late 2021, the bureau still had not expanded that pilot and the other components still had not launched. The program’s cost, originally estimated at $18 million,
...more
now the EDD had a replicable set of queries its team could run that measured the backlog consistently each week.
The PowerPoint presentations commonly given to executives are sorely insufficient.1
Programs like unemployment insurance need to be able to scale up, and they need to be able to scale down.
The only way to ensure that a system can scale up is to address its chokepoints. At the EDD in California, that’s the recomps, those claims that need to be handled manually.
If we want services that scale to meet people’s needs, it’s not just a matter of building new technology. It’s a matter of clearing out the clutter it rests upon.
the agile manifesto says at the top: “Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.”
“I’ve spent my entire career training my team not to have an opinion on business requirements,” he told me. “If they ask us to build a concrete boat, we’ll build a concrete boat.”3 Why? I asked. “Because that way, when it goes wrong, it’s not our fault.”
A SURE SIGN of a waterfall organization is how the people within it treat data. In an agile, empowered organization, data is a useful tool for adjusting course. The people in the organization not only have access to data and the ability to understand it but have the power to decide what to do based on it. If the compass says you’ve drifted off course, no one summons the inspector general or calls for a hearing. You just turn the wheel.
In a waterfall organization, on the other hand, data functions less like a compass that helps you steer and more like an after-the-fact evaluation, a grade you get that says how well or poorly you did on something that has already happened.
General Stanley McChrystal put it this way: “I tell people, ‘Don’t follow my orders. Follow the orders I would have given you if I were there and knew what you know.’”
The more trouble a project is in, the more oversight it gets, and more oversight almost always means stricter compliance with requirements, not finding creative ways around them.
Government’s obsession with requirements—voluminous, detailed requirements that can take so long to compile the software is obsolete before it’s even bid out—stems from a delusion that it’s possible to make a work plan so specific that it requires no further decision-making.
The redesign of the health care application form at the VA was a triumph of outcomes over process. Sadly, though, process usually wins, as it won on the satellites. That public servants get held accountable to process over outcomes is well known;
servants—they manage, but they don’t implement. One hundred percent of the implementation is contractors.”
But Mike’s biggest problem wasn’t the deadline or the procurement rules themselves—it was the prevailing operating model that says that government staff manage but they don’t implement. Especially not when it comes to digital. They rely on contractors for that.
Those practices might feel like they have the force of law, but a closer look will often reveal them as mere clutter.
what government leaders mean is that the core of their work is policy.
(While the federal CIO focuses on the government’s internal tech systems, the CTO typically acts more as a tech evangelist and adviser, serving within the White House’s Office of Science and Technology Policy.)
Why did the contractor do that? “I saw other lines had these slashes so I thought I should put them in too,” he explained.
Just as government’s core competency has been in contracting with vendors, some vendors’ core competency has been in getting those contracts. They may have lots of people who do account management and project management, but they don’t always have the people who can make the websites work.
Eighteen years earlier, Clinger and Cohen had asked the White House to develop a strategy for digital technology, but OMB hadn’t wanted to let the mechanicals in the building. That decision came back to haunt them with healthcare.gov. The need for basic digital competency cannot be unclear now. But as they say, culture eats strategy for breakfast. The culture still has a ways to go.
SNAP applicants were by definition low-income, and most low-income people use the web through their phones. So at Code for America, when Jake developed applications for safety-net benefits, he built them to work on mobile phones from the start.
Today, when digital professionals come into government ready to build services for the American people, they are shocked at how hard it is to build anything at all. It’s not only because the government policies they are attempting to digitize are enormously, needlessly complex. It’s not only because they have to spend so much of their time on procurement, since the actual code writing and interface design must all be outsourced. It’s not only because seemingly arbitrary aspects of their work have been wildly overspecified by distant rule makers with little understanding of the problems at
...more
bottom of the hierarchy, where they have little voice or power. It’s also because the administrative agencies many of them work for were designed—on purpose—to be unable to make the kinds of decisions that good software development requires.
“vomited the policy into the forms.”
The first principle read “Start with needs.”
the need to be treated with dignity. When services respect our time, minimize intrusion, use language we understand, and don’t make us feel stupid, that deeply broken relationship with government can start to mend.
Project management is the art of getting things done. Product management is deciding what to do in the first place
the site had a lot of project managers but no product manager.
Byrne, the guy who built the broadband map for the FCC, estimates that most government tech projects could cost 10 percent of what they do and still provide 85 percent of the functionality.5 I hereby dub this “Byrne’s Law.
“You can have either one site in English that works or two sites that don’t,” Mina told the CMS administrator. Tavenner apparently didn’t like the answer. She hung up in the middle of the call.
Once a program is established in government, its value is rarely measured by usage or utility. (In fact, low usage is often welcomed because it doesn’t create scaling problems. Recall all the people at the VA agitating to go back to the online form that made it so hard for veterans to apply for health care—because so few people used it.)
You cannot get the benefits of product management and agile development in a top-down culture—these practices require that “mechanicals” working on details of implementation be able to exercise meaningful judgment, and even to weigh in on issues out of their lane.
Mostly, technologists in government simply prefer the impact they have.
After our EDD task force disbanded, as Marina Nitze and I were reflecting on what the future might hold for the agency, I lamented the fact that no more than a handful of people there knew how its systems worked. Marina corrected me. No, she said: a handful of people there knew how some individual pieces of the system worked. There was no one who understood how it all worked together.
