Finance Systems
The work around the data is the bottleneck, not the data — Issa Al Balushi
Most teams I work with already have the data.
The CRM has the deals. The billing system has the invoices. The HRIS has the headcount. The general ledger has the entries. Someone, somewhere, built a Looker dashboard last year that even has the right joins.
What they’re missing is the work around the data. Who pulls the export. Who reconciles the two systems that disagree by 3%. Who decides the methodology when a refund spans two months. Who writes the email that explains why this quarter’s variance is bigger than the last one. Who follows up the day after the meeting to actually close the action item.
That work is invisible. It doesn’t show up in any system. It lives in spreadsheets, Slack threads, four-line emails, and the heads of two or three people who happen to remember how things were done last cycle.
And it is almost always the bottleneck.
I keep coming back to one specific pattern. A team will ask: “Why does the close take so long?” The reflexive answer is always something about the tooling — the GL is old, the close software is clunky, the integrations are flaky. So the team buys better software, or asks engineering for a new pipeline, or hires a consultant.
A few months later, the close still takes the same number of days.
When I sit with the team and walk through what actually happens between day zero and day eight, the tooling is rarely the slow part. The slow part is the chain of decisions that no one wrote down. “Wait, do we recognize this on the contract date or the start date?” “Should that adjustment go to corporate or to the BU?” “Who has authority to sign off on this accrual?” Every question stops the line. Every answer requires finding the one person who remembers the last time it came up.
This is not a data problem. It is a workflow problem masquerading as a data problem. The data team can’t fix it because the data is already correct. The engineering team can’t fix it because there’s no code path to optimize. It belongs to whoever is willing to map the actual decisions and the actual handoffs — and to write them down somewhere durable.
The diagnostic question I find most useful is short:
Where, in the last cycle, did the work stop and wait for a person?
Not where the system broke. Not where the data was wrong. Where it stopped and waited.
If you ask that question across three cycles in a row, you get a list. The list will surprise you. It’s almost never where you thought the problem was. The actual bottleneck is usually a junior person waiting for a senior person’s signoff on something the senior person doesn’t realize is blocking anything. Or it’s a handoff between two teams where neither side considers themselves the owner. Or it’s a single spreadsheet that one analyst maintains by hand because the official tool can’t do the one thing leadership keeps asking for.
These are workflow questions. They look like data questions only because the symptom shows up in a report.
What I’m trying to do with most of my work right now is take that diagnostic seriously. Map the work around the data. Find the handoffs that stop and wait. Decide whether the right fix is a process change, a written policy, a small tool, or just naming the bottleneck out loud so it can be staffed.
It’s slower than buying software. It’s less impressive than building a dashboard. It is, in my experience, the thing that actually moves the close from eight days to four.
More notes on this to come.