How to make Tech Force work

The Office of Personnel Management recently announced that U.S. Tech Force, starting this September, will place 1,000 fellows annually into federal agencies for one- or two-year terms, supervised by managers hired from the private sector who report to agency heads. If agencies can get them on real projects that ship products and lean into their engineering-focus, this could improve tech efforts in the government. If not, and if this fails to internalize the relevant lessons from previous government digital service efforts, it’ll be the latest round of innovation theater — a waste of money for the agencies and a waste of time for the participants.

I’ve worked at the AI Corps and in other federal technology roles. At the Department of Homeland Security, I was an AI/ML engineer on what was the largest AI team in the federal government, and prior to that, I was a data scientist and Army civilian. While the irony is not lost on me that OPM is engaging in one of the largest tech hiring efforts in federal history coming in the wake of dismantling many of those same teams — mine included — I know the world is full of irony, and I still wish anyone well who takes civil service roles to make government work better.

This administration includes people who have shown significant hostility toward civil servants and no interest in building functional government services. It also includes people who are trying to make things work — as shown in the recent data.opm.gov redesign, which interviewed users like me and was responsive to our requests.

I’m not here to tell anyone they should go work for the federal government right now. But, regardless, things are going to keep getting built. Some of it will be built well and some of it won’t, and the difference will depend partly on whether the people involved — at OPM, at the agencies, and in the Tech Force itself — make specific decisions that set these efforts up for success. That’s what this piece is about. Whether this program reflects a genuine commitment to improving government services or is primarily a branding exercise, a thousand people are going to show up at agencies in September. What happens to them depends on decisions being made right now.

I think meaningful tech expertise is woefully absent in some of the most critical parts of the public sector. And I’ve seen what makes technical efforts succeed and, more often, what makes them fail. The reality is that while many technology initiatives in the past did achieve real results — from Veterans Affairs to online immigration web forms, to brief-but-successful Direct File tax efforts — many were also innovation theater. Instead of accelerating working code and time and cost savings, many of these efforts left the programs they touched with unread reports, wasted hours of interviewed employees’ time without tangible results, and splashy press articles about culture change and the challenge of government — with little change in the actual federal services offered. This was not always their fault, but often they had the wrong organizational incentives and tools that should have enabled success.

The Tech Force also has some unique characteristics and a different focus from other similar tech talent efforts, such as the U.S. Digital Service, 18F, Civic Digital Fellows, and the AI Corps. First, the elephant in the room: There is no way the culture won’t be at least partially influenced by public impressions of the Department of Government Efficiency‘s highly controversial approach to government reform. But there are also more mundane differences: It has a decidedly engineering-heavy focus compared to other tech initiatives that traditionally include other roles like product managers and designers. It places a heavy emphasis on earlier career talent that will not stay for a long time — a two-year term seems to be a strong focus in its advertising materials, whereas even other termed roles in the other digital service teams were rarely less than four years. And it is much larger than other efforts: If Tech Force achieves its goal of 1,000 people, that will dwarf even teams like the U.S. Digital Service that reached a few hundred people at its zenith.

Setting the Tech Force — and its unique characteristics — up for success will require real work beyond just recruiting and hiring people. It may seem obvious that if there’s a deficit of tech talent in government, bringing people on will be useful. But the math isn’t that simple. Now — not when the fellows show up — is the time to figure out what this program is going to be and make sure agencies are prepared on day one. Hopefully they are already doing this but if not, here’s where to start.

Find the projects

The biggest organizational advantage the agencies can provide Tech Force is a clear purpose. What you don’t want to have, especially with a decentralized organization like Tech Force, is lots of engineers with only the mandate to “make things better.”

This is because in large organizations there are significant learning curves before staff can be meaningfully productive. The time it takes to get other staff up to speed — especially when it’s unclear how committed a transient, high-visibility group will be to a given project — gives little incentive for those same career and contract staff to invest in the relationship and knowledge building needed to let Tech Force succeed. In government, the biggest risk is often where people invest their time and who they build relationships with — so make it worth their while.

That means a clear purpose and project: “We are assigned to reducing immigration backlogs.” “We are supposed to improve AI-related cybersecurity defense in Air Force systems.” “We are tasked with improving VA call center wait time.” Something that says who in the bureaucracy needs to care about the Tech Force’s presence and roll out the welcome mat.

The clear purpose can be established two ways: on existing projects or on new ones. For the existing ones, there will be the standard requests to political appointees of projects that need support. However, this is a double-edged sword. Political appointees often have mediocre senses of timing of when to include additional tech staff in a project. Adding Tech Force too late to an existing effort can risk slowing down something that is close to completion. Too early, and there might not be any work to do and you’ll cause territorialism.

Political appointees also pick projects based on what they care about, not what’s feasible. Projects that leadership are most excited about may be the worst fits for Tech Force — big, complex, high-stakes efforts that need full product teams and multi-year timelines, not junior engineers on one- or two-year terms. Someone needs to be able to tell the secretary no. That’s partly on the managers, but it’s also on OPM to vet projects for feasibility before matching begins — not just “does this align with administration goals?” but “can engineers ship something quickly and well given the starting conditions?” Prior to managers being hired, offices requesting Tech Force support won’t know the answer to that question either. OPM needs people who can work with agencies to figure that out.

There are also “new projects.” Timed correctly, plugging in Tech Force is an easier transition. Without an existing bureaucracy working on something, as we’ll discuss later, there’s less territorialism to navigate.

Doing this project scoping could easily be a full-time role at OPM between now and September. Calls need to be put out at the agencies for ideas and the vetting needs to start as soon as possible. Getting at least some of this work done before onboarding is crucial because these are one- and two-year terms. Burning six months figuring out what someone should do eats a significant portion of their entire tenure. Also, the kinds of projects that agencies need done should inform what OPM screens for in hiring.

No matter what Tech Force does now, some of the ideas will turn out to be duds. But to whatever extent it can start to understand what might be in the pipeline, get agencies thinking about how to identify good projects, and inform the existing hiring process, the more OPM can reduce the risk of innovation theater.

Ship and own projects

After project definition, scoping the Tech Force’s role on that project is also important. Unlike many other past federal technology efforts that included other roles like product managers and designers, Tech Force seems focused on engineers.

Even with roles actually well-suited to being less “hands-on,” it’s easy in government to get stuck on projects that are advisory in nature or where you’re only embedding fellows individually into existing contractor teams. That work can sometimes be valuable, but with the engineering focus of Tech Force, unclear or advisory roles can lead the technologists to spend most of their time having opinions about other people’s code instead of writing their own. Whenever possible, Tech Force and its managers should lead the engineering efforts, architectural decisions, and development decisions of the products. When agencies offer spots for Tech Force, as much as possible, that role should be clearly defined in their requests.

Sometimes past technology efforts didn’t take ownership, in part, because they were limited by staffing and were not large enough to ensure successful delivery. But if OPM hits its goal of 1,000 program participants — and given the initial 35,000 expressions of interest, this seems possible — it should be feasible to have real development teams that are primarily made up of Tech Force participants.

Where that has happened in the past, the stories have often been successful: IRS’s Direct File tool that lets people file taxes directly with the government is a great example of this. At its height, dozens of team members from federal digital service organizations worked alongside agency counterparts. It worked because they built something — not a report about what should be built, not an assessment of existing systems, but working software that people used — and staffed it appropriately.

Another example from my own team: DHSChat, the internal generative AI system the AI Corps built at DHS in less than six months. At one point, almost a third of the AI Corps team was dedicated to it. It got built — and scaled — because the team shipped real working software that people used. And, because it was a greenfield project, there were far fewer challenges in integrating into existing agency teams or resolving the inevitable territorialism between federal partners — or the contractors working for them.

Your development environment

Even with a clear project and a clear role, Tech Force will also face another challenge: On day one, they probably won’t be able to actually deploy any software. Without necessary planning, the default computer you receive from your agency will be a brick to your average software engineer. Most government computers, of course, do not let you install any software, access a development environment, or even have resources on where to resolve those issues. And at most agencies, if you want a Mac, good luck — getting hardware that engineers need, like MacBooks for machine-learning work, can take months of procurement battles.

At the AI Corps, our leadership spent nearly nine months trying to get a headquarters deployment environment for model training and GPU cloud infrastructure set up. By the time I left, it still wasn’t operational. I heard later the project was cancelled when the office couldn’t find money to hire a contractor to work as a dedicated information system security officer — something we didn’t know we had to do many months into the project.

There are other infrastructure issues, too. Do you have git servers? What AI coding tools will fellows be allowed to use — the ones engineers actually use, like Claude Code? Or will you tell them Copilot Chat is close enough? The people you want to hire are going to expect industry-standard tools. And if you can improve tooling access for other engineers at the agency while you’re solving this for your own staff, that’s a bonus.

Working through these questions will also help with scoping projects realistically, because what’s realistic depends partly on how you solve the development environment problems.

The managers

The OPM memo says fellows will be supervised by managers hired from the private sector. Who you hire and what you teach them matters.

These managers need to understand how government technology projects work before they start. They should read Recoding America. They should talk to people who led previous digital services efforts and find out what worked and what didn’t. They should understand the basics: how systems get ATOs, how contracting works, what authorities they’ll have and which ones they won’t.

You don’t want managers whose theory of change is “we’re going to hire some good engineers and things will get better.” That’s not a theory of change. Government is full of good engineers who can’t get things done because of where they sit, what access they have, and how decisions get made. If the new managers don’t have a more sophisticated model than “talent solves problems,” they’re going to be frustrated and their teams will be ineffective.

The right managers are curious about why previous efforts succeeded or failed. They want to understand the constraints before they start pushing against them. They’re thinking about organizational dynamics, not just technical problems. And if they aren’t curious about what has or hasn’t worked in the past, they are, as the cliche goes, likely to repeat it.

The headwinds

These fellows aren’t going to work in a vacuum. To be successful, other people at the agencies — civil servants and contractors — are going to have to work with them. This is harder than it sounds.

Embedded teams that don’t report to you and do report to leadership are threatening. Everyone knows this. They’re just as likely to replace you or flag problems up the chain as they are to help. This is even worse in the government, where most technical efforts are not staffed by federal employees, but by contract teams who are usually paid based on how many hours they bill — meaning that they are incentivized to control more work themselves. Even when the contract is not structured like this, they have a strong incentive to ensure they are the primary resource of technical know-how to ensure they remain in the strongest position for future recompetes. They don’t want to be replaced.

Now, there are many great and patriotic federal IT leaders and contractors working on technology projects throughout the government, and I’ve seen their commitment to duty and mission overtake their narrow self-interest many times.

But individual virtue is not enough to overcome the fact that there are few organizational and political incentives to welcome Tech Force among either contractors or other federal civilians. A secretary’s support is helpful, but agency heads are busy, and rarely have the time to help with the thousands of minor roadblocks that teams of smart, junior engineers will face.

This brings us to a decision that is going to make all of this harder than it needed to be. The same administration launching Tech Force largely dismantled the existing network of federal digital service teams — USDS, 18F, parts of the AI Corps, and others — that represented the closest thing the government had to institutional knowledge about how to do what Tech Force is attempting. Those teams made plenty of mistakes, but they also learned, often painfully, what it takes to ship working software in a federal environment. That knowledge didn’t disappear when the teams were disbanded. It lives in the people who did the work, many of whom are now in the private sector and would be reachable if OPM made the effort.

This isn’t just a point about irony, though the irony is hard to miss. It’s a practical recommendation. OPM should be actively consulting with alumni of previous digital service efforts — not to replicate those programs, but to avoid relearning lessons that were expensive the first time around. What development environment problems did they hit? How did they handle the trust issues with career staff? Which agency projects were good fits for termed technologists and which ones weren’t? That knowledge exists. Use it.

And then there’s the trust problem — which is a problem for all the reasons it was always a problem with digital services teams in government, plus some new ones because of what happened to the civil service in 2025, which not coincidentally is why I’m no longer in government.

You don’t have to agree with the narrative that political leadership is hostile to career staff, or that Tech Force fellows might be there to spy for leadership, or that the interest in AI is primarily about eliminating jobs. But these fellows will have to work with people who believe some version of it, if they want to be effective. It’s not going to be possible to fully mitigate this. But there are things you should try.

At the AI Corps, leadership was explicit with staff at partner agencies: Fellows on projects were there to serve that agency’s mission, not report back to headquarters. That framing helped — but only because it was true, and the leadership backed it up.

For Tech Force to work, fellows need a clear mandate that they’re there to help the agency succeed — not to report on civil servants, and not to scout for workforce reductions. If that’s not actually the arrangement, people will see through it and freeze fellows out.

The opportunity

People who’ve done this work before are skeptical of Tech Force, and for good reasons. We’ve seen programs that sounded good on paper produce very little. We’ve seen talented people burn out fighting bureaucratic battles instead of building things. We’ve seen “innovation” get good press coverage and turn into nothing.

But there are better and worse versions of this. A thousand fellows annually, with real projects, working development environments, prepared managers, and a mandate to ship things — that’s a version worth trying. A thousand fellows dropped into agencies that haven’t done the prep work, managed by people who aren’t curious about understanding government, with no clear projects and no path to deployment — that’s a version that wastes everyone’s time and will only serve to prove critics right.

I’ve been asked, in various ways, why I’m writing advice for a program launched by an administration that dismantled the team I was on. The answer is simple: I care more about whether government technology works than about who gets credit or blame for it. And I’d rather be specific about what success requires than add to the chorus of people who are, understandably, skeptical. 

Skepticism is warranted. But a thousand people are going to take these jobs. The agencies they walk into will either be ready or they won’t. That part is still up for grabs.

Abigail Haddad is a former artificial intelligence/machine learning engineer with the Department of Homeland Security’s AI Corps.