Joe Patrois leads the development team at Thomas Cavanagh Construction. His partnership with Palantir reveals what becomes possible when outsider rigor challenges embedded industry assumptions.
About Joe Patrois
Joe leads the development team at Thomas Cavanagh Construction, spearheading an all in strategy to simplify operations and build a fully connected operating system on Palantir Foundry. With over fifteen years of experience across field and project roles, Joe is focused on removing operational complexity and delivering tools that actually work for crews, and in doing so unlocking true operational AI.
“My God, they’ve done it.” Joe Patrois
That was Joe’s reaction watching a Palantir engineer demonstrate their ontology system at a bootcamp. Not excitement about flashy features or impressive dashboards. Recognition that someone had finally solved what construction software is keep trying: connecting data without destroying context along the way.
That recognition sparked a partnership that would challenge every assumption about how construction operations should work.
This isn’t a technology adoption story. It’s about what becomes possible when three principles converge:
1. Outsider rigor exposes embedded assumptions. When someone from defense and intelligence applies their intellectual methods to construction problems, they don’t just bring different tools; they bring different questions. They see precision without accuracy, outputs treated as inputs, administrative burden serving no real purpose.
2. Speed becomes a learning mechanism. Deploy early, sit with users during breaks, fix problems immediately. When field teams test workflows the same day developers complete them, feedback arrives while context remains fresh. Building faster means learning faster.
3. Demonstration breaks belief barriers. You can explain benefits for months. Or you can hit “order truck,” watch it appear, and let everyone in the room go “oh, you mean…” People don’t believe transformation is possible until they see it working.
Each principle alone generates incremental improvement. Combined, they enabled Cavanagh Construction to rebuild their entire operations stack from first principles.
The happenstance that changes everything
The partnership began with serendipity; Palantir’s salesman had gone to high school with Cavanagh’s owner. Joe was walking down the hallway when someone mentioned a boot camp. “Palantir is coming here,” he thought. “Of course I want to join.”
He’d been in project controls, building tools, structuring data and creating Power BI reports. Standard construction technology work. But watching the Palantir forward-deployed engineer demonstrate how the ontology connected data, something clicked.
That recognition sparked a year-long internal campaign to secure a Palantir use case. They started with real-time job costing by connecting their ERP system to their field time capture software. Conventional digital transformation territory.
Then the pattern emerged.
“Every time we did it, we kept finding ourselves going, ‘oh, this would be way easier if we just did it in Foundry,'” Joe explains.
“This would be easier if we did it in Foundry. This would be easier.”
The question shifted from “how do we connect our existing systems?” to “what if we just did it all in Foundry?” What if they built everything the right way, from the ground up: contracts, resources, labour, equipment, materials, trucking. Everything.
They called it the TOM Initiative: Total Operations Management, a nod to founder Thomas Cavanagh. The message was clear: all other software must justify its existence. They were all in on Foundry.
The whiteboard moment: when orthodoxy meets mathematics
As the partnership deepened, the most transformative moments came when Palantir’s outsider perspective collided with construction’s embedded assumptions. Jesse, Palantir’s leading development strategist working with Cavanagh, had a physics background and brought the kind of intellectual rigour that defence and intelligence work demands. During a discussion about how Cavanagh’s job costing worked, Jesse challenged Joe directly with a statement that sounded absurd: “I don’t think job costing matters.”
Joe’s reaction was instinctive: “Wait a minute. No. The costs have to go to the contract item. Of course they do. That’s how we’ve always done it.”
Then Jesse did the math on the whiteboard, demonstrating how their approach was generating “precision with no accuracy.”
You can be incredibly precise about the wrong thing.
The construction industry obsesses over job-costing precision: allocating every cost to the exact contract item and tracking where every dollar goes. A massive administrative burden arises from this requirement. Field teams spend hours entering data to ensure costs land in the right buckets. The precision feels rigorous, scientific and necessary.
But as Jesse demonstrated mathematically, hard-coding assumptions upfront, before work actually happens, destroys the very accuracy that precision was meant to imply.
“By the end of it, I went, you’re totally right.”
Joe recalls. “It doesn’t matter.”
What Jesse meant was simpler than it sounded: you still capture all the data, but you don’t pre-bake it. By “upfront,” he meant the advance configuration and data entry (e.g., cost codes, job-cost allocations, supervisor assignments). In Foundry, you can track changes in real time instead of trying to predict them upfront.
A material order provides the clearest example. Traditional systems require picking the job and the cost code when ordering material. But when it arrives on site, teams often deviate, placing it elsewhere based on actual needs. The front-end precision was a wasted effort. The data was wrong the moment reality diverged from the plan.
With Foundry, dispatch coordinators, fleet managers, and job cost accountants can see changes in real time. When field teams adjust material placement, the information is automatically updated. “They just say, ‘Well, I actually put it here,'” Joe explains. “Now, dispatch knows, the fleet knows, and the job knows. Everyone in this chain understands that the decision has changed.” Dispatch is a workflow/app built in Foundry that coordinates truck assignments, and both the fleet tracking system and job costing records are updated in real time without manual data entry.
This revelation opened a larger pattern. Consider employee supervision: most human resource management systems force you to hard-code who reports to whom. In construction, that’s often inaccurate because workers move between supervisors as project needs shift. “Joe works for Ryan 96% of the time, and the other 4% of the time he works for someone else,” Joe explains. “That’s actually a real representation of who someone works for. Whereas if you hard-coded it on the front, you lose all that information.”
When someone needs Joe’s performance review, they should probably ask both supervisors because neither would have the complete picture.
“We’re treating a lot of outputs as inputs because historically, that was the only way to get it,” Joe explains.
“Whereas now, with Foundry, you get it for free because all that information isn’t destroyed along the way.” When tracking complex, dynamic situations where relationships shift constantly, you can’t hard-code assumptions. You build systems that capture reality as it unfolds.
Changing the mental model: speed as a learning tool
The intellectual breakthroughs from Palantir’s outsider perspective were crucial, but they weren’t enough on their own. Joe and his team still had to win over sceptics inside Cavanagh. The methodology that ultimately worked came from the partnership’s collaborative approach, which injected a more startup way to act that Joe explained in this way:
“If you’re proud of the workshop that you’re putting out, you waited too long to put it out. You’ve got to get it in the user’s hands. It’s got to be ugly, it’s got to be just barely working, because you could sit there for a month and polish something, and day one, they’re going to go ‘that doesn’t work for me.'”
This inverts how construction typically approaches software deployment. Traditional implementations follow a careful staging process: requirements gathering, design reviews, user acceptance testing, and phased rollouts. Each step adds time, and time creates distance between problem and solution. Software companies iterate rapidly and embrace breaking changes; construction has historically resisted both.
Between deployment stages is where education happens. This is where field teams learn that new tools aren’t threats; they’re opportunities to eliminate friction. That weekly iterations will bring changes, and that’s precisely the point. Yes, feedback means revisions. But these minor course corrections prevent the catastrophic failures that come from pursuing perfection in isolation.
Construction’s cultural resistance to releasing imperfect solutions stems from legitimate safety concerns, but that caution doesn’t apply equally to software workflows. Breaking a digital time card system isn’t the same as a structural failure on-site.
Cavanagh took the opposite approach. Project managers created workflow tools for their own teams. When subject matter experts gain direct control over application development, they eliminate the translation layer where requirements typically degrade. “The subject matter expert turned forward deployed engineer is really a dangerous combo, because they understand what they’re trying to build and exactly how to do it.”
They’re not branching, not creating test environments. Hit publish and it goes live.
“It’s actually kind of reset the standard, because we can just do them so damn fast.”
Building faster means learning faster. When a foreman tests a time card workflow the same day developers complete it, feedback arrives while context remains fresh. Problems surface immediately, not three months into deployment when everyone has moved to other priorities.
The permission to break things safely
This speed requires cultural transformation. Breaking things in software isn’t the same as safety failures on-site. The team created explicit permission: expect the first action to produce an error, and we’ll fix it together, right now, while you’re watching.
They practice “sitting in the shit”; developers sit with users during initial deployment, fixing problems immediately. This immediate responsiveness transforms resistance into partnership. Users stop protecting broken legacy processes when they trust that complaints will generate rapid improvements.
“We’re creating a culture where people are becoming more open and honest. My workflow sucks, let’s blow it up!”
Traditional implementations fail when they break because users interpret failure as incompetence. Cavanagh reframes breaks as expected steps in collaborative improvement.
Simplicity scales, complexity fails
Palantir’s intellectual rigour drove simplification that internal teams couldn’t achieve on their own. “They push us out of our comfort zone a lot of times,” Joe notes. “They’re helping break the beliefs that we didn’t even know we had.”
Even when Joe thought he was approaching problems from first principles, finding the lowest common denominator, Palantir would go deeper. “Are you sure that even matters?” they’d ask. “And you have to stop and go, no, you’re right. It can go even simpler.”
Simplicity scales; complexity fails. That became the operating principle.
The resulting applications aim to simplify restaurant reservations. Order a truck: click the button, answer a few dropdown questions, done.
Joe’s analogy is “When someone takes an Uber Ride, the driver doesn’t sit in his car and write down I drove the passenger from here to there. No, The passenger gets out of the car and the invoice is in their email. And that’s exactly how we’re building all these processes. So just by doing the thing you need to do, we get the outputs for Free, we approach every workflow this way”
That’s precisely how they’re building processes.
Every workflow should be simple enough that a grade school kid or someone outside the industry could operate it. This isn’t dumbing down tools; it’s stripping away accumulated complexity. The team designed mobile interfaces for thumb navigation, considering even button placement for field use.
This simplification enables democratisation: “getting the decision maker to do the action.” When ordering a truck requires no specialised knowledge, foremen who need trucks order them directly. No phone calls, no intermediaries where details get lost, no manual entry creating errors.
The goldilocks zone: when conditions align for radical change
Not every organisation can pull this off. Joe recognises they occupy what he calls “the goldilocks zone”: just private enough, just nimble enough, just the right size.
“We feel all the pains of a big organization,” he explains. “But we’re just private enough, just crazy enough, to go all in on something like this.”
Leadership buy-in matters. When executives push the message down, when everyone pulls in the same direction, when there’s organisational commitment to challenging the status quo, transformation accelerates. Teams can’t break things and fix them fast when leadership interprets broken things as failure rather than learning.
Company size matters too. Massive enterprises struggle because coordination costs overwhelm the benefits of speed. Tiny organisations don’t face the integration challenges that make unified platforms valuable. Cavanagh hit the sweet spot: complex enough that workflow integration delivered real value, compact enough that teams could iterate quickly.
But the critical ingredient is openness to external perspective. When a group of committed, nimble people partners with someone from another sector, when they’re willing to have their assumptions challenged, when they value intellectual rigour over industry convention, transformation becomes possible.
What outsiders see that we miss
The Palantir partnership revealed something essential: construction’s challenges aren’t primarily about construction. They’re about constraints internalised so deeply we can’t see them anymore.
Construction assumes job costing must work a certain way because every software works that way. Hard-coded relationships emerge from database limitations. Complexity signals professionalism. Process changes risk project failure.
An outsider with intellectual rigour and different domain expertise doesn’t carry those assumptions. They see precision without accuracy. They recognise outputs being treated as inputs. They question whether the administrative burden serves any real purpose.
They ask “why?” until you run out of answers better than “because that’s how we’ve always done it.”
The whiteboard demonstration didn’t introduce new mathematics to construction. It applied existing rigour to examine whether construction’s conventional approach actually achieved its stated goals. It didn’t.
The development strategist is pushing for simpler, more understandable constructions. He refused to accept that software complexity was necessary to handle operational complexity. It wasn’t.
Show them, don’t tell them: the breakthrough methodology
But intellectual rigour alone doesn’t win transformation battles. When asked what advice he’d give others attempting similar change, Joe’s answer is immediate: “Show them, don’t tell them.”
“You can spend an awful pile of time telling people how awesome something is and explaining all the benefits,” he notes.
They’d talked to people, explained the concept. Nothing landed.
Then came the breakthrough: dispatch built, truck ordering app connected. “I actually hit order truck, it popped up in dispatch, and then they put a driver in the truck and the truck in the order, and then the person saw on their phone. Everybody in the room went ‘oh, you mean…’ We’d said it 100 times, but until you show them.”
People don’t believe transformation is possible because it sounds too good to be true. In an industry where software typically disappoints, where implementations drag on for months or years, the claim that you can build applications in days sounds like marketing hype. “Whether they believe you or not, or if it’s just hard to conceptualise, there’s just something about actually showing it being done that completely changes people’s minds.”
Patterns that transfer
This approach extends beyond the specific Cavanagh-Palantir partnership. Organisations that achieve similar transformations follow recognisable patterns across different platforms, partners, and contexts.
They build minimum demonstrable workflows rather than comprehensive solutions. One small process that works end-to-end, even with dummy data, demonstrates the possibility more effectively than detailed requirements documents. When stakeholders see the truck appear after pressing the button, conceptual resistance collapses.
They deploy early and sit with users during initial use. Rather than handing off workflows and hoping they work, developers stay present for first attempts, expecting breaks and fixing them immediately. Trust builds through demonstrated responsiveness, not initial perfection.
They simplify by questioning every assumption. Each required field, each approval step, each piece of mandatory information gets challenged. The goal isn’t dumbing down tools; it’s stripping away accumulated complexity until workflows achieve grade-school simplicity even when serving sophisticated users.
They practice strategic transparency about imperfection. Users are told upfront that the first action will likely break. When it does, teams fix it together in real time. This reframes failure from shameful to expected to resolved.
They seek external perspectives that expose embedded assumptions. Outsiders from other industries, other contexts, other problem domains see what insiders accept as unchangeable reality. Their questions push past “we’ve always done it this way.”
They move fast because speed enables learning. If you’re proud of what you’re releasing, you’ve likely waited too long. The faster users identify what’s wrong with a working prototype, the quicker teams reach the right solution.
The path forward
Cavanagh is deprecating traditional ERP, dispatch software, and field-time capture in favour of unified Foundry solutions. Real-time equipment and truck telematics create live operational maps. “We call it the Swiss cheese model,” Joe explains. “The more of these data points you start to layer on top of each other, the more you don’t have any holes.”
The results speak for themselves: applications built in days, field workers freed from administrative burden, summer students deploying production systems, and a construction company operating with a tech company’s metabolism.
The three principles don’t just coexist; they form a reinforcing system.
An outsider perspective exposes assumptions that insiders can’t see. But intellectual rigour alone doesn’t win transformation battles. Construction has heard plenty of consultants explain what’s wrong. Explanation creates scepticism, not momentum.
Demonstration breaks through where explanation fails. But a demonstration only works if you can build fast enough to show the possibility before sceptics disengage. Speed enables demonstration. Deploy the minimum working version, sit with users during breaks and fix problems immediately. This rapid iteration does more than accelerate delivery; it creates permission to question more assumptions. When teams see that broken things get fixed in minutes, not months, they stop protecting legacy processes. They start asking, “What else could we rebuild?”
Each cycle compounds. Faster demonstration enables deeper questioning. Deeper questioning reveals more fundamental assumptions. Challenging those assumptions requires faster proof. The metabolism shifts.
This is why the Goldilocks zone matters. The system requires organisational conditions that let it compound: leadership that interprets broken things as learning rather than failure, teams small enough to iterate quickly, and subject matter experts with direct control over development tools.
Construction’s advantage won’t come from finding better software. It comes from creating conditions where these three principles can reinforce each other, where the gap between “what if we tried this?” and “here’s how it works” collapses from months to days.
Sometimes the most valuable expertise is not knowing what’s impossible. The most powerful methodology is demonstrating the possibility before asking for permission.