THE SCARY ANALYST
The Scary Business Analyst
There is a man I know named Igor.
Officially, he is a Senior Business Analyst.
Among friends, however, we jokingly call him something else.
The Scary Business Analyst.
Not because he is loud.
Not because he enjoys proving people wrong.
And certainly not because he wants people to feel uncomfortable.
The nickname appeared for a completely different reason.
When you know you're about to meet Igor, you prepare.
Not because anyone expects you to.
Because you know he will.
If you mention a number, he'll ask where it came from.
If you reference a report, he'll want to know who prepared it.
If you base a conclusion on an assumption, he'll quietly ask whether anyone has verified that assumption recently.
If you say, "I think," he'll probably ask, "How do you know?"
Never aggressively.
Never to embarrass you.
Only because he genuinely believes that important decisions deserve honest answers.
The first few conversations with him can be exhausting.
Not because they're difficult.
Because they force you to think.
You begin checking your own reasoning before he ever asks the question.
You verify documents.
You revisit numbers.
You separate facts from assumptions.
You stop using words like probably when the business depends on certainty.
Over time, I realized something unusual.
People don't become more careful around Igor because they're afraid of him.
They become more careful because he respects the truth too much to let anyone, including himself, settle for convenient answers.
That kind of discipline is rare.
Much rarer than technical expertise.
Most companies have people who know Excel.
Many have people who know finance.
Some have brilliant analysts.
Very few have someone whose instinct is to quietly improve the quality of every decision being made around them.
Looking back, I don't think Igor's greatest talent is analysis.
I think it's intellectual honesty.
And once you've worked with someone like that, it quietly changes the way you think forever.
NOT ABOUT EXCEL
A Spreadsheet That Was Never About Excel
The first time Igor showed me his spreadsheet, I expected to see something extraordinary.
After all, I already knew the company relied on it for some of its most important business decisions. I imagined an intimidating financial model built over decades, thousands of formulas, endless worksheets, something only its creator could possibly understand.
Instead, I saw Microsoft Excel.
Rows.
Columns.
Pivot tables.
Charts.
Nothing that looked revolutionary.
If someone had taken a screenshot and posted it online, most people would have scrolled past it without a second thought.
They would have seen a spreadsheet.
I almost made the same mistake.
Then Igor started explaining what I was actually looking at.
For the next few hours, we barely talked about Excel.
We talked about people.
About dozens of departments sending documents in different formats.
About reports that arrived late.
About numbers that looked correct but couldn't be trusted.
About information that had to be verified before it deserved to become part of a financial forecast.
He wasn't explaining formulas.
He was explaining why those formulas had to exist.
Every worksheet had a story.
One existed because two departments interpreted the same business event differently.
Another appeared after a forecasting mistake revealed that an important assumption had silently become outdated.
A third was created because the "official" report consistently arrived too late to be useful, forcing the business to find another way to understand what was happening.
None of those decisions came from Excel.
They came from years of observation.
Years of asking uncomfortable questions.
Years of refusing to accept numbers simply because they looked convincing.
That's when I understood something that has stayed with me ever since.
The spreadsheet wasn't organizing data.
It was organizing reality.
Every improvement represented another piece of business knowledge that had been discovered, tested, challenged, refined and finally trusted.
It wasn't a collection of formulas.
It was a living model of how one complex business actually worked.
And that changed the way I think about software forever.
HOW SYSTEMS START
Every Enterprise System Starts the Same Way
That afternoon, I stopped thinking about Excel.
Because Excel had never been the point.
The spreadsheet was simply the place where years of thinking had been recorded.
And that's a very different thing.
We often imagine that enterprise software begins with a large budget, a consulting firm, months of workshops, and a team of developers drawing architecture diagrams on whiteboards.
It rarely does.
More often, it begins with one person trying to solve one problem.
A founder opens a blank spreadsheet to track sales.
An accountant creates a better way to reconcile payments.
An operations manager builds a simple table to monitor inventory.
A business analyst notices that two reports never quite agree, and decides to find out why.
None of them are trying to build an enterprise platform.
They're trying to make tomorrow a little better than yesterday.
Then something remarkable happens.
The business grows.
New employees arrive.
New products appear.
New suppliers.
New regulations.
New markets.
What began as a simple solution slowly becomes a system.
One improvement leads to another.
One exception creates a new rule.
One discovered pattern changes the forecasting model.
One mistake prevents ten future mistakes.
Year after year, the spreadsheet becomes less about calculations and more about accumulated understanding.
Eventually, the business reaches a point where everyone agrees:
"We've outgrown Excel."
They're usually right.
But they often misunderstand why.
The problem isn't that Excel has become too small.
The problem is that the business has become too intelligent.
What no longer fits inside the spreadsheet isn't the data.
It's the knowledge.
The relationships.
The exceptions.
The reasoning.
The invisible architecture that has been evolving for years.
We wrote a whole piece about this exact kind of invisible structure, Most Companies Don't Own Their Website. They Own a Collection of Dependencies.
That's why so many digital transformation projects struggle.
Companies believe they're replacing software.
In reality, they're attempting to preserve decades of human understanding.
And if that understanding is never discovered, documented, and questioned before development begins, no programming language, AI model, or enterprise platform can recreate it.
Technology can execute logic.
It cannot invent the business logic that was never captured in the first place.
NOT JUST SMALL BUSINESS
It Isn't Only a Small Business Problem
Here is the part that surprised me most.
This isn't something that only happens to founders working out of a spare bedroom, or to companies too small to afford proper systems. It happens to some of the most resourced, most experienced organizations in the world, because the problem was never about budget. It was about where knowledge lives.
In 2012, JPMorgan Chase's Chief Investment Office was running one of the most sophisticated risk-management operations in global finance, a bank that had just come through the 2008 crisis looking stronger than almost anyone on Wall Street. Buried inside that operation was a risk model, maintained partly by manually copying and pasting values between spreadsheets. A formula that was supposed to average two numbers ended up summing them instead. That single, silent error helped a trading position balloon out of control. The eventual loss came to more than six billion dollars, along with congressional hearings, regulatory fines, and a CEO whose pay was cut in half that year. Nobody at JPMorgan thought of themselves as "an Excel shop." They were, by reputation, the opposite. It didn't matter. The knowledge of exactly how that spreadsheet worked, and exactly what its formulas assumed, lived with very few people, and nobody outside that small circle was positioned to catch the error before it became a crisis.
In 2020, at the height of the pandemic, England's national health agency was collecting positive COVID-19 test results into a spreadsheet format that dated back to 1997, one with a hard limit of roughly 65,000 rows. Nobody decided to lose data. But once each day's file filled up, every new row past that limit simply vanished, silently, with no error message. Nearly 16,000 positive test results disappeared from the official count for more than a week. As many as 50,000 close contacts were never reached by contact tracers in time. The system did exactly what it was built to do. It just wasn't built by anyone who had mapped, end to end, everything it would eventually need to hold.
Smaller versions of the same story show up constantly. A Canadian power company lost twenty-four million dollars to a single cut-and-paste error in a hedging spreadsheet. A well-known camera company overstated an employee benefits liability by eleven million dollars because of one extra zero. An influential academic paper on national debt and economic growth, cited to help justify austerity policy across Europe after the 2008 crisis, turned out to rest on an Excel average formula that silently excluded several countries' data from its calculation.
None of these organizations were careless. None of them lacked talent, budget, or technical sophistication. What they had in common was simpler and more universal: critical business logic that lived inside one file, fully understood by very few people, and effectively invisible to everyone else, until the day it broke.
This pattern is common enough that it has several names, coined independently by people who kept running into it from different directions.
Risk managers call it Key Person Dependency Risk, the point at which a business has become so reliant on one individual's knowledge that losing them would materially disrupt operations. It is no longer treated as a soft HR concern. The UK's Financial Conduct Authority has folded it into its operational resilience requirements for financial institutions, and the U.S. Securities and Exchange Commission requires public companies to disclose the risk in their annual filings when it could materially affect the business.
Software engineers call it the Bus Factor, a blunt way of asking how many people would need to disappear before a critical system stopped working. On a healthy team, the answer is several. On far more teams than anyone likes to admit, for their single most important process, the honest answer is one.
IT departments have a name for the systems that appear without them: Shadow IT. It describes the tools, spreadsheets, and workarounds a business unit builds on its own because waiting for an official solution costs more than building an unofficial one. By some industry estimates, over a third of all enterprise technology decisions happen this way, quietly, outside any officially sanctioned process, until the day someone notices.
And operations teams simply call the knowledge itself Tribal Knowledge, the fixes, exceptions, and workarounds that exist only in someone's head, or in someone's spreadsheet, and nowhere else in the organization.
Four different names, from four different disciplines, all describing the same thing Igor's spreadsheet was quietly solving for, one worksheet at a time.
BEFORE WE BUILD
Before We Build Software, We Look for Igor
That conversation changed something fundamental for me.
For years, I believed software projects started with requirements.
Today, I think they start somewhere else.
They start with people.
Not because people are more important than technology.
But because technology is incapable of creating understanding.
It can only preserve it.
Since then, every time someone asks us to build a website, an internal platform, a custom application, an AI solution, or a completely new digital product, I find myself asking a very different question.
WHO IS IGOR
Who is Igor?
Not literally.
Every company has a different name.
Sometimes it's an analyst.
Sometimes an operations manager.
Sometimes an accountant.
Sometimes a production engineer.
Sometimes it's the founder.
Sometimes it's the person nobody notices until they're on vacation.
They're rarely the loudest voice in the room.
They usually don't have the most impressive title.
But over the years, they have done something extraordinary.
They've spent thousands of hours observing the business.
Finding patterns.
Questioning assumptions.
Eliminating unnecessary complexity.
Improving processes no one officially asked them to improve.
Teaching colleagues who genuinely wanted to learn.
Not because it was written in their job description.
Because they couldn't ignore a system that could become better.
Those people are building software long before developers ever write a line of code.
Their programming language just happens to be conversations, documents, spreadsheets and experience.
Eventually, every successful business reaches the same crossroads.
The spreadsheet is no longer enough.
The processes have outgrown the tools that created them.
A new system has to be built.
This is where many companies make an expensive mistake.
We wrote a longer breakdown of exactly this pattern in How to Choose a Web Development Company.
They begin with technology.
Python or Java?
Custom software or SaaS?
AI or automation?
Cloud or on-premise?
Those are important questions.
They're just not the first questions.
The first question is much simpler.
WHAT PEOPLE KNOW
What have your people already discovered about the way this business works?
Because that knowledge is the foundation of every successful system that will ever be built. It's also, as JPMorgan and Public Health England learned the expensive way, the thing that quietly determines whether a company discovers its own blind spots on its own terms, or discovers them in a headline.
A well-designed platform doesn't replace the spreadsheet.
It inherits its wisdom.
It preserves years of decisions, lessons, mistakes, and discoveries, while removing the limitations that once made those discoveries difficult to scale, and the single points of failure that once made them fragile.
That's why our discovery process begins with people, not technology.
It's the same conviction behind The Hidden Cost of Choosing the Wrong Architecture.
With conversations before architecture.
With curiosity before code.
Sometimes those conversations confirm that a business truly needs custom software.
Sometimes they reveal that an existing system only needs to evolve.
Sometimes the right answer is surprisingly simple.
The technology changes.
The tools evolve.
AI will continue to reshape the way we build software.
But one principle has remained true in every meaningful project I've been part of.
BORN FROM PEOPLE
Great Software Is Never Born From Technology
It is born from people who cared enough to understand the business before anyone tried to automate it.
Every business has its own Igor. Most businesses also have their own bus factor of one, they just haven't been unlucky enough yet to find out where.
Before recommending a website, custom software, AI integration, or a digital platform, we believe the first step is understanding how your business actually works. That's exactly what our Strategic Sessions are designed to do.
- Share
-
-
-
-
