New York City needs durable solutions to the tech problems that plague government.
On July 3, the Mayor’s Commission on Government Efficiency published a preliminary report that included the most accurate diagnosis of government IT dysfunction I've ever read from a political body — and I’ve read a lot, having led federal implementations of Congressional legislation and White House executive orders. Typically, such publications focus on vague notions of innovation and technology trends. But in its recitation of testimony COGE received, the report cited operational inefficiencies around processes like procurement and hiring as the real culprits of public sector technological mediocrity: “Why does it take so long to buy technology in government? What do we do about the fact that by the time we get through the procurement process, the technology we thought we wanted is obsolete? Why can’t we hire and retain the talent we need so that we are less dependent on outside vendors?” The individuals who provided this testimony were 100% correct: Government technology isn’t technologically difficult. It’s an administrative headache.
Ten days later, City Hall announced its PIT Crews: five small product teams, hired by the Office of Technology and Innovation (OTI), that will parachute into agencies and build digital tools for the mayor's signature policy initiatives.
Together, the COGE initiative and the PIT Crews looked like a smart two-pronged strategy: Lay the groundwork for agencies to improve their IT through better procurement and hiring practices, while simultaneously employing a bureaucracy hack to accelerate the arrival of results.
But then, on July 23, COGE released its final report, laying out five proposals for voters to approve or reject on the November ballot. The IT and bureaucracy reform ideas were gone. There were no draft ballot initiatives to require technology procurements to support modern technology practices, or to require the City to offer civil service exams for IT positions more than once a year. What survived were proposals to speed up street redesigns, tweak procurement, streamline housing permitting and the like.
Where did the good ideas go? They were relegated to a summary of discarded ideas on the final page of the report, in a section called “Building the government of the future.” Contrary to the testimony cited in the preliminary report that procurement and hiring policy were the levers for reforming technology, the final report claimed that OTI was already “working to transform how City government operates.” This is a huge task for a City Hall office with relatively little authority over how individual agencies operate. COGE could have recommended a charter revision that gives OTI real power — for example, authority to kill contracts that don’t follow certain standards — but curiously opted not to. This was perhaps COGE’s greatest missed opportunity.
The timing makes it hard not to draw conclusions: The preliminary report had real ideas for technology reform, OTI and its PIT Crews stole the scene and COGE delegated the matter of government reform to them.
But as currently envisioned, the PIT Crews will not provide any durable improvements to City technology. Their goal is to build one-off digital products, following the playbook of the U.S. Digital Service (USDS). COGE’s final report cited USDS as an inspiration for OTI’s efforts. (New York City’s new Chief Technology Officer and OTI Director Lisa Gelobter is a former USDS official.)
Consider how USDS performed its work: When the White House deemed a federal agency incapable of building a digital companion to a policy initiative, USDS would “parachute in,” build the product for the agency, put agency branding on it, and depart victorious. Relying on preferential treatment from agency staff, USDS received fast approvals for cybersecurity accreditation, new staff, IT infrastructure changes, data access, Privacy Act review and other processes that take all other IT programs months or years. The contractors that supported USDS often received competition-free contracts, reducing a years-long procurement process to a few months. And USDS staff often used outside, non-federal systems to perform their work, a violation of protocol that only White House staff could get away with.
These are expedient hacks that I’ve used myself. They’re the tactics civil servants employ in an emergency. They are not strategies for government reform at scale. For every system that gets the political cover to take these administrative shortcuts, there are thousands of invisible, unglamorous systems that keep governments afloat. Making those systems better requires labor, and the people who would provide it are stuck in hiring and procurement backlogs.
Yes, the state of federal IT is bleak, and working strictly within the confines of the system would have kept USDS from getting anything done. But instead of bulldozing the bureaucracy for the benefit of every IT program, USDS just walked around it, celebrating a handful of wins while leaving the walls in place for thousands of other, less-glamorous systems. Combined with the fanfare and go-karts that accompanied the mayor’s July 13 announcement, this history makes the PIT Crews feel like innovation theater. Everyone in public sector technology knows that it’s possible to build great technology when there are far fewer administrative constraints. The challenge — which COGE articulated so well in its preliminary report — is to change the constraints for government IT at large.
There are real opportunities to do so, without state intervention or City Charter amendments. First, the City must change the way it procures software services. The typical contract is full of specifications about what a vendor shall build, and bundles everything into one large, complex, “big bang” effort. This not only slows the procurement process down, as it makes standardization across contracts impossible — it also delivers worse results. Overspecification was a primary cause of two of the City’s biggest software modernization failures: CityTime, the City’s employee timekeeping system, and Emergency Communications Transformation Program (ECTP), an attempt to overhaul the 911 system. In both cases, the City entered into large contracts with vendors confident about what had to be built, despite the enormous administrative complexities that each system had to navigate. Repeated modifications to the scope ballooned the CityTime contract from $63 million to $700 million. ECTP was delivered 10 years late and $1 billion over budget.
This practice of pre-defining extensive, detailed functional requirements is generally known in the software industry as “waterfall development.” Over the past 30 years, the waterfall methodology has been displaced by the Agile methodology, which emphasizes fast iterations of evolving requirements based on constant feedback from users. This prevents teams from having to make guesses about what customers will want in several years when the project is complete. With Agile, the focus is always on what customers want right now. And by distilling an impossibly large, “big bang” effort into many smaller, more achievable pieces, it increases the odds of success.
OTI heard this lesson in advance of the MyCity contract, but didn’t internalize it: According to a Comptroller audit of the MyCity program, OTI staff claimed they “used an agile approach,” yet they still contracted a firm to develop functional requirements. The use of the word “agile” is telling: Agile, with a capital A, is a professional term of art. I routinely see government contracts for software services that call for traditional waterfall methods, yet are littered with the word “agile,” as if simply repeating an adjective will impart its characteristics upon the author. Even the Comptroller’s final recommendations for MyCity reached the wrong conclusion, stating that OTI should “develop a clear and detailed project plan for MyCity’s end state, with detailed functional requirements and time and cost benchmarks.”
To prevent future software boondoggles, the City should require software development services contracts to be short and simple: devoid of product-specific functionality requirements, and phased in a way that requires a program to make progress before committing more funds to the effort. OTI does not have the power to force agencies to do this, but the Procurement Policy Board and the City chief procurement officer do.
For better hiring, one PIT Crew should be dedicated to the task of building better recruiting tools for every City agency. The City employs over 4,000 IT staff. While the City may have little control over the application process for these jobs (that’s the purview of the State, and largely constrained by a century-old civil service system), it can do a lot to improve its marketing of these positions and attract better candidates. For most vacancies, the status quo is what we call “post and pray”: Post a job announcement to a web site, and pray that good candidates find the announcement and apply. USDS proved that a strong online brand and a call to mission will attract great candidates. This is one page from the USDS playbook that the City should follow. After all, PIT Crew marketing has already inspired thousands of candidates to join public service.
Rather than limiting this success to dozens, why not empower every agency to recruit in the same way, drawing thousands of great people into the City HR pipeline?
Upon landing, PIT Crews will quickly discover that their host agency’s infrastructure is not ready for a modern web product. To make their products work, they will need to fetch data from, and write data to, legacy agency systems that were built in the 20th century before the internet was contemplated, and have no modern interface for such data transactions. Many of these systems won’t even have documentation that explains to PIT Crews how they work. In the most extreme cases, the PIT Crews will encounter entrenched vendors who are the only people who can answer such technical questions, but do not want to relinquish control of a public system that they consider proprietary. A recent Comptroller audit found that such integration challenges were one cause of the failure (thus far) of the MyCity program.
It’s too early to know exactly which legacy systems PIT Crews will encounter, but here is a hypothetical example presented simply in order to make it more tangible: A Click to Cancel digital product might conceivably need to connect to a City financial system like the Financial Management System for Accounting (FMS/3) in order to levy non-compliance penalties against a business. What will happen when a PIT Crew knocks on the door of the Financial
Information Services Agency (FISA) and asks to connect their new web application to FMS/3? Perhaps it cannot happen without great technical effort; a recent Comptroller report said that FISA’s systems are “old and fragmented.” Or maybe such integration is technically possible, but the FISA staff cannot explain how the system works; the same report says that FISA staff are inordinately retirement-eligible and are not being replaced due to insufficient recruiting efforts. Or maybe the incumbent vendor, whose contract expires at the end of 2027, does not want to help an effort that could render them less essential.
While daunting, these problems present the PIT Crews’ biggest opportunity for citywide IT reform — assuming they approach their job more expansively than it seems they’re poised to. Unlike the other, non-technological barriers to innovation like hiring and procurement, the solution here lies in software code. In all likelihood, PIT Crews will overcome such problems with technical ingenuity and tenacity. They will have two options: stop streamlining the legacy system the moment it begins working with their own product, or go the extra mile, polishing their workarounds and publishing documentation for how they work. A workaround for one product can become a City-wide service that every system can leverage, unlocking data and interconnections that will benefit countless other City systems beyond those that are politically important to the mayor. While unglamorous, this is the true work of government modernization.
Finally, PIT Crews can promote better technology culture via a single mantra: Demos, not memos. Government agencies traditionally fail to rigorously monitor the progress of IT projects. In recent years, the City Comptroller has published multiple audits that found that New York City agencies aren’t performing basic evaluation of vendor performance.
This happens because governments measure progress in terms of paper: To demonstrate work completed, a vendor will typically show a PowerPoint deck with Gantt charts, rather than showing the actual results of their work. Contracts routinely tie vendor performance to metrics that are wholly unrelated to whether the vendor is building a functional product, such as whether the vendor is submitting its monthly reports on time. In the case of the aforementioned 911 system upgrade, the Department of Investigation found that City officials “pushed workers to ‘sanitize’ documents in order to make progress and overall health appear better than it actually was,” while failing to notice that subcontractors were overbilling for products and services by 600%. In the case of CityTime, a fraud ring exploited the City’s lack of visibility into project progress and stole $100 million. Three people, including the City’s own project manager, were sentenced to 20 years in prison. This culture of lax oversight needs to be disrupted, and tech culture might be the answer.
For digital products, there is only one thing that matters: Is there working code? Is the team producing an actual, real-life product that users and leaders can put their hands on as it comes together? This question is seldom asked in government IT programs. But it is standard in the tech sector, where digital teams put live demonstrations of their unfinished products in front of audiences on a daily basis. Such demos by PIT Crews will likely catch agency staff off guard, as they are used to a much different type of program oversight. This is a good thing. PIT Crews should not only insist on this type of briefing, they should expose as many agency staff to this behavior as possible. Of all the barriers to public sector innovation I’ve seen, perhaps the biggest is government staff’s lack of exposure to the right way of building technology. They need someone to model this behavior for them, and the PIT Crews could be that model.
The COGE final report concluded, “If the City embraces this moment, technology can help create a government that is faster, more responsive, and easier to navigate.” This is true. Technology is now the engine of almost every government mission, the primary engagement medium for the public it serves. But technology as a tool on its own will never fix government at the scale required. For technology to achieve its potential to transform government, the tools needed are starkly non-technological.
