What construction taught me about shipping software

I spent eighteen years running construction and infrastructure projects across Southern Africa and the UK before I wrote a line of production code. I now work as a full-stack engineer, and over the last five years I've noticed something quietly interesting: the habits that made me useful on a building site are the same habits that make me useful on a software team. Not the obvious ones - not the stakeholder management or the spreadsheet fluency - but the deeper ones, the ones that sit underneath the work and shape how I think about delivery itself.

I didn't expect this. When I made the career switch I assumed the eighteen years were largely behind me - a background, a story to tell at interviews, not something I'd lean on day to day. That turned out to be wrong. The technical layer is genuinely new. The substrate underneath it isn't. I find myself reaching, again and again, for mental models I picked up on building sites in my twenties.

This post is an attempt to write some of those down. It's not a complaint about software - I love the industry I work in, and I'm not in a position to lecture anyone who's been here longer than I have. It's an honest account of what transferred, and why I think the transfer is worth more than I gave it credit for.

On a building site, you cannot pour concrete before the steel is in. You cannot install the windows before the frame is up. You cannot commission the lifts before the shaft is built. The sequence is not a preference. It is the work.

This is obvious on a site because the constraint is physical. If you get the sequence wrong, the next trade arrives and cannot start, and you are paying them anyway. Everyone on site can see it. Everyone on site has an opinion. The cost of bad sequencing is loud.

Software has the same constraint, but it is quiet. You cannot build the feature before the data model supports it. You cannot ship the integration before the auth flow is solid. You cannot migrate the database before the backfill is verified. The sequence is real - the cost of getting it wrong shows up later, in a half-broken release, or a rollback, or a feature that technically shipped but doesn't work for the customer who actually needs it.

Because the cost is quiet, it's easy to underrate. Tickets get pulled in because they look ready, not because the upstream work is actually done. PRs get merged because they pass review, not because the system around them is in a state to receive them. The team moves, things ship, the burndown chart goes down, and somewhere downstream the bill arrives.

What construction taught me, viscerally, is to listen for the quiet version of the constraint. When I'm picking up a ticket, the first question I ask myself is whether the thing it depends on is actually done - not in JIRA, not in the PR description, but in the system. That habit isn't smarter than the people around me. It's just borrowed from an industry where the question got asked out loud, every day, until it became automatic.

On a mid-sized construction project you are managing dozens of contractors at once. The main contractor. The subcontractors. The suppliers. The consultants. The client. The local authority. Each one has its own scope, its own timeline, its own incentives, its own definition of done. None of them care about the project as a whole. That is your job.

The work of project management - the actual work, not the Gantt charts - is holding all of those interfaces in your head at the same time and noticing where they are about to collide. The steelwork is running two weeks late, which means the cladding contractor is going to arrive to an unprepared frame, which means they will charge a standby fee, which means the client's budget contingency is about to be eaten, which means the conversation with the client next Tuesday is going to be harder than it needs to be. You see the collision coming six weeks out. You either intervene or you pay for it.

Software has a similar shape. Every system depends on other systems. Every team depends on other teams. Every release depends on data flows, third-party APIs, security reviews, infra capacity, design sign-off, legal sign-off. The interfaces are everywhere. The good engineers I've worked with hold a surprising number of them in their heads at once - they're the ones who spot the collision early, mention it in standup, and quietly route around it before it becomes anyone's emergency.

That noticing-things-six-weeks-out instinct is the single most valuable thing I brought across. It isn't a project management skill in the formal sense. It's more like a peripheral vision for delivery. You don't always intervene. Sometimes you just flag it and trust someone else to take it from there. But you don't miss the collision, because you've spent years training yourself not to.

That's the habit I most consciously try to bring to engineering work - and it's the one I think most travels across the boundary between the two careers.

I hold IOSH Technical Membership. That means I spent a meaningful part of my construction career thinking about safety - not as a poster on the wall, but as a daily practice. The thing about real safety culture is that it is boring. It is the same conversations, the same checks, the same toolbox talks, every week, for years. It is not heroic. It is the opposite of heroic. It is the quiet discipline of doing the unglamorous thing before anyone has been hurt.

The closest software parallel I've found is incident response, and specifically the way the best teams treat near-misses.

In construction, the question is not whether something will go wrong - it is when, and how prepared the team is when it does. Near-misses are reported. Root causes are investigated. Lessons are written down and read by people who weren't there. The culture treats near-misses as gifts, because they are warnings without the cost.

The software teams I most admire have the same instinct. They treat the deploy that nearly broke production as more interesting than the one that succeeded. They treat the alert that fired at 3am and resolved itself as a signal worth understanding, not noise to be muted. They treat the rollback as the artefact, not the embarrassment. That posture isn't universal in the industry, but the teams that have it are visibly better at not breaking, and the teams that don't tend to break in similar ways more than once.

Where I think the construction muscle helps is in the small habit of noticing the near-miss in the first place. When a deploy nearly broke something, I want to know why. When an alert fired and resolved itself, I want to know what would have happened if it hadn't. When a migration was rolled back, I want the rollback itself to be the thing we learn from, not just the successful retry. That's not heroism. It's the boring practice. It's what safety culture looks like, transferred sideways - and it costs almost nothing, which is part of why it's worth doing.

Every construction project has a plan. Every construction project has a moment, usually about a third of the way in, when the plan meets reality and reality wins. The ground conditions are not what the survey said. The supplier has gone into administration. The client has changed their mind about the lobby finish, again. The plan is now wrong, and the question is who owns the gap between the plan and what is actually going to happen.

The answer, in construction, is that the project manager owns it. Not the contractor. Not the schedule. Not the client. The person on the ground, holding the radio, deciding what happens next. The plan is a tool. The outcome is the job.

Software teams talk about ownership constantly, and most of the time we mean something slightly narrower than this. Owning a service. Owning a domain. Owning a metric. Those are all fine, and they're how modern engineering organisations have to work. But there's a second flavour of ownership that sits alongside them - the kind that kicks in when the plan breaks, when the architecture turns out wrong, when the requirements shift, when the customer reveals what they actually wanted. Someone has to absorb that and produce a next step the team can execute. The teams I've enjoyed working on most are the ones where that ownership is shared - where it doesn't matter whose ticket it is, somebody just picks it up.

I think about this when I look at how teams handle ambiguity. The engineers I most want to work like treat ambiguity as the work, not as an obstacle to the work. They don't wait for the requirements to firm up. They don't insist the ticket be fully specified before they touch it. They go and find the answer, often by talking to the person who actually has it, and they come back with a version of the next step that the team can act on. That posture isn't a construction PM trick - plenty of software engineers arrive at it on their own - but it's a posture I recognise, because it was the daily reality of the job I had before this one.

The plan is rarely the deliverable. The outcome is. Holding that in mind, gently, is one of the most useful things I brought across.

Three things, beyond the specific lessons.

One: the skills that transferred from construction were not the ones I expected. I expected to bring stakeholder management and the ability to read a room - and I did, and those things help. But the deeper transfer was about how to think about delivery itself: sequence is real, interfaces are work, near-misses are gifts, the plan is rarely the deliverable. Those are mental models, not soft skills. They sit underneath the code, and they help me show up better than I otherwise would.

Two: I came in as the junior in the room, and I still mostly am. The engineers around me have spent careers building intuitions I'm still developing. The point of this post isn't that my old industry has answers software doesn't - it's that two delivery-heavy industries, looked at side by side, share more shape than either tends to notice, and the overlap is a quietly useful place to think from.

Three: the career pivot was not a reset. I sometimes hear second-career engineers described as having started over, as if the first eighteen years got binned. They didn't. They are the substrate. The code is the new layer. The eighteen years are still doing work underneath it, every day, mostly invisibly, in the choices I make about sequence, ownership, and what counts as a near-miss worth listening to.

If there's a single habit I'd recommend to anyone reading - whether or not they ever spent time on a building site - it's the near-miss one. The next time something nearly broke and didn't, sit with it for ten minutes. Ask what it was warning you about. That one practice, more than any process you can install, is the thing I most consistently see separating teams that ship cleanly from teams that don't.