Engineer
Designing 240-metre towers at SOM taught me how complex systems actually get delivered — and exactly where their assumptions run out.
Five projects across three continents taught me that the boundary between 'how it's always done' and 'what the problem actually requires' is where the most interesting work lives. At SOM, the only way to push the boundaries was to prove it — quantifying every unknown until the unconventional became undeniable.
Working without defaults demands a method. This is mine.
Let the problem surface the solution
Start with what the problem actually requires, not what the standard says is good enough. Rules are written for common cases. Interesting problems rarely are.
Build the tool if it doesn't exist
When the right tool doesn't exist, build it. Problems at the edge of what's been done before usually need methods that don't exist yet.
Work across the full stack
Don't hand the problem off at the boundary of your discipline. The most important insights usually live at the interfaces.
Quantify what you don't know
Pushing the boundaries means working with uncertainty. Measure it, bound it, and make explicit decisions about what's acceptable.
Five projects. Five moments where the default answer wasn't good enough.
500 Folsom
San Francisco · 2015–2019
A tower designed for the earthquake that hasn't happened yet — by modelling exactly what would happen when it does.
View gallery →
Karlatornet
Gothenburg · 2015–2019
Scandinavia's tallest building — designed around the idea that the structure should disappear.
View gallery →
Thames City
London · 2016–2019
Three towers. One constrained site. Existing Underground tunnels directly below. The conventional response to that kind of constraint is to add structure.
View gallery →
HiLo / NEST
Zurich · 2019–2023
The proof that the floor slab — the most material-intensive element in a building — doesn't have to work the way it does.
View gallery →
Museum of Modern Art
Warsaw · 2016–2019
A concrete façade designed to move — and the structural system built around that fact.
View gallery →The projects are specific. The lessons aren't.
I think in systems, not in components.
A complex problem is never a local exercise. If you want to solve the system, you need to see it in all its complexity. That's how I learned to always step back and see the whole.
I'm comfortable where a wrong assumption has real consequences.
When you work on real, tangible things like a building, you develop a different relationship to uncertainty. You learn to quantify it, work with it, and make decisions despite it rather than pretending it away.
I've learned to be a beginner on purpose.
The most interesting problems sit just past the edge of what you know. Getting there means being willing to start from scratch. I've made that choice more than once. It's never felt wrong.
I'm looking for the next hard problem. If that sounds like yours — let's talk.
franaudo.com