The program was a large-scale refresh of servers, storage, and network equipment for a federal agency with roughly 270 overseas posts across dozens of countries. Some of our longtime federal customers may recognize the story. The standard plan would have sent our engineers on a long string of international trips, and every trip meant flights, per diem, country clearance, site access requests, and a maintenance window that had to line up with the post’s local schedule. We built a different plan. Our engineers stayed in the U.S., the people already at each post handled the physical installation, and we ran the technical work remotely. The approach saved the agency millions of dollars in travel and deployment costs, and sites that used to wait weeks for an engineer were finished in days.
Who Actually Has to Be There?
A hardware refresh at an overseas post bundles two kinds of work together. Someone has to unbox the equipment, rack it, cable it, and power it on. Someone else has to configure it, check it against the baseline, fix whatever doesn’t come up cleanly, and sign off that the site is ready. For years those two jobs traveled together on the same plane, mostly because that’s how it had always been done.
They don’t need to. Most posts already have capable IT staff or local support on the ground. What they were missing was the specialized engineering knowledge, and that knowledge moves over a secure connection far more cheaply than it moves in an airplane seat.
How We Made It Work
Splitting the work only pays off if the person at the site can succeed without a senior engineer standing next to them, so we did most of our work up front. Every site received the same standardized deployment package, with the hardware configuration, installation steps, and acceptance criteria settled before anything shipped. We wrote the runbooks for someone who had never touched the equipment before, and we kept revising them as each deployment taught us something. During the install, our engineers connected through the agency’s approved remote access to configure and validate the gear, and walked post staff through problems in real time. Every site had the same escalation path and the same acceptance check before we called it complete.
The runbooks and SOPs outlasted the refresh. They became the starting point for later work with the same agency, including an overseas data storage architecture we designed and deployed under tight security constraints, and engineering and technical refresh work across its global sites. Each of those moved faster because the delivery model had already been proven in the field.
What’s Changed Since Then, and What Hasn’t
A lot of the technology in that story has moved on. Out-of-band management, zero-touch provisioning, cloud management consoles, and centralized monitoring now handle much of what our engineers did by hand over a remote session back then. A configuration that once took an engineer on the line with a post can now be pushed from a central console and verified automatically. AI agents are starting to take on routine configuration and troubleshooting as well.
The lesson underneath it still holds. Every step in a delivery process carries an assumption about who has to do it and where they have to be. On the refresh, the assumption was that the expert had to travel with the hardware. Today it might be that a senior engineer has to write every line of a build or watch every dashboard. Better tools make those assumptions easier to break, but someone still has to notice them first.
We’re applying that same thinking to software delivery now. Our Helios lab is building a delivery framework around AI coding agents. The goal is to let agents handle more of the routine build work so our engineers can spend their time with product owners, designing the features and business capabilities that move the mission forward. It’s the same question we asked about the refresh, pointed at a different kind of work.
Where Operational Efficiency Really Comes From
Agencies are under real pressure right now to cut travel and contractor costs without letting service slip. In our experience, the operational efficiency gains that last come from questioning the assumptions built into how work gets done and putting expertise where it changes the outcome. New tools help most once that groundwork is done. We saw it on a hardware refresh years ago, and we’re seeing it again with AI-assisted delivery today.
If you’re planning a refresh or modernization effort across distributed sites, we’d be glad to walk you through how we approach it.