← Back to Insights

Load Paths: The Concept That Separates Engineers From Software Operators

There's a line that runs through structural engineering, and it has nothing to do with which software you know. On one side are people who can drive an analysis package. On the other are people who understand how a structure carries load. The two overlap less than you'd hope, and the thing that separates them is the load path.

A load path is the route every force takes from the point it's applied to the point it reaches the ground. Gravity load from a slab into beams, beams into columns, columns into footings, footings into soil. Lateral load from a façade into a diaphragm, diaphragm into walls or frames, down to foundations. It sounds basic. Tracing it correctly, every time, for a real building, is the most valuable habit an engineer can have — and it's the one most quietly skipped.

Gravity and lateral load paths through a building section, from slab to foundation

The model doesn't understand the building

A finite element model solves equations. It does not understand the structure, and it will happily give you a beautifully converged, completely wrong answer if the load path you built into it doesn't match the building you intend to construct.

The model will distribute force along whatever stiffness you gave it. If you released a connection you shouldn't have, the force reroutes silently. If a wall is modelled with no in-plane stiffness, the load finds another way down and you never see the path you assumed. If a transfer element isn't there, the forces above it land somewhere you didn't plan. None of these throw an error. The analysis runs, the contours look plausible, and the load path in the model is not the load path you have in your head — if you even have one.

This is why "the software said so" is not an engineering justification. The software said what the model told it to say. Whether the model represents a real, buildable load path is a judgement only the engineer can make.

You should be able to sketch it in five minutes

The test is simple. For any structure you're working on, you should be able to take a blank sheet and trace, by hand, how load gets from the top to the ground — both gravity and lateral, in both directions. Where does the force enter? What carries it? Where does it transfer? What resists the overturning? Where are the discontinuities — transfers, setbacks, podiums — that break the obvious path?

If you can't sketch that in five minutes, the model won't rescue you. It will just hide the gap. The sketch is the single highest-leverage thing you can do before building anything, because it forces the decisions the model assumes you've already made. Most of the rework that shows up in review traces back to a load path nobody drew.

This is also the fastest way to find an error in someone else's model. You don't re-run their analysis — you sketch what the load path should be, then check whether the model agrees. Where they diverge is where the problem is.

Continuity is the whole game

A load path only works if it's continuous. Force has to have somewhere to go at every step, all the way down. The classic failures are discontinuities:

  • A column that lands on a beam instead of a column below — a transfer that has to be deliberate, not accidental
  • A wall that stops at a level with nothing to pick up its load
  • A diaphragm with an opening so large the in-plane force can't get around it
  • A lateral element that resists load on its way down but has no foundation detailed to receive it

Every one of these is a break in the path. The structure doesn't care how good your member design is if the force can't get to the member. Continuity first, capacity second.

What this means in practice

The skill isn't knowing the software. The software is the easy part, and it's getting easier every year. The skill is holding a correct mental model of how the building carries load, sketching it before you model, and using it to interrogate whatever the analysis hands back.

Engineers who have this catch problems at concept stage on a napkin. Engineers who don't catch them at DD in a peer review, or on site, or not at all. The difference isn't talent or speed — it's whether they traced the load path themselves or trusted the model to have figured it out.

The model never figured it out. It solved the path you gave it. Knowing whether that path is real is the job.