What Seven Years Inside a Construction Giant Taught Me About Risk, Scale and Survival

Lessons from Balfour Beatty’s Victoria head office — and watching a rival the size of a small country collapse in real time.

Before any of the products, before Bangkok, before any of it, there were seven years spent inside one of the UK’s largest construction and infrastructure groups — Balfour Beatty, at the group head office in Victoria, London. It’s not the chapter that shows up on a product timeline, but it’s arguably where most of the instincts that shaped everything since were actually formed. Software is comparatively forgiving. You can ship, learn, and ship again. Construction doesn’t forgive much of anything, and spending seven years inside a business that lives with that fact leaves a mark.

Where the fascination actually started

None of this began at Balfour Beatty, if I’m honest about it. It began earlier, with my late stepfather, who was an architect — a genuinely renowned one. Among his many projects over a long career, he was lead architect on Westminster tube station, which is the kind of credit that’s easy to say quickly and hard to actually picture: a station used by tens of thousands of people a day, built into one of the most constrained, structurally demanding sites in the country, directly beneath and around a working seat of government. That was just one project among many, but it was the one I understood earliest, because you could stand in it and feel the scale of the problem he’d solved.

Growing up around that meant construction was never abstract to me. It was always a fascination — how things actually got built, what held them up, what happened underground before anything visible appeared above it. Like most children, I think, I wanted to build something of my own. My first instinct, the obvious one, was a castle. I’ve since decided that’s probably the wrong image, though — a castle is a fortress, built primarily to keep people out, and that was never really the impulse. What I actually wanted, even if I couldn’t have named it as a child, was something more alive than that: not a wall around something, but a structure people could move through, gather in, be changed by simply by standing inside it — closer to what a station or a bridge or a public building actually does than what a fortress does. I’m still not sure I have the right word for it, but I know it’s not “castle.”

Years later, a close friend of mine — a senior partner at one of the large architectural practices in London — added the other half of that education I hadn’t realised I was missing. Everything I’d learned at Balfour Beatty was from the delivery side of the industry: the contractor, the risk-taker, the organisation that has to make the design real inside a budget, a timeline, and a supply chain full of people whose incentives don’t always align. My friend gave me the design side of the same conversation — the priorities, the pressures, and the professional culture of the people actually drawing the buildings before anyone breaks ground, and dealing, from the other direction, with exactly the same contractors and delivery teams I’d spent years working alongside. Seeing both halves of that relationship, from inside each of them, is probably the closest thing I have to a complete picture of how the built environment actually gets made — and, as it turns out, a fairly good template for how anything genuinely large and permanent gets made at all.

Eighteen CTOs, and then six

When I joined, the group was still operating as a loose federation of businesses, each with its own operating unit and — this is the detail that tells you everything about the culture at the time — its own CTO. Eighteen of them, across the group, each running their own technology agenda, their own vendor relationships, their own version of what “digital” meant for their corner of the business. It worked, in the sense that nothing had visibly broken yet, but it was an expensive way to run a company: eighteen separate technology strategies inside one balance sheet, eighteen sets of licensing costs, eighteen ways of solving the same problem slightly differently.

Part of what I was there to help do was consolidate that down to six, standing up a proper shared service function underneath it. I worked closely on that with the group CTO and the enterprise architect, and looking back, the three of us did something genuinely good with a hard brief — not because any one of us had a silver bullet, but because we understood, together, what the actual game in construction is. It isn’t really about who pours the most concrete. It’s about the edge: whoever manages risk better, predicts further ahead, and handles the sheer complexity of how these tenders get put together wins access to rewards that are proportionally enormous precisely because so few organisations can carry that complexity well. Anyone who has tried to shrink a federation of empires into a shared service knows this isn’t really a technology project. It’s a political one wearing a technology project’s clothes. Eighteen CTOs don’t hand over their kingdoms because a spreadsheet says it’s more efficient; they hand them over because someone has done the harder work of building the case, building the coalition, and building the shared infrastructure well enough that giving up the old way stops feeling like a loss. That’s a different skill from writing code, and it’s one I don’t think you learn anywhere except by doing it, badly, a few times first.

Being early, on purpose

The digital transformation that came out of that consolidation wasn’t cautious. We were among the first implementers working directly with Oracle as they were still developing Oracle Cloud — not adopting a finished product off a shelf, but sitting close enough to the vendor that our own requirements were shaping what got built. We were early adopters of Office 365, back when “the cloud” was still a genuinely contested idea inside a lot of boardrooms, let alone a construction business built on decades of on-premise habit.

And we invested in what would now sound almost quaint to call AI — good, old-fashioned machine learning, before the term got swallowed by everything that followed it — specifically to build predictive models. Not predictions about which supplier might be late, though there was plenty of that too, but predictions about the shape of the economy itself: modelling the early signals of a recession forming, so the business could start re-engineering itself before the downturn actually arrived rather than after. That distinction — acting on the leading edge of a signal instead of the trailing edge of a headline — is, I’d argue, the single most transferable lesson from that entire period. It’s the same instinct that, years later and in a completely different context, meant building tools before the money to hire people for them ever existed, rather than waiting for permission that was never going to come.

What it actually took to survive Carillion

None of that investment happened in a vacuum, and it’s worth being honest about why it mattered as much as it did. In January 2018, Carillion — at the time the UK’s second-largest construction company, a business with roughly 40,000 employees and contracts running through HS2, hospitals, schools, and prisons — collapsed into compulsory liquidation. It went down owing something in the region of £1.5 billion, with barely £29 million left in the bank, dragging an estimated 30,000 suppliers and subcontractors into financial jeopardy behind it. It remains one of the starkest corporate failures in modern British industrial history, and the post-mortems that followed all converged on broadly the same causes: a complex, acquisition-built structure spanning hundreds of subsidiaries, debt taken on cheaply and never seriously challenged by the board, and — the detail that should chill anyone in the sector — paper-thin margins on enormous public contracts that left no room at all for the cost overruns that construction projects, being construction projects, reliably produce.

That last point is the one worth sitting with, because it isn’t really a story about one badly run company. It’s a story about the economics of the entire industry Carillion happened to be the most exposed example of. Bid on a billion-pound infrastructure contract and the margin you’re actually working with, once you strip away the headline number, is a fraction of a single percentage point. That thin sliver is what the entire enterprise is staked on, and it comes bundled with genuinely enormous risk: currency exposure on international projects, ground conditions nobody fully understood until the diggers were already in, political risk on contracts that outlive the governments that awarded them, and joint venture partners whose incentives don’t always point in quite the same direction as your own. Taking on that risk isn’t optional if you want the contracts at all — it’s the price of admission — but managing it badly, at scale, across a company with hundreds of subsidiaries and no unified view of where the exposure actually sat, is close to what killed Carillion. The industry’s own commentators said as much at the time: Carillion wasn’t a freak occurrence, it was an extreme version of the sector’s default business model, and plenty of other tier-one contractors were exposed to close to the same risks.

Balfour Beatty was one of them, in the sense that the underlying economics of the industry didn’t spare anyone. What made the difference, as I experienced it from inside the technology function, was precisely the kind of investment that looks unglamorous right up until the moment it turns out to be existential: a shared service that could actually see across the group rather than eighteen separate silos each blind to the others’ exposure, and predictive modelling that gave leadership a genuine early warning on macro conditions rather than a rear-view mirror. None of that guarantees survival on its own. But it buys the thing that actually matters in a crisis, which is time to re-engineer before the walls are already coming down, rather than after.

Winning people over, not overruling them

If there’s one skill from that period I’d single out above the technology itself, it’s stakeholder management — properly learned, not the diluted version the phrase usually implies. Eighteen CTOs don’t hand over their kingdoms to a mandate from head office, however well argued the business case is on paper. What actually works is showing people, not telling them: building something real enough that a sceptical stakeholder can see it working before they’re asked to trust it, taking them on the journey from where they are to where the shared service needs to be, rather than announcing the destination and expecting them to find their own way there. Done properly, it doesn’t just secure buy-in. It empowers the people you’re bringing along — they end up with more capability at the end of the process than they had at the start, not less, which is precisely why the ones who mattered most stopped resisting and started building alongside us. That distinction — between winning compliance and actually winning people — turned out to matter far more, in the years since, than any single piece of technology I helped put in place.

Buildings taught me architecture before software did

There’s a habit I picked up in those years that I didn’t fully recognise until much later, working on entirely different systems: I think about software architecture the way a structural engineer thinks about a building, not the way most software careers teach you to. It’s worth saying plainly why that overlap exists at all, because it isn’t a metaphor I’ve forced onto the work after the fact — the word “architecture” itself was borrowed from the built environment by the software industry, decades after construction had already worked out most of the hard lessons the term was meant to carry.

Watching how a genuinely large project actually comes together — the sequencing of a tender, the structural design review, the staged handover from design to build to commissioning — teaches you things about system design that no amount of pure software experience gets you to on its own. Foundations get poured before anyone argues about the finish on the lobby floor, because everything above depends on what’s beneath being sound, and a flaw discovered after the tenth storey is up costs orders of magnitude more to fix than the same flaw caught at the footings. Load-bearing elements get identified early and treated with a different level of scrutiny than partition walls, because not every part of the structure carries the same consequence if it fails. Redundancy and safety margins aren’t optional extras bolted on at the end — they’re specified into the design from the start, sized to the actual risk the structure will face over its working life, not the risk someone hoped it would face. And nothing gets signed off on trust; it gets inspected, at defined gates, by people whose job is specifically to find the problem before the building has to.

Every one of those principles has a direct, almost uncomfortably exact analogue in how I now think about building software systems. Get the data model and the security foundations wrong early, and the cost of that mistake doesn’t stay flat — it compounds with everything built on top of it, the same way a structural defect compounds with every additional floor. Not every service in a system carries equal consequence if it fails, so it doesn’t get equal scrutiny; the load-bearing pieces — the parts an entire platform actually depends on — earn the harder review, the same way a transfer beam earns more engineering attention than a stud wall. Redundancy has to be designed in deliberately, sized to a real assessment of what could go wrong, not added as an afterthought once something has already gone wrong once. And nothing ships on trust alone; it goes through a gate, the same instinct that shaped SILO — a system built specifically to keep watching, inspecting, and verifying autonomous software the same way a clerk of works never stops walking a live construction site.

None of that thinking came from a computer science course. It came from watching how you actually build something enormous, permanent, and unforgiving of shortcuts — and then noticing, years later, that software has exactly the same problem, just with a shorter feedback loop and a much cheaper cost of being wrong the first time. That’s a genuine advantage, incidentally, not a disadvantage: software lets you find out you were wrong about the foundations in weeks rather than years. But only if you were trained to look for the foundations in the first place, and that’s a habit I owe entirely to seven years spent around people whose mistakes were measured in tonnes of concrete rather than lines of code.

Reading the room in a room full of frenemies

The other education, harder to formalise but just as durable, was learning the actual social mechanics of how the industry’s biggest deals get built. A billion-dollar tender for major infrastructure is very rarely one company standing alone. It’s a joint venture, often stitched together from firms that are, on a different contract in a different city, direct competitors bidding against each other for the next piece of work. You build a data room together, share commercially sensitive information you’d never hand a stranger, structure legal agreements that anticipate the partnership fraying before it’s even signed — and then, the moment that tender closes, you’re back to treating the same organisation as a rival on the next one.

Learning to operate comfortably inside that contradiction — being a genuine partner today and a genuine competitor tomorrow, sometimes with the same individuals in the room both times — teaches you something about business that a purely product-and-technology career doesn’t naturally offer. It teaches you to separate the deal from the relationship, and the relationship from the person. It teaches you that data rooms, information governance, and the technology underneath collaborative bidding aren’t administrative footnotes; they’re the actual infrastructure that either enables trust between organisations with misaligned incentives, or fails to, with consequences measured in hundreds of millions of pounds. It’s not a bad primer, as it turns out, for almost anything that came after — including, unexpectedly, a portfolio of AI security and governance products built years later, in a different industry entirely, around the same underlying question: who do you trust, with what, and how do you actually know.

---

A note of thanks

I want to end this properly, rather than let it just trail off into the next chapter, because it deserves that. Thank you, Balfour Beatty, for the experience you gave me. I won’t forget my time there. I worked alongside some genuinely fascinating people, some deeply interesting people, and — occasionally, as it goes in any large organisation worth its salt — some properly challenging ones too, and all three kinds accelerated my growth more than I fully appreciated while it was happening. It was a voyage into the future at the time. It’s my past now. And somehow, looking at everything that’s come from it since, it’s still turning out to be my future as well.

---

Sources and further reading

On Carillion’s collapse and the recession-adjacent risk it exposed across the sector:

• Wikipedia — Carillion: timeline of the collapse, liquidation fallout, and the wider insolvency wave it triggered across UK construction supply chains
• IMD Business School — Carillion: High debt, mismanagement and increased political risk: case study on the debt, complex structure, and thin public-sector margins behind the failure
• Design & Build Review — Construction in the Wake of Carillion’s Collapse: industry reaction in the immediate aftermath, February 2018
• StrategicRISK Global — Carillion collapse: the lessons learnt in supply chain risk: on the ~30,000 suppliers and subcontractors exposed by the collapse
• Raconteur — How Carillion has unmasked the construction industry: on paper-thin margins and risk being pushed down the supply chain as a sector-wide pattern, not a one-off

On Balfour Beatty’s own digital transformation, for context on the direction the group took in the years since:

• Balfour Beatty — Digital-first: the group’s account of its data lake, built from 2018, and its ongoing AI trials
• Balfour Beatty — From the bottom up: Balfour Beatty’s digital transformation: on taking supply chain partners along on the digital journey rather than mandating change from the top
• Construction Digital — Balfour Beatty turn to AWS & Procore on Digital Transformation: on the shift away from paper-based site processes
• Construction Digital — Balfour Beatty Bolsters Digital and Procurement Leadership: on more recent CIO and CPO appointments continuing that direction