Audio article narrated by OpenAI
This article is the second in the column called Change Order.
This operates as a separate monthly column on Last Week in ConTech, which readers can opt in to receive here.
This conversation is with Santino Medina.
About Santino Medina
Santino Medina is a Technical Program Manager at Google, working on data centre construction innovation, digital manufacturing and process optimisation. He attained his Master’s at SCI-Arc after undergraduate study at UTSA, which later gave him its inaugural Distinguished Alumni Meritorious Global Influence Award, and spent a decade at Gehry Technologies on museums, hospitals, airports and theme parks, including 4 years in Shanghai as Overall Parkwide BIM Manager for Shanghai Disney Resort, leading the firm’s local Chinese team. He then moved into general contracting, with Mortenson on Chase Centre in San Francisco and Climate Pledge Arena in Seattle, where Google recruited him to bring the same digital-to-physical skill set to hyperscale infrastructure. The opinions stated here are Santino’s and not those of Google.
—
Those with the least resources often need technology the most.
Santino Medina
—
He was referring to his cousin, a painting contractor. The constraint in construction is no longer technology capability. Rather, it’s the person who can stand between the model and the concrete, with the leadership buy-in to act on what they find there.
The habit of getting in the way
Santino spent ten years at Gehry Technologies, living on the construction sites. What made his team special was that they treated buildings as a system rather than a stack of trades: not just the structure but the MEP and how that meets the facade.
That systems view led to clashes:
“They would have designed something and they quite did not design it. It’s just a piece of geometry in the model. Now that can go straight to the steel vendor, and that vendor is gonna build whatever they want, because that’s what they’re contracted to. But if you want the design intent, I kind of got in the way.”
I kind of got in the way defines Santino’s career. He’d step into the gap between what had been designed and what could actually be built. A model or drawing might describe the geometry but doesn’t have the detail for constructability or account for how the structure and trades will come together on site.
As the model moves from the architect and engineer to the contractor and fabricators, the gap becomes a problem. The missing piece is constructability, ensuring the design intent is captured and translated into something that can actually be coordinated, fabricated and built.
The skill proved valuable when he moved to a general contractor role on the Chase Centre in San Francisco, which had five cranes and 1,500 people a day. At this scale, the model is used less as documentation and more as a rolling forecast of the weeks. Then he moved to Seattle and the Climate Pledge Arena, and while he was working on the stadium, Google called. What drew him was less the data centres than the problem underneath them, how to build something correctly:
“This is an industry problem. This is not a Google problem.”
Seen as a whole, his career moves steadily toward the point where decisions are made. As a designer, he could draw it. At Gehry Technologies, he could advise. At the contractor, he could intercept geometry before fabrication. Now, on the owner’s side, he can change the brief itself.
The closer he got to the decision, the more of the system he could change.
Construction doesn’t really have a name for this role. When we discussed what came closest, the best analogy was the forward-deployed engineer: the software specialist embedded inside a customer’s operation, working directly with the people using the technology to figure out what needs to change.
Santino did this in Mexico City, as part of what he calls “a small team of specialists”: several people, including one on the facade, Santino on MEP and another on structure. Each lived on site with the model, using it as the language between teams.
“I don’t speak a lot of Spanish, Arabic, or Mandarin. As long as I had my model and I could sketch, that’s all I needed.”
Monumental runs the same model on bricklaying robots.
Each project site is too variable to be specific in advance, so they send people to find the process, helping them to meet corners, curved walls and scaffolds no one has programmed for. Field iteration isn’t a support function that follows an R&D loop; it is the R&D loop.
As Santino thought about his work, his role comes down to two disciplines. The first is being software-agnostic by design:
“I don’t care what the tool is. What is the problem, the opportunity that you have that I need to solve?”
That agnosticism buys him a bluntness with vendors. When a promised capability doesn’t materialise, his position is that the schedule doesn’t wait for it:
“we’re not gonna stop building because your software doesn’t work. We have to keep moving. So once you fix it, then maybe we’ll come back.”
The second is being able to constantly switch contexts and understand stakeholders’ needs.
“When you go down there to the general contractor, that superintendent only cares about his one zone. Whereas I care about all zones.”
As a leader, he needs to understand his people’s goals and coordinate across them. He needs to be credible in both registers, able to sit with the mechanical, electrical and structural teams, ask what they don’t understand and turn their answers into an orchestrated sequence.
The hard part of his role is understanding what the system needs to do, not just what each individual part needs to do. Most people don’t think about how they could do their own job differently, or how it interacts with everything around it. That focus is useful. It allows them to execute their part of the work.
But someone has to sit outside those individual functions and see how they connect.
That’s the role Santino has spent his career moving toward: someone close enough to the work to understand what is actually happening, but far enough outside any one function to see what could be done differently.
Construction already pays for versions of this role. Andriy Mulyar has described the economics from inside AEC AI: in the parts of the market that only buy professional services contracts, a $2 million deal is $100,000 to $200,000 of software and $1.8 million of engineers implementing it inside the customer’s operation. The industry is already paying for people to bridge the gap. It just doesn’t treat that bridge as the product.
Ultimately, we need people embedded close enough to the physical work to identify how the system can change, yet independent enough from individual functions to make those changes.
Finding and training those people is the challenge.
Baseline before you optimise
I’d been reading The Algorithm, Jon McNeill’s account of how Tesla works, where automation is deliberately the last of five steps, after questioning the requirement, deleting what you can, simplifying and speeding up. Construction tends to jump straight to the fifth. I asked Santino why:
“A lot of people don’t have processes. They might say they have a process, but they really don’t. Because if they did, they would be more successful.”
So his team maps what they build end to end, including the steps, the length, the number of people, the company owner and where the handoff sits.
Once mapped, a full project can have almost 50 handoffs, and the gap between one company finishing and the next starting can cause schedule slip. Without mapping the process, we don’t see the sequence. And without the sequence, nobody asks, in his words, “Have you ever questioned why it takes two days?”
“We should be able to say it takes seven days to do this one thing, go around to all the general contractors, and make sure that it’s happening in seven days. And if someone says, well, we’re doing this in eight days, but we’ve got a baseline. Is it people? Is it supply chain? Why are you doing it in eight days? But then we can go and find that one GC, “Hey, we’re doing it in six days. We’re doing it just as safe. Okay, so then what are you doing? And now my new baseline is six days.”
Standard work is the precondition for optimisation, because you cannot improve a process you have never defined. The 50 handoffs aren’t an execution failure blamed on individual trades; they are the structure.
These handoffs won’t smooth out on their own. A schedule only shows the technical sequence of the work, which is how the owner and the construction manager read it. Every service provider reads it through their lens. For a specialty contractor, the project is one event in their portfolio, and their priorities are shaped by their own crew, scope, schedule and other commitments.
These two viewpoints affect what each party considers important and where they focus their attention.
Mapping the process end to end, with the steps, durations, companies and handoffs, creates a shared view of how the work actually moves. It makes the dependencies visible, allowing the team to identify failure points and optimise the system rather than individual parts of it.
But you can’t create that map from a desk. Being forward deployed lets you discover how the work actually happens, which you can’t do from a desk.
Year one, thirty times over
Firms often say they have established processes. But in reality, they have rigidity:
“People say, we’ve been doing this for twenty years. In reality, you haven’t. You’ve been doing it for one year, and you’ve done it 30 times over. You figured out one way to do it, and you went with it. And that doesn’t mean that first year that you figured it out works. It worked for you.”
Experience without a feedback loop is repetition and in construction the incentives push this way. Changing anything creates a chance of cascading failure, so while leadership talks about innovation, on the ground it’s about reducing risk. It’s why innovation teams work within the current delivery system and why failure stays taboo in an industry where failure is statistically the norm.
The people who need it most have the least
Santino’s cousin is a painting contractor who asked for help pulling quantities off 2D drawings. Medina set him up with an AI subscription that reads the drawings and returns quantities by paint level.
“He’s like, I would put out two bids a week. Now I can put out 10 plus bids a week.”
If his cousin didn’t know this existed, he’d still be working only two bids. The constraint was never coding; it was awareness.
But that alone isn’t enough.
Someone needs to understand his workflow, recognise where the technology could help, and train them to use it.
“We worked with Dusty Robotics back in the day, and we would take the robot to site and it would layout stuff. And people are like, oh man, this is crazy, let me get a picture with it. And I was like, yeah, that’s cool, but I want it to be like a drill.”
As people understand new technology, they start to ask for it like they do another tool: get the robot over there. It isn’t novel anymore; it’s just part of the work. When I asked if AI will take an architect’s job:
“No. But a person like me who can manipulate AI, I will take five jobs.”
The asymmetry, stated plainly
Santino is clear about why he’s at Google:
“I can’t work at a small architecture firm and do there what I’m doing here. I need to work at Google so that I can solve those problems in this industry with an innovative global company.”
What that position really buys is room to take risks. In our industry, risk aversion takes three forms:
- Culture: the fear of sticking out
- Economics: at margins of around 6%, a failed pilot costs too much
- Liability: every party pushes risk down the chain
Google’s position eases all three. When innovation can absorb a failed pilot, sticking out is less risky.
Ownership also changes who is responsible for optimising. Santino still walks onto job sites running four cranes where two would do, or twenty diesel forklifts where ten would be enough. That costs money and adds carbon.
It isn’t about bad intent. Contractors run their own schedules, the cost isn’t theirs to carry, and re-planning the equipment takes a skill set most of them don’t have. That’s the gap Santino steps into:
“As an owner now, I can be responsible enough and be like, let’s take a look at your construction plan, collaborate, and reduce the schedule. And we’re still safe.”
The bigger value of being at Google is the ability to experiment. When Santino calls a 3D concrete printing company, the first reaction is surprise: why is Google calling? Then he does a digital mockup with them to test it. At large scale, it doesn’t work. For smaller projects, it works well.
Solve modular assembly for one typology, and he can push it into others, like affordable housing. Most firms can’t match Google’s innovation. They can use what it learns.
Stop building, start assembling
Two conditions now make modular viable:
- Standardised demand. Modular and 3D printing startups offered a standard product while the market wanted customisation. Hyperscalers order the same building, repeatedly.
- Efficiency targets. Owners are now pushing them into their contracts, keeping the scope while cutting costs.
My last question to Santino had two parts: what will change in the next five years, and what will stay the same?
The first part: digital twins will run end to end, as the projects inside Google are scattered across the lifecycle. The shift he states:
“Right now, we build our data centres. At a certain point, I want us to assemble them.”
The building/fabricating partner he’s looking for has a growth mindset. It’s about shared exposure, not capability:
“we’re gonna fail too. It’s not like, oh sorry, that’s all your fault. No, it’s both ours. We both have skin in the game.”
Many contractors decline on the grounds of risk and that refers to the second part of the condition. Much of the industry will stay the same in the next 5 years; that’s why he is selective about who he onboards.
What that partnership needs is alignment: people willing to carry risk and leadership close enough to the work to authorise a deviation when the crew finds one. You can’t hold a team accountable for a problem you don’t understand yourself, which is why the person at the top has to grasp the detail.
“Just because we want to build faster doesn’t mean we can build faster. We still need to engage with the city. How are you gonna submit these drawings to the city the same way you’ve been doing it for fifty years? Here’s a thousand pages of a PDF.”
The idea is to start talking to the city, learning what permitting offices would want in a model, how it should be broken down and whether a viewer showing everything colour-coded to materials would let them read a submission faster. Both sides want the permit to move, but nobody has built the interface between them.
The seat that can absorb the first failure
Firms without a defined process have no baseline. Without a baseline, there is nothing to optimise. Technology lands on undefined work and underperforms. That reinforces lower margins and risk aversion, which makes the next technology investment harder to justify.
That is how you stay in year one thirty projects later.
What breaks the loop is the person who stands at the handoff: model in hand, credible to the superintendent and the vendor, writing the sequence down before anyone tries to automate it. And what makes them rare isn’t technical expertise alone; it’s fluency across the industry’s different languages: a model, a schedule, a fabrication drawing and a crew.
The industry has to stop treating this person as a personality who appears by accident and start treating them as a role: naming it, staffing it and funding it.
That is how you turn field learning into organisational learning, and make every cycle an opportunity to change the system.