The Owner
The fix for CRM data debt starts with one person owning the architecture of the revenue stack. But most companies get the choice wrong — not by picking the wrong person, but by giving the right person the title without the one thing that makes the role work. Three filters for choosing the owner, and the mistake that makes the whole thing decorative.
- Author
- Jonaz Kumlander
- Published on
- Reading time
- 5 min read
In the data-debt trilogy I argued that revenue stacks decay one rational decision at a time, that nobody owns the connecting layer in most mid-market companies, and that AI has made the price of that gap much higher. I ended each essay the same way: the fix is ownership, then a map, then a gate.
This is the first of three essays on the fix. It is about the owner — and about why the most common way of appointing one produces a job title and nothing else.
The question everyone asks
After every talk I give on the spiral, the first question is the same: who should the owner be? It usually comes with a candidate already in mind — the marketing ops lead, the sales ops manager, the senior HubSpot admin who seems to know everything. And the instinct is often right. The person who should own the architecture is frequently already in the building.
But the question is slightly wrong, and the way it is wrong matters. "Who should own it?" is a casting question. The harder question is what does ownership require? — because if you cast the role without defining it, you get the most common failure I see: an owner in name, with no ability to own anything.
Three filters, in order
When I help a company choose, I apply three filters. The order is deliberate.
First: can they move between the business and the technology? The owner has to understand why sales wants the new field and what that field does to the data model. Why marketing's attribution tool needs the integration and what the integration does to the source of truth. Most people are fluent on one side. The rare ones are fluent on both, and they are the only candidates. A brilliant integration engineer who cannot explain to a CRO why the shortcut costs money will lose every argument that matters. A brilliant ops leader who cannot read an integration spec will be told "that's harder than it sounds" and have no way to know if it's true.
Second: do they have a mandate? This is the filter companies skip, and it is the one that decides everything. The owner's actual job, most days, is to say no — or more precisely, to say "not like that" to shortcuts that look harmless to the person requesting them. If the owner can review but not refuse, they are not an owner. They are a documentarian. They will produce beautiful maps of a stack that keeps decaying around them, and in two years someone will ask why the architecture function didn't prevent the mess it so carefully documented.
I want to be blunt about this because it is where good intentions die. Appointing an owner is easy and feels like progress. Giving that owner the right to block a request from sales, marketing or a regional leader is politically expensive, and it is the part that gets quietly dropped. An owner without veto is a job title. The map and the gate — the next two essays — both decay without it.
Third: do they have the time, and is it their real job? At mid-market scale, this is not a full-time role. It is one or two days a week of genuinely architectural attention: reviewing changes, keeping the map current, sitting in on the deals where integration scope drives risk. The failure here is subtle: because it does not fill a week, it gets bundled into someone's existing job as a third priority. And a third priority loses to the first two every time there is a deadline — which, in a revenue organisation, is always. Ownership has to be somebody's actual job, with time carved out and protected, or it will exist on the org chart and nowhere else.
Look inside first
Apply the three filters and something interesting usually happens: a name emerges that was already there. The ops lead who has been quietly maintaining a spreadsheet of integrations because nobody asked her to. The developer who knows which sync skips which records and why, because he built the workaround three years ago. The person everyone goes to when a report looks wrong.
These people are already carrying the map — in their heads, informally, unpaid and untitled. The cheapest and best ownership decision most companies can make is to take that informal role and make it formal: title it, give it the mandate, protect the time. The alternative is the version I have watched more times than I would like: the informal owner leaves, and the architecture leaves with them. Nobody notices for about six months, which is how long the undocumented knowledge takes to run out.
Internal or external
Sometimes nobody inside passes the first filter, or the one who does cannot be given the mandate for political reasons — the architecture owner cannot report into the function whose shortcuts they most need to refuse. In those cases the ownership comes from outside: a senior person on a part-time basis, with the mandate written into the engagement rather than negotiated across an org chart.
I have said this before and will keep saying it: I don't think it matters much whether the owner is internal or external, permanent or fractional. The three filters are the same. What matters is that the role passes all three — fluency, mandate, protected time — and that it is a real job rather than a hopeful line in a reorg deck.
The one-line test
If you want to know whether your company actually has an owner, ask one question: when did this person last say no to something, and did it stick?
If the answer is a date and a story, you have an owner. If the answer is "well, they raised concerns," you have a documentarian. And if the answer is a pause, you are in stage two or three of the spiral and the position is vacant — however many people have the word "architecture" in their title.
Next: the map — what happens when a company sees its revenue stack drawn on one page for the first time, and why that moment changes the conversation more than any tool purchase.