Nobody Orders a Substation the Week the Tenant Walks In.

On September 22, I sat down to dinner at Claud in Manhattan with a table of New York technology leaders. David Fischer of Engineer Access built the room, and Bob Matsuoka led the conversation on how engineering leadership changes as AI takes on more of the work. David's recap lists what we covered: token costs, deterministic checks, how junior engineers learn, open-weight risk, and power. We settled none of it. Everyone at that table was open to having their mind changed, and for four and a half hours we tested each other's thinking.

Power was one of the threads I carried home, and it opens a series of articles I am writing from that dinner this week. It came from Jay Bedovoy, CTO of DataVerge, who sat directly across from me. DataVerge has run a colocation data center at Brooklyn's Industry City since 2006, with more than forty carriers and network providers coming into it and a 50-megawatt substation on the campus. For most of those years, demand across his industry grew in a shape everyone knew how to plan against.

Jay walked us through how AI is changing that shape. Training could run in Texas or anywhere else power was cheap, but inference has to sit close to the people using it, because latency and distance matter. That puts a premium on exactly what his building offers: power on the campus and carriers in the building, next to the users.

The dinner broke up around half past ten. I headed for the subway to make my train home to Milford, and the doors on my subway car would not close properly. By the time I reached Grand Central, my train was gone and the next one was almost an hour out. I sat down and took out the yellow legal pad. I am usually in bed by ten; I was physically exhausted and mentally drained, and I was wide awake anyway, because the ideas were arriving faster than I could write them down.

The first pages were about the people at that table: their backgrounds, their ideas, and the insights each of them brought. Then the power shift Jay described. Then a curve I have been drawing for years, because that shape is one most technology leaders face inside their own companies. When the train came, I took my usual seat, second car from the front, facing forward, and kept writing. I walked into my house in Milford at half past one in the morning.

The advice we follow on the way from startup to enterprise sounds responsible. Build for the stage you are in. Do not scale ahead of demand. Install enterprise practices when an enterprise customer requires them: the first security questionnaire, the first SOC 2 request, the first SLA with penalties attached. Almost every technical leader who has moved a company from startup energy toward enterprise has lived the week that first questionnaire arrived and the team learned what it did not have.

Physical infrastructure shows why that advice fails. Engineers plot a structure's behavior on a load-deflection curve. A structure absorbs load predictably up to a point, and then its response changes character: the same added load that once produced a millimeter of deflection starts producing a hand's width. The Load Curve™ is that shape applied to a company's need for CTO-level structural decisions as it grows.

Across his industry, the load did two things at once: it bent, and it moved. Decades of demand history said little about workloads that have to sit next to their users, and power and connectivity cannot be added on the timeline those workloads arrive. The transformers a substation runs on now take two to three years or longer to deliver, so a substation cannot be ordered the week a tenant walks in.

I walked into the same shape in software. When I took over the API product at my current organization, the architecture was overbuilt: Kubernetes, with most of its capacity underused. The business wanted enterprise-class customers, and we were talking to them and struggling to close them. What they asked, every time, was what happens when a region goes down, and the honest answer was two days.

Statics treats every force as having a size and a direction. A member sized for load along one axis carries only a fraction of its rating when the same load arrives from another direction. The version for a seat is what I named Design Aim: the outcome a seat was built to move, as distinct from the specialty it exercises to move it. Our platform was sized for scale we did not have, aimed at a load nobody was bringing us.

On the business side, that gap reads as a long sales cycle. Deals with the customers the business most wants stall in review, and when one finally closes, the lead time on failover, audit trails, and change control is longer than the weeks between signature and go-live. The engineers you most need on the product are pulled off it to answer security questionnaires and build the missing controls against a deadline. The opposite mistake is just as structural. Build for a customer the business will not land, and the company carries cost it cannot pay for.

The leaders who get this right do not have bigger budgets. They stopped judging technology spend by its size and started judging it by its direction.

So I re-aimed. We moved off a Kubernetes footprint built for peak to an architecture that scales with demand, and the money that came back paid for active-active in Azure, East and West, with automatic failover. Recovery from a regional disaster went from two days to an automatic failover; losing a single region no longer takes us down. I also reorganized the team under a tech lead for each system, the precursor to the management layer I put in as we grew. All of it was in place before the business needed it, and none of it raised our costs.

Structural engineers build ahead of a load on purpose. A cambered beam is manufactured with a deliberate upward curve, sized so that when the permanent weight of the floor it carries settles onto it, it comes down close to level. Before it is loaded, it looks like a mistake. I call the technology version Camber Architecture™: build one band ahead of where the company sits, aimed at the class of customer the business intends to win, sized to the goals you judge will land rather than the ones on the stretch slide, which makes the technology seat a business seat. Every line of infrastructure spend should be able to name the class of customer it is aimed at, and the line that names no class of customer is the budget for the one you are trying to win.

Pull two documents this week: your last infrastructure bill, and the last deal your business lost or stalled with the class of customer it is trying to win. Next to each major line on the bill, write the class of customer it serves. Next to the deal, write the question it stalled on. Then find the line on the bill that answers that question. If there is none, you have found your re-aim, and the first place to look for the money.

The Structural CTO works Camber Architecture™ in full: how to read which band your company is headed for and build to it without spending today's team or today's runway to get there. It ships November 2 and is open for pre-order now: http://TheStructuralCTOBook.com