I figure that I know as much as the average person about how cars work. I can tell you what a cam shaft is, what spark plugs do, and why the carburetor is a relic. But still, I’m at the complete mercy of auto mechanics. If the mechanic tells me that the alternator needs to be replaced and, a week later, tells me that it has been replaced, I can’t open the hood and evaluate the work. I don’t know whether right component has been installed, whether any bolts were replaced and tightened correctly, whether the work was adequately checked and tested, or even what questions I should be asking.

Effectively, I can only make useful judgments about the work product of mechanics in the case of gross failures. To me, all basically competent mechanics are qualitatively equivalent.

Clients judge the service level, when they can’t judge the service

What I can and do evaluate, though, is the quality of service that mechanics provide. Does the mechanic clearly explain to me the problem and its remediation? Do the final charges match the original estimate? Is the work done on schedule or predictably late? Is the mechanic attentive or did he or she make me wait on hold or stand around in the garage while attending to other matters?

Naturally, I’m inclined to believe that a mechanic who is transparent, reliable, and detail-focused where I can see is more likely diligent where I can’t. As the tractable aspect of the interaction, customer service becomes a proxy for judging overall value.

The moral for mechanics, and the rest of us, is that client experience matters tremendously. Adequate work backed by great customer service can be better than great work plus mediocre customer service.

Focus on your client’s values. Know when they’re different from yours.

The key to great service is to focus on what’s important to the client. And, clients often value different aspects of the experience than the people they hire to do work for them. Experts and technicians naturally value deep expertise, attention to detail, and elegance, all of which are good values. But, they’re not necessarily the client’s primary focus.

Imagine you are building an iPhone app for a client. You decide that it would be a good idea to build in the flexibility to deliver the app on Android later. So, you take the initiative to use a framework that supports multiple platforms, which requires 3 extra days of work.

You may proudly declare that you spent an extra 3 days at no charge to ensure that the client has the option to use Android in the future. But, the client may only hear, “Your app will be 3 days late.” The fact that you went above and beyond will be lost because the client perceives no difference in the outcome. Focused on what you value, future-proofing, you miss what the client values more, time to market.

Don’t take this as an argument to cut corners and take advantage. Just remember that it’s your job to stay in alignment with the client. Surprise delays are always unwelcome and the explanations we make for them, even when valid, get heavily discounted.

Identify with the mechanic and think like the client

Here’s a good test of the value of some aspect of customer service: How much would the service affect (or not) your choice of an auto mechanic?

As professionals, we are all in the mechanic’s position. By the nature of specialization, professionals at anything have a better understanding of the work that they do than their clients. Yet, we have imperfect access to understanding what the client values.

From our privileged, yet also disadvantaged, position relative to the customer, we can do two things to put the customer at ease:

One, reduce the information gap by making reasonable efforts to explain neutrally to the client the work that is being done and why. Include a basic analysis of trade offs, cost drivers, and risks. A better understanding of the work will help a client to evaluate quality objectively and rely less on soft indicators.

And two, focus on the perspective of the client in order to deliver a great experience. Specifically try to exclude what you know about the quality of your product or service that, because of experience or information disparity, may not be accessible to the client.

It’s easy to fall into the trap of trying to convince the client of a truth that she or he cannot see. The success of such efforts will depend on your credibility with client, i.e. on subjective judgements. Frequently, they are attempted precisely because credibility has been damaged and bear the weight of apparent conflict of interest. Think of a mechanic trying, after the work is done, to explain the necessity of replacing an expensive component.

Better, focus early on how a client will reasonably assess your contribution and provide relevant and appropriate tools.

And yet they were no better positioned than those aspirational organizations when tackling significant analytical efforts. Those projects required something that no amount of quality and governance investment could provide: a working knowledge of how the data had been constructed, what edge cases the models had silently absorbed, and which institutional practices were encoded not in any system but in the heads of the people who had been there long enough to know. Deriving an accurate picture of what was actually happening in the business required extensive enrichment, careful transformation, and a kind of expert interpretation that felt more like archaeology than analysis.

For a long time I assumed this reflected a governance gap, that more documentation, better metadata, and stronger standards would close it. The more I worked through these environments, though, the more a different diagnosis emerged: the underlying models were not faithfully representing their domains, and all the governance in the world could not compensate for that.

Data quality vs. representational adequacy

Data quality, as the field usually defines it, concerns the accuracy and reliability of individual values: whether a field is populated, whether a number is correct, whether a record reconciles to another. Representational adequacy is a different kind of question. It asks whether the model, the collection of tables, fields, and relationships that defines what gets stored, actually captures the structure of the business reality it is meant to describe. A system can achieve impeccable data quality by every conventional measure and still fall well short of this.

The clearest way to see this is through an example. A trading system records each trade as a single record, and among the fields it captures is the salesperson who originated the deal. This is a natural and useful thing to store, and for years it works exactly as intended. Then the business evolves: salespeople begin collaborating on larger transactions and splitting the commissions, and the practical solution is to book two trade records rather than one, crediting each salesperson individually. Each record is accurate. The salesperson is correctly identified, the commission correctly calculated, and an auditor reviewing either record would find nothing to question.

What has quietly broken is the model’s correspondence with the underlying reality. A trade record now serves two purposes simultaneously: it is both a record of a transaction and a unit of compensation credit. Anyone who later wants to count transactions with a given counterparty, or analyze trading volume in a particular product, will find numbers they cannot trust without first knowing this history and working around it manually. No individual value is wrong, but the model has been stretched past the point where it reliably represents what it was built to represent.

When the transaction disappears

A structurally more complex version of this problem appeared at one of those Swiss banks in the treatment of repurchase agreements, or repos. A repo is a short-term financing transaction in which one party sells securities (typically government bonds) to another, with a simultaneous agreement to repurchase them on a specified future date at a slightly higher price. The difference between the sale price and the repurchase price is effectively interest, and the securities serve as collateral for what is, in economic substance, a short-term loan.

The bank’s system recorded repos as two separate trades: the initial sale and the forward repurchase. Both legs were captured faithfully and accurately. But the system held no representation of the repo itself as a unified transaction. There was no link between the two legs, no encoding of the agreed repurchase price as a rate of return, and no concept of a collateral relationship connecting them. To calculate the implied interest rate on any given repo, an analyst had to know to locate both legs and perform the arithmetic manually. To track whether collateral had been substituted during the life of the transaction, which is a common event in active repo books, required institutional knowledge of how substitutions would have been recorded, because the system had no model of substitution at all. The individual values were accurate in every respect, but the repo itself, as a coherent object with a term, a rate, and a collateral relationship, had no place in the system.

What these two examples have in common is that competent people made reasonable decisions. Recording two trades for a split commission is a pragmatic solution to a genuine business need. Recording both legs of a repo is technically accurate as far as it goes. The failure in each case is more subtle, and harder to catch in the moment: neither approach considered whether the model, as extended, would continue to correspond to the underlying reality it was meant to describe. The commission-split convention turned trade records into something else, and the two-legged repo recording preserved all the arithmetic while discarding the transaction itself.

Representational adequacy, as I have come to understand it, is the quality of that correspondence. A representationally adequate model captures the entities that actually matter in the domain, along with the relationships and events that define their behavior. Where the business has exceptions or non-standard processes that arise regularly enough to matter, it models those explicitly rather than absorbing them through workarounds that gradually obscure the underlying structure. Its absence rarely triggers a data quality alert, because the individual values are accurate and lineage holds up under scrutiny; the problem surfaces only when someone tries to answer a question the model was never designed to support.

This doesn’t fix itself downstream

The practical urgency is that representational problems do not get easier to address once data has entered the warehouse. There is a reasonable intuition that these issues can be resolved during the transformation process — what practitioners call the bronze-to-silver stage, where raw ingested data gets cleaned, standardized, and aligned. And transformations can do a great deal: inconsistent formats, naming conflicts, identifier mismatches are all addressable there.

What they cannot do is reconstruct meaning that was never recorded. If split-commission trades enter the raw layer as independent records with no indication that they belong together, there is no transformation that can recover the connection without someone encoding the institutional knowledge that these records represent a single transaction. If repos arrive as two unlinked trade legs, any downstream analysis that depends on treating them as a single instrument must carry that reconstruction logic forward indefinitely, updated as the business changes and explained to every new team member who inherits the pipeline. The transformation layer gradually accumulates business rules that should have lived in the source system, and the burden of interpretation compounds quietly over time.

This is why the representational work has to happen before data enters the warehouse — not necessarily by overhauling the system of record, which is often impractical, but by ensuring that whatever feeds the warehouse correctly represents the domain. Sometimes that means a tactical reconstruction: a purpose-built feed that merges split-commission records into unified trades, or links repo legs into single transaction objects with their associated terms and rates. It is unglamorous work, and it lives upstream of where most data teams focus their energy. Without it, every layer built above inherits the same interpretive burden.

What strikes me, looking across the organizations I have worked with, is that neither of these failures is unusual. The commission-split problem and the two-legged repo are instances of patterns that appear, in different forms, across industries and systems of every kind. Once you know what to look for, you start seeing them. And once you see them, you find yourself asking different questions — not just whether the data is accurate, but whether the model behind it actually represents the thing you are trying to understand. That shift in framing is, I think, where the more durable fixes begin.