After nine years in data journalism at the New York Times, I had to admit that I was feeling pretty burned out from the media business. Journalism is where I’ve had some really amazing experiences, but it’s also where I worked myself so hard at times that I had come down with shingles and pneumonia. I wanted to try something different, but it had to be something that served the public.

In 2015, I found out about 18F. And that organization literally changed the entire course of my career.

18F

18F was a novel experiment operating within the federal government: what if we could build technical capacity within the government by offering software development services to other agencies without the need for external contracting? 18F was located within the General Services Administration – whose headquarters are at 18th and F street NW – and entirely funded by one of the GSA’s internal discretionary funds that are normally used to purchase vehicles or buildings. 18F would then otherwise operate like a consulting firm by charging agencies a rate for services that would then be reimbursed back into the fund. This clever approach allowed for 18F to be spun up without the need for explicit appropriations and for GSA to keep it operating even when its costs exceeded its income during the early years when I was there.

Unfortunately, that same flexibility made it easy for DOGE to destroy 18F in a single day years later by eliminating all of its staff in a mass-firing at midnight on a Friday and then deleting the website. This followed a similar evisceration of the US Digital Service, which suffered the additional indignity of being renamed the US DOGE Service. I am not going to document how woefully destructive and inadequate DOGE has been for the task – I have a whole other website for that – but I hope these monsters will be haunted to the end of their days for their actions. And I will encourage you to visit 18f.org, where the spirit of 18F lives on.

When I joined 18F in 2015, it was about a year after its founding, and the enthusiasm was infectious. We had engineers, developers and product managers working remotely from all over the United States and the offices in DC. Our Slack was filled with various goofy jokes and reaction emoji to cheer on each win – I particularly liked the shorthand of 💪🖥️🇺🇸 that we used as shorthand for the field of civic tech; it was hard work, but it was hard work for the American people. Other of my favorite memories of the culture include how typing robot dance party in our Slack would trigger a little line of dancing robots in the chat or the Slack channel named #hi where all we would ever post was the single word “hi.”

18F is also where I first learned how to do agile software delivery. This meant learning how to work in two-week sprints with teammates, how to accurately break down work into tickets and estimate its difficulty, how to use customer research so we could build the product that our customers (and the public) needed. For my first project at 18F, I joined the MyUSA team in progress, which was developing a tool for users to identify themselves and choose what information they wanted to share with government websites instead of having to re-enter their information everywhere. The project was ultimately scuttled, but it was a precursor to login.gov. After that, I helped to build out an online tool for an experiment in how the government might be able to pay for small software tasks without having to issue a complex procurement – a tool allowed contracting officers to create reverse auctions for engineers to bid on small tasks that could cost no more than the $10,000 micro-purchase limit. Once the auction closed, the winning engineer would have to deliver the work and then be reimbursed for their efforts. It was just one of the many fun ways in which 18F was trying to explore new ways to use procurement.

My last project at 18F was a modern revamp of the FBI’s Crime Data Explorer in 2016. Previously, the FBI had released annual reports of crime statistics collected from each state as a series of static HTML tables on a website. With the impending launch of the more advanced NIBRS format for data collection, the FBI wanted to make a more modern site to highlight the new information available for the first time in NIBRS and allow for users to interactively explore the data. 18F built the initial version of the site for the FBI as a project in Python with a database backend that could load the data. I asked to be on this project both because I’d been wanting to work on a data-related product and it was a chance for me to learn Python properly. I particularly enjoyed building out some SQL-driven crosstab analyses with the new NIBRS data and providing pages where developers and data journalists could download the raw database tables if they wanted to explore the data further.

While the first Trump administration was not as overtly hostile to 18F, it wasn’t as supportive of developing technical staff within the US government. At 18F, I noticed that projects began to shift more towards defense and security projects, and that wasn’t an area I was interested in working. And so, I departed 18F in 2018 and joined up at one of the new civic tech consulting companies, Nava PBC. Traditionally, the government has often purchased software either as complete products or had contracted for custom software services from large consulting companies often referred to as “the Beltway bandits,” due to their pricing and licensing practices. Nava’s founders had been among the teams that were brought in to salvage the disastrous launch of healthcare.gov, and they founded the company in 2015 to build software using the same responsive practices for agile software development that were being pioneered in government by public entities like 18F and USDS as well as other small contracting companies within the newly formed Digital Services Coalition.

After 18F, Nava felt very much like home from the start. There was a goofy Slack; teams were made up of developers, designers, product managers and more from across the country; there was the same ambition to reshape how government digital services could work and how we could replace the failure-prone waterfall planning processes that lead so many big IT projects into failure. The only difference now is that I was outside the government again, working on contracts that Nava had competed directly to win against our frenemies and to deliver the specific work we had been engaged for. My first project at Nava was to join a team developing the submissions API used by doctors and registries in Medicare’s Quality Payments Program. This was a new effort to essentially grade the doctors providing services to Medicare so that better doctors would be reimbursed at slightly better rates and this would incentivize all the practices to improve the quality of care. When I joined, there were 8 engineers on the team as well as a project manager, a product manager and a business analyst. Everything was built in Node.js; I didn’t know Node, but I always love the challenge of learning a program language on a new project!

The QPP project honed some of the delivery skills I had picked up at 18F. Nava was one of 14 different scrum teams from multiple contractors working on the QPP ecosystem. Everything was coordinated through the convoluted Scaled Agile Framework for managing multiple teams. After a few months as a senior engineer, I suddenly became the Engineering Lead for the project, when the team’s lead was promoted to the VP of Engineering at Nava. This meant that I was ultimately responsible for planning out the work with my team at one of the quarterly Program Increment sessions held at a ballroom outside of Baltimore. It also meant that I now had to become a people manager for the first time, responsible for performance reviews and career development for the engineers on my team. I absolutely loved it, and I continued to be a people manager over multiple projects at Nava.

After a brief interlude on a project for improving IT operations at the Centers for Medicare and Medicaid (I got to learn Go on the job!), my last project at Nava was to join as the tech lead on the Medicare Payment System Modernization effort to eventually move Medicare payment processing off of the mainframes running COBOL and into the cloud. This was careful, deliberate work – any outage would affect the payment of millions of claims a day and Medicare spending alone accounts for 4% of the US GDP – undertaken by a consortium of CMS employees, USDS staff and small agile companies that would bid on specific projects. Our project was the Replicated Data API, which would for the first time share claims to other parts of CMS within a day of their filing instead of the mandatory 14-day delay required for the accounting system. This work involved translating data from COBOL files into a modern relational schema and then streaming millions of claims in realtime down to clients. I got to learn GRPC and relearn Java (which has improved a lot over the past few decades!) on the project, so that was exciting. And it was also just a test of what we could do with a small team – we only had a product manager, a tech lead, a scrum master working part-time and 3 other engineers. Our API’s data was going to be provided by a pipeline out of the mainframe itself; when that project had to be reworked, we had to adapt and load the data ourselves every day from a collection of COBOL data format files. It was a huge expansion in the scope of work for the team, but we built a solution that has run flawlessly and cheaply every day with only a few months delay from our original timeframe. This work was deeply technical, and all too often we had to grapple with random existential doubts, but I consider it one of the finest projects I’ve ever worked on.

Consumer Financial Protection Bureau

In 2022, I felt like it was time to move on from Nava after several years on the job. After a ludicrously long federal hiring process, I was hired as Supervisory IT Specialist at the Consumer Financial Protection Bureau within the Design & Development team. We used to joke that D&D was bit like Yamaha or Kawasaki – those big conglomerates that make both motorcycles and grand pianos – except our portfolio ranged from video and photography to print materials to the website and other custom internal applications used by other teams at CFPB. As the supervisor of the App Dev team, I was the people manager for 12 engineers working on the front-end and back-end web development on several different teams. There are two things that were exceptionally remarkable about CFPB. The first of these was the mission – I looked forward every day to the daily email that shared news clippings of what CFPB was up to, whether it was introducing new policies or holding bad actors to account. The second was the people, all driven by a patriotic mission to protect the American consumer but also some of the kindest and most thoughtful people I have ever worked with.

The engineers that I managed had been there from the start. Many joined the CFPB in its 2013 and 2015 fellowship classes and stayed on afterwards to continue working for the agency. One of the engineers has been at the CFPB for 13 years, a time before Nava and even 18F existed. CFPB was the first digital services organization in any government, and the team had created and continued to support such fundamental work like the website or the design system over the past decade. I will admit that I didn’t always know what to make of this – I was more used to “greenfield” projects that started from nothing – but in time I really grew to appreciate the different sort of development work that was happening at the agency. It takes very different skills to code systems for longevity. Modern developers like to deride COBOL programs, but how many of us have created systems that span decades of service? Through its continued presence, CFPB was figuring out how to build modern software for the long haul while keeping it stable and accessible for all. I would have stayed with them on this journey until the end of my career if I could, but the Trump administration ruined that plan.

Magnum Opus, LLC

On July 4, the GOP-controlled Congress passed HR.1 also known as the “One Big Beautiful Bill Act,” which contorted the budget reconciliation process to extend tax cuts for billionaires and radically reduce the government to make that happen. CFPB’s union (buy their merch!) had been successfully fighting off the Trump administration’s efforts to unilaterally shutter the agency without Congressional approval, but the new bill included a provision that cut the maximum budget for the CFPB in half, making it almost certain that the government would eventually succeed in forcing layoffs at the agency. I hated to leave and it was a painful job searching process, but there is no way in which I would or should be spared in any future layoffs that might occur. And so, I wound up taking a job at MO Studio, another member of the Digital Services Coalition.

Ironically, my latest work is also linked to HR.1 through its provisions that require every state to implement a system that will validate new work requirements for Medicaid recipients by January 1st, 2026. Past efforts to enforce such requirements have univerally been disasters for Medicaid recipients in their states, with most qualified people losing their benefits either due to poor communication about the new rules and broken systems that make it difficult for beneficiaries to comply. Some observers have noted that requiring validation in every state on an extremely short timeline like this make it seem like Congress is purposefully setting up states to fail their citizens in order to save some money from Medicaid, especially since many states also need to modernize their Medicaid processing systems to better support automated renewals. MO is one of many organizations, both private and public, that is trying to avert failure. I myself will be working on improving Medicaid systems to handle this validation and renewal in Pennsylvania, alongside some old faces from every part of my civic tech career. At 18F, we had the saying “hard work is hard,” when we described a project that necessitated very complicated work to succeed. This is going to be true for dozens of states in the US, and I only hope that all of us can pull it off.