When two technology companies announce a partnership, what they've usually shown is that their tools work together in a demonstration. I've been on multiple projects where a tool vendor said its tool could connect to the systems a project keeps its official records in. That connection is called an integration, and it's meant to carry information from one phase to the next. In a sandbox, a test copy of the software with sample information in it, the vendor may well be right. Put those tools on a real project and you've got a different problem, and when the integration fails, it's usually in construction.
Most of the vendors I've worked with, software or hardware, build their products to work with their own other products. Used that way, they can work well. Two of them announcing a partnership doesn't change how either product was built, or how the people using them work.
Why does that matter? For whoever paid for a facility, every month it sits dark, built but not yet running, is money spent and nothing earned. The people living near it may see it very differently. Some of them never wanted it, and they have real questions about what it will do to their bills or their water. A power station, a data centre and a gas terminal each raise different questions, and this piece can't answer them. If a facility was approved on a promise, though, keeping that promise depends on it running.
A real project is a harder test than a sandbox
On a real project, information gets created all the way through the life cycle. It starts in feasibility and planning. More of it comes in design, engineering and procurement, in pre-construction and construction, and in testing, commissioning, handover and operations. The tools have to carry that information from each phase into the next, and you don't see what that takes in a sandbox.
You also don't see how complicated these tools are to deploy. You're putting them into organisations with their own processes and policies, and people who are used to the tools they've already got. Now try getting those people to understand other tools as well, sometimes across several organisations on the same project.
While I was working for a top-tier engineering, procurement and construction company, I had a team that understood the order things go in. First come the standards the information has to meet, then the information itself, organised properly, and only then the tools. Without a team like that, it's very difficult.
When integrations break, it's usually in construction
There's an idea in project work called the influence curve. Early on, making a change isn't that expensive. The further you get through a project, the less you can change and the more each change costs.
Construction comes late on that curve, and it works differently from the phases either side of it. Design and operations are both organised around each piece of equipment. The pump in the design model is the pump the operator looks after. That's the idea behind a digital twin, a live digital copy of the facility. Construction is organised by area. It's about which area gets built when, the quantities put in, how much gets done each day and what's been produced. And a lot of companies are doing it at once, which is part of why it's harder to have partnerships there. All of that is messy, and it's where tools built around single pieces of equipment have to deal with areas. So it's where gaps from earlier phases surface and information gets lost.
Partnerships are rarely in place when a project begins. It might be better if one started in feasibility, while changes are still cheap. I know that's the ideal rather than the norm.
People also still think about handover as one big event at the end of the project. If information were handed over in steps through the phases, that final handover would carry a lot less risk, and a partnership that started early could do exactly that. When an integration breaks, the information created in one phase doesn't reach the next, and that's part of why a finished facility can sit dark.
Some things only happen with everyone in the room
At Bentley Systems I built a practice called Partner Experience. Its aim was to give everyone in an infrastructure project's ecosystem real empathy for what it's like to use and deploy a solution. One way we did that was through innovation days and hackathons, where the whole ecosystem built something together over a day or two. The hackathon at Bentley's London office in June 2025 was one of them. We got stakeholders, developers, the actual users, decision makers and partners together, so each of them could hear what the others needed. Four teams worked side by side, with everyday users sitting next to the interface designers and AI engineers.
You could never do that on a call. Developers usually get requirements, or the user experience team tells them what to do. In that room a user says, "This is how I would use it," and the developer hears it directly. Product managers and engineers from the partner companies were talking to each other too.
What it's like to be the one being tested
This year I've been on the other side. At Vistergy we build software agents that check facility records against published standards, and we joined IBM's and Red Hat's partner programmes. IBM tested the three agents we put on its marketplace, and the server that runs them is now Red Hat Certified.
In a vendor's demonstration, the vendor decides whether it has passed. Here, IBM and Red Hat each had written requirements. They checked our work against them and could have said no.
What happens after the announcement decides whether a partnership works
Two things usually tell me an announced partnership won't reach a working site. The first is when each company's partner team is working to its own targets. I've seen that across multiple organisations, and the people in those teams are doing what they've been asked to do. The second is someone saying, "Yes, we can do that," when the people at the top of both companies haven't agreed to it.
Boston Consulting Group wrote in 2025 that 60% to 70% of alliances fail to achieve their intended outcomes. By alliances it means partnerships like these, where neither company owns a stake in the other. It also said those with strong governance, meaning clear roles and decisions agreed at the top, succeed up to 80% of the time.
Signing a partner and activating one, which means getting them working with real customers, need different skills. Activating takes people who keep going long after the announcement has gone out. It also depends on what both organisations have committed to the people who'll use the tools.
Most of the partnerships I've seen have had a small company and a big one. I've seen fewer with two big ones, and when there were, it was harder to agree who led. When a small one and a big one worked really well together, the big company brought reach, distribution and reputation. The small one moved fast and brought new ideas. That's often what attracted the big one.
One I worked with was a small company partnering with a bigger one. It had good documentation and good application programming interfaces (APIs), the connections other software uses to work with it. It also understood Model Context Protocol (MCP) servers, the newer way of letting AI assistants work with other software. It wanted a good outcome for the customer more than a listing in the bigger company's marketplace. It knew both companies would be serving the same customer in the end.
Companies working together won't settle whether a facility should be built, or whether its neighbours want it. That's for communities and regulators to decide. But once a facility has been approved and built, it ought to start running when promised and do what it was meant to do. That takes partners who care about the customer the way that small company did, and who start early on the real project.
If I were starting a partnership tomorrow, I'd start as narrow as I possibly could, with a named customer and a small first version, as early in the project as I could get. So when you next read one of these announcements, ask which customer it's for, and who at the top of both companies has agreed to it. If each partner team is still working to its own targets, the partnership may never reach a working site.
What comes next
Still Dark returns when an argument demands the page. The podcast carries the rest. Permit to Operate is where the people who live in this gap speak in their own voices.
If you build, operate, invest in, or regulate infrastructure anywhere in the world, this is written for you. Subscribe to Still Dark.
This newsletter lives in the gap between digital delivery complete and permit to operate. That gap is where value dies, and where it can be recovered.
I also co-author The Vistergy Brief at vistergy.com/archive. Satellite and geospatial monitoring, facility lifecycle intelligence, and standards architecture across LNG, nuclear, data centres, utilities and construction. Subscribe to both for the full picture.
The podcast is live. Permit to Operate is available at vistergy.com/pod, Apple Podcasts, and Spotify.
Permit to Operate.
P.S. If you'd like the deeper analysis behind this newsletter, the member tier is £12 ($16, €14) a month.
