Data center work does not reward firms that are good at AI. It rewards firms that can move at a schedule the rest of our industry considers unreasonable, and manual document workflows are what break first under that pressure. The firms winning this work are not automating design. They are automating the back office, because that is where the schedule actually fails.

I lead data center work at ECS, so this is the pattern I watch weekly rather than a market thesis I assembled from reports. The constraint on delivery is almost never engineering capability. It is power, land, water, interconnection, and permitting on the owner's side, and on ours, the sheer document throughput required to keep pace with a program that treats a normal design schedule as a starting point for negotiation.

What compressed schedules do to a firm

A conventional project gives you a rhythm. Submittals arrive at a pace one reviewer can absorb. RFIs come in batches you can work through between other obligations. Reports have a review window measured in days.

A data center program removes that rhythm. Multiple buildings proceed in parallel, often on a repeated prototype. Submittal volume arrives in waves rather than a stream. RFIs carry a response expectation measured in hours because a delayed answer stops trades that are already mobilized. Documentation volume per week can exceed what the same team handled in a month on conventional work.

Nothing about that is technically difficult. It is a throughput problem, and firms respond to it in one of two ways. They add people, which is slow, expensive, and constrained by a hiring market that has no slack. Or they change how the documents move.

Firms that do neither do not lose the work dramatically. They deliver the first building acceptably, exhaust their team, and are not invited onto the next program.

Repetition is the property that makes this different

Here is what makes data center work unusually suited to automation, and it is not the technology sector's appetite for it.

These programs repeat. A prototype building constructed eight times across three sites. The same specification sections, the same submittal packages, the same equipment, the same reviewer comments recurring building after building. On conventional work, every project is enough of a one-off that automating the document flow rarely pays back. On a repeated program, the same effort amortizes across every building in the campus.

Concretely, the workflows where I see the clearest return:

  • Submittal review against a known spec. When the specification is fixed across eight buildings, a first-pass comparison is a well-defined, repeatable task. An engineer still adjudicates every finding; what changes is that they open a sorted stack rather than an unsorted one.
  • RFI response drafting from precedent. On a repeated prototype, most RFIs have been asked and answered on an earlier building. A tool that surfaces the prior answer and drafts from it turns a two-hour research task into a fifteen-minute verification.
  • Document control and log reconciliation. Unglamorous, enormous, and pure overhead. Nobody's judgment is required and it consumes a coordinator's entire week.
  • Recurring report narrative. Monitoring reports, observation reports, monthly summaries. Same structure, new data, high frequency.

Note what is absent from that list: design, calculations, anything sealed. The compression does not change the licensure question, and the temptation to let it is the main risk this market creates. That boundary is the subject of how liability works when AI touches sealed work, and schedule pressure is precisely when firms are most inclined to blur it.

The reason this market is the forcing function

Most firms adopt AI because leadership decided to. That produces a pilot with a champion, a modest result, and a slow argument about scaling.

Data center work produces adoption for a different reason: the alternative is visibly failing. When a team is drowning in submittals on building three of eight, the conversation stops being about whether to modernize the workflow and becomes about which workflow to fix first. Necessity produces adoption that enthusiasm never does, and it produces it faster.

There is a second effect worth naming. The owners in this sector are technology companies. They are not skeptical about AI in their supply chain, many of them expect it, and some will ask how you are using it. That is close to unique in our industry, and it means the usual client-perception objection largely disappears here.

What I would tell a firm entering this market

Fix document throughput before you win the second building. The first building is survivable on effort. The program is not. If you wait until you are behind, you will be implementing new workflows during the worst possible week.

Pick the workflow with the highest repetition, not the highest visibility. On a repeated prototype the answer is usually submittals or RFI precedent. The reasoning generalizes: the boring back-office workflows beat design as a first pilot.

Measure it on building one so building two has a baseline. Repeated programs are the best measurement environment our industry offers, because the work genuinely recurs and confounding variables are unusually few. Most firms waste that. Capture hours per submittal and cycle time on the first building and you will have an unusually clean before-and-after, the conditions for a result your partners will accept.

Do not let schedule pressure erode the review step. This is where firms get hurt in this market. The pressure is real, the tools make unverified work look finished, and an RFI answered in ninety minutes with a fabricated code citation is worse than one answered in a day correctly.

The constraint in this market has never been engineering capability. It is throughput, and throughput is a workflow problem.

The durable advantage

Demand in this sector is strong and delivery is constrained by factors mostly outside our control, power availability, interconnection queues, water, entitlement timelines, local execution capacity. None of that is fixed by anything an engineering firm does.

What we control is whether our own documentation keeps pace. A firm that has genuinely solved submittal and RFI throughput on a repeated program carries that capability into every market it serves afterward, because the underlying workflows are the same everywhere. The data center work is what forces you to build it. The capability outlives the program.

If your firm is entering or scaling in this market and the document load is where it hurts, that is a specific and solvable problem. Our workflow automation engagement targets exactly these workflows and reports a measured before and after. Start a conversation.

← Back to insights