The 80/20 of Structural Design

The 80/20 of Structural Design

One thing I've noticed over the years is that most structural engineering jobs aren't actually that complicated. That's not to say they don't require care or good judgement, but the majority of residential projects are variations of problems we've already solved many times. Whether it's a new house, a townhouse development or a renovation, the principles are generally the same. The details change, but the underlying engineering is usually familiar.

Despite that, almost every project goes through exactly the same workflow. A straightforward beam replacement can end up following much the same process as a complex multi-storey development. Information gets entered into multiple programs, calculations are built from scratch, reports are formatted, drawings are checked and documentation is prepared. Before you've even started thinking about the challenging parts of the design, a significant amount of time has already been spent on work that is largely repetitive.

I think this comes from the way engineering workflows have evolved. Most practices build systems that can handle their most complicated projects, which makes sense. The problem is that those same systems end up being applied to every project, regardless of whether they actually need that level of effort. The result is that simple jobs inherit a process designed for the exceptions rather than the rule.

If you look at where engineers actually add value, it's rarely in the repetitive parts of the job. The value comes from understanding load paths, identifying potential issues before they become problems on site, deciding how a structure should behave and applying judgement where the standards don't provide a simple answer. Those are the decisions clients are paying for. Nobody hires a structural engineer because they're good at copying numbers between spreadsheets or formatting calculation reports.

That's why I think the 80/20 principle applies so well to structural engineering. Around 80% of projects contain maybe 20% of the technical complexity, yet we often spend just as much effort documenting and processing those projects as we do on the genuinely difficult ones. The routine work ends up consuming the same amount of attention as the engineering that actually requires experience.

As software has improved, we've become very good at solving calculations. Analysis that once took hours now takes seconds. Member design is faster than it's ever been. 

Ironically, that isn't where most engineers lose their time anymore. The bottleneck has shifted to everything around the calculations, preparing inputs, moving data between different tools, checking documentation and producing reports. The calculations themselves are often the quickest part.

I don't think the answer is to reduce checking or cut corners. Engineering will always need experienced people making decisions and reviewing work. But our workflows should reflect where that expertise is actually needed. If routine parts of a project can be completed more efficiently and more consistently, engineers can spend more time reviewing critical details, coordinating with architects and contractors, and solving the problems that genuinely require engineering judgement.

The goal shouldn't be to make engineers work faster for the sake of it. It should be to remove the unnecessary effort that has gradually become part of the process. Most projects don't need to feel like the most complicated job you've ever worked on. They need a workflow that's proportionate to the engineering involved, leaving more time for the parts of the job that actually matter.

Article written by Kevin Crowe