As an Excel trainer, I get a very particular kind of call again and again.
A team reaches out because their spreadsheets feel fragile. Numbers are difficult to trust. Only one or two people really understand how things work. Everyone else is hesitant to touch anything important. There is usually some pressure involved, often a reporting deadline or a recent mistake that made leadership uneasy.
Then the request comes, sometimes directly and sometimes between the lines.
Could you come in and fix our spreadsheets?
I understand why that sounds reasonable. When something important is misbehaving, the instinct is to want it repaired by someone who knows what they are doing. In the short run, that instinct often makes things feel calmer and more controlled.
It is also where many teams accidentally make their long-run situation worse.
What usually happens after the spreadsheet is fixed
When I step into situations like this, the technical issues are rarely mysterious. Logic can be cleaned up. Errors can be corrected. Structure can be made more consistent. Afterward, the spreadsheet often works better.
What changes much less reliably is how the team relates to the spreadsheet. Understanding is still uneven. Confidence is still concentrated. People still hesitate before making changes. Questions still route to the same individuals.
Over time, the organization becomes more dependent on outside help rather than less.
The spreadsheet improves, but the risk increases.
The matrix I use to make sense of this
To explain why some Excel interventions age well and others do not, I use a simple 2×2 matrix. It looks at Excel work along two dimensions.
The horizontal axis is ownership: whether understanding lives with one person or is shared across a team. The vertical axis is durability: whether the work holds up over time as people, requirements, and context change. Those two dimensions create four common patterns.
Bottom left: Hero fix
This is where many teams start: one person steps in when something breaks. The fix is fast and effective. The immediate problem goes away.
The cost is that knowledge stays concentrated. The next change requires the same person again. Over time, the spreadsheet becomes something people are grateful for but afraid of.
Bottom right: Ad hoc internal fix
Here, ownership is broader, but structure is weak: multiple people make changes. Conventions vary. Logic accumulates without a shared design approach.
Teams in this quadrant often feel responsible but exhausted. Every change feels risky because no one has a clear mental model of how the spreadsheet is supposed to work.
Top left: Consultant dependency
This is the quadrant many teams mistake for a long-term solution. The spreadsheet is technically strong. Outputs are reliable. But understanding still lives outside the organization. When the consultant is unavailable, progress slows or stops.
Durability improves, but dependency remains.
Top right: Durable Excel systems
This is where teams usually want to end up, even if they do not articulate it this way. In this quadrant, understanding is shared. Assumptions are written down. Patterns repeat. More than one person can modify the work safely.
The spreadsheet survives turnover and change because it was designed with handoff in mind.
Why “just fixing it” does not move teams where they want to go
Most requests to fix spreadsheets move teams upward in the matrix but not across it. The work becomes technically stronger, but ownership does not change. That is why the same teams often find themselves revisiting Excel problems year after year, even after investing in expert help. The relief is real. The improvement is temporary.
One simple way to see where risk is hiding is to ask a few practical questions:
| Question | What a “no” usually signals |
|---|---|
| Could more than one person explain how this works? | Knowledge is concentrated |
| Could a new team member make a safe change? | Structure is unclear |
| Are assumptions written down anywhere? | Risk is implicit |
| Would this survive turnover? | Dependency is high |
What I do instead
At Stringfest, I do not take ownership of client spreadsheets or quietly repair them behind the scenes.
That choice is intentional. Fixing files for people often increases reliance on external help. It solves the immediate problem and reinforces the conditions that created it.
For that reason, I usually start engagements with short, structured sessions, often around 90 minutes, using examples drawn from outside the organization rather than deeply customized internal files.
This is not because internal work is unimportant. It is because jumping straight into a team’s existing spreadsheets often locks everyone into the same confused definitions, inconsistent flows, and unspoken assumptions that caused the problems in the first place.
If a team does not yet share a common language for things like structure, inputs, outputs, and assumptions, trying to improve their real models immediately is usually counterproductive. You end up building on top of a weak foundation and calling it progress.
Working first with neutral examples creates space to slow down and align. People can talk about design choices without defending past decisions. Concepts can be named clearly. Patterns can be seen without the emotional weight of “this is our reporting model.”
Only after that shared understanding exists does it make sense to bring internal work back into the conversation.
This approach is how the work actually moves teams across the matrix, not just up it. It typically involves:
- slowing down where teams are used to rushing
- making assumptions explicit in plain language
- choosing repeatable structures over clever shortcuts
- designing Excel work so more than one person can modify it safely
The goal is for Excel work to hold up when people change roles, when requirements shift, and when questions come from new directions.
If a spreadsheet only works because I am involved, I do not consider that a successful outcome.
Why I am writing this down
I am writing this partly to set expectations and partly to make the tradeoffs visible. Many teams genuinely want better Excel systems but default to fixes that feel efficient and familiar.
Naming these patterns helps clarify what kind of help will actually improve things and what will only postpone the next round of frustration.
If you want to understand how I work
If this way of thinking resonates, I have laid out my approach in more detail on my How I Work page. It explains what I do, what I do not do, and why those boundaries exist.
That page should help you decide whether this is the kind of engagement you are looking for.