The best financial modellers aren’t finance experts or Excel wizards. They’re structural problem solvers.
After 30 years in financial modelling, I’ve stopped being surprised by who turns out to be genuinely great at it. It’s rarely the person who knows the most about finance. It’s almost never the fastest in Excel. It’s usually the person who can look at a messy, ambiguous problem and see its structure before anyone else in the room.
That’s a different skill entirely. And the industry is still largely in the dark about it.
The two false gods of financial modelling
There are two archetypes that get celebrated in financial modelling circles, and both are overrated.
The Finance Guru. Deep domain knowledge, knows every covenant structure, can quote DSCR thresholds from memory, understands the deal better than anyone. Valuable? Absolutely. A great modeller? Not necessarily. Domain knowledge tells you what to model. It says almost nothing about how to model it. The guru who can’t separate their understanding of the deal from the logical structure of the model produces something that only they can maintain - and only while they still remember why they built it that way.
The Excel Wizard. Fastest hands in the room, dynamic arrays, Power Query, macros on demand. Again, valuable as a capability. But tool proficiency is execution speed, not analytical quality. You can be extraordinarily fast at building something that is fundamentally misconceived. The Excel wizard who hasn’t resolved the underlying problem structure just produces elegant-looking errors faster than everyone else. I see it all the time - super fast (way faster than me) - fastest to head down the wrong direction which carries a HUGE overhead in the deal domain.
The thing both archetypes share is that they’re optimising at the wrong level. They’re working on the surface of the problem. Great modellers work on the structure underneath it.
Finance people hack at technology. And it’s costing them.
There’s a pattern I’ve watched play out repeatedly as financial modelling has brushed up against modern technology - automation, APIs, Python, AI-assisted analysis, model verification tools. Finance people engage with it the same way they engage with Excel: they hack at it.
They find a workaround that produces the right number today. They bolt on a fix without understanding the underlying structure. They copy a script from Stack Overflow and modify it until it stops throwing errors, without understanding what it’s actually doing. They build on top of fragility and call it a solution.
This isn’t a character flaw. It’s a training problem. Finance, as a profession, has always rewarded output speed over structural rigour. Get the model out. Close the deal. Fix the errors when they surface. The incentive to understand why something works has always been weaker than the incentive to make it work now.
That approach was always expensive. In a world where financial models are increasingly integrated with live data, automated workflows, and AI-assisted verification, it’s becoming untenable. Hacking at technology produces systems that are brittle, opaque, and impossible to audit - which is exactly the opposite of what the industry needs as the stakes around model accuracy continue to rise.
The template industry is the most honest proof of this. For decades, vendors have sold standardised model templates as the solution to modelling inconsistency and risk. The pitch is compelling - pre-built structure, proven logic, just add your numbers. The market has repeatedly shown that it doesn’t work. Templates fail because they encode someone else’s dimensional assumptions about a problem that is almost never identical to yours. They give you the appearance of structure without the thinking that produces it. If a genuinely great template solution existed, I’d use it - and I’ve spent 30 years looking.
The underlying problem is the same one that produces bad models and bad technology integrations: the absence of structural thinking before the build starts. A finance professional who has learned to think dimensionally - who frames the problem before reaching for the tool - approaches everything differently. They ask what the system needs to do before they ask how to make it do something. Templates, hacks, and Excel shortcuts are all answers to the wrong question. That shift in sequence changes everything.
What structural problem solving actually means
About 20 years into my career, I started working closely with a software architect. Not a modeller, not a finance person - someone whose entire discipline was about decomposing complex systems into clean, logical structures before a single line of code was written. It changed how I modelled fundamentally and permanently.
What I realised was that I’d been doing a version of this thinking instinctively, but without the vocabulary or the rigour to apply it consistently. The software architecture lens gave me both. And looking back, it’s probably the single biggest inflection point in the quality of my own work.
The irony is that the knowledge transfer almost never runs in that direction. People occasionally move from modelling into software - usually into fintech or data roles. People almost never move from software architecture into financial modelling. And the rare few who do tend to be extraordinary. The profession is leaving an enormous amount of value on the table by not deliberately building that bridge.
Before a great modeller opens Excel - or any tool - they do something that most modellers skip entirely: they decompose the problem dimensionally.
What are the true variables here? What drives what? Which relationships are linear and which aren’t? What’s a stock and what’s a flow? What timeframe does each variable live in - is it instantaneous, periodic, or cumulative? Where are the feedback loops? Where are the hard constraints?
This is dimensional thinking, and it’s closer to mathematics than it is to finance. It’s the ability to see a complex economic structure - a project finance deal, a leveraged buyout, a power purchase agreement - not as a collection of financial concepts, but as a system of relationships between quantities. Before a single formula is written, the architecture of that system should be clear.
Problem framing sits on top of that. A model is always answering a question - but the question is frequently misunderstood, underspecified, or conflated with a different question that’s easier to answer. What is the decision this model actually needs to support? What does the audience need to be able to see and test? What does not need to be in the model? Problem framing is the discipline of answering those questions before the build starts, so that the model’s structure serves its purpose rather than just reflecting the modeller’s habits.
Most models are built without either of these steps. It shows - sorry!
Where Excel fits - and why its constraints are actually useful
Excel is a two-dimensional grid. Rows, columns, sheets. That’s it.
The problems financial modellers are asked to represent are rarely two-dimensional. They have time, scenarios, tranches, entities, asset classes, counterparties - multiple dimensions of structure that need to coexist. Forcing that into a flat grid is always a compromise.
But here’s what’s interesting: that constraint is a diagnostic tool if you know how to read it.
When a model starts getting genuinely ugly - when the tabs multiply uncontrollably, when the formula references become impossible to follow, when every change breaks three other things - it is almost always a symptom of unresolved dimensional thinking. The model is fighting the grid because the modeller hasn’t fully worked out the structure of what they’re building. Excel didn’t cause the problem. It revealed it.
Conversely, a model that sits cleanly in the grid - where the flow of logic is clear, where each tab has a coherent purpose, where the dimensional structure has been resolved into something the tool can represent without distortion - that’s a model built by someone who did the structural thinking first.
Excel’s two-dimensional constraint is, in this sense, honest. It punishes confused thinking. It rewards structural clarity.
The implication for how to build
If great modelling is fundamentally about structural problem solving, that has real consequences for how we develop and identify talent.
It means the most valuable thing you can develop in a modeller isn’t Excel speed or product knowledge. It’s the habit of decomposing problems dimensionally before touching a tool. It’s the discipline of framing the question clearly before designing the answer. It’s the mathematical intuition to know when a relationship is being represented correctly and when it’s being fudged for convenience.
These are harder skills to hire for because they don’t show up on a CV the way Excel certifications do. They show up in how someone thinks through a problem in a conversation - how quickly they identify the structural question underneath the surface question, how comfortable they are with ambiguity before they’ve resolved it properly.
It’s also why model verification is so hard. Checking whether a model is right isn’t a formula audit. It’s a structural question: does the logic of this model correctly represent the economic reality it’s supposed to capture? That requires the same dimensional thinking that building the model well requires in the first place.
The takeaway
Financial modelling is a discipline that sits at the intersection of mathematics, logic, and communication. The finance knowledge matters. The Excel skills matter. But neither is the foundation.
The foundation is structural thinking - the ability to see the shape of a problem before you start solving it, to decompose it into its true dimensions, and to build something that represents economic reality accurately rather than conveniently.
The modellers who have that are rare. They’re also the ones whose work holds up under pressure, survives deal evolution, and can actually be trusted when the decision is on the line.
That’s the edge worth developing - work at it.
First published on Nick Crawley’s Substack.
