The Commercial Compass, Diveco’s corporate revenue-reporting tool, decomposes every revenue deviation by Shapley value: how much comes from volume, how much from price, how much from margin. It doesn’t just flag the deviation; it explains it. On top of that, it drafts the executive narrative with a language model. The four business units sum exactly to the corporate total, and underneath it all runs a serverless data lake that returns the query in milliseconds (in Spanish).
And yet users still called it “basic.”
The data unit I ran was fighting, in parallel, a different and more stubborn battle: getting the organization to trust its numbers. We’d build the right tool and then defend every figure one number at a time. For a long time I read that as a product problem: a missing feature, a chart that needed polish. I was wrong.
The gap was never about the quality of the tool. It was about trust and adoption.
Why isn’t rational utility enough?
Management was already pushing the Compass. There were “please complete this” emails, there was the obvious argument: this tool tells you, at a glance, where you’re making money and where you’re losing it. Rationally, using it was a trivial decision.
And we’d tried it the rational way. An institutional email, a how-to guide, a demo at the monthly meeting. The pattern was always the same: a spike in opens the first week, then a flat line back to baseline. The tool got opened once, to check a box, and never again. Nobody was lying when they said “I don’t have time”; there simply was no status reason to make the time.
The three objections that weren’t technical
Because the resistance wasn’t rational; it was behavioral. “It’s basic,” said by someone who’d never opened the decomposition view. “I don’t have time.” “That’s IT’s thing.” None of the three is a technical objection. They’re identity objections: opening the tool meant admitting you didn’t know how to use it, and admitting you don’t know something, in front of your peers, costs status. A “please complete this” email doesn’t move that. It pushes against exactly the wrong current: it asks for more of the same (use the tool) without touching the reason people weren’t using it.
Hence the insight, and it’s an uncomfortable one because it disarms the engineer’s reflex:
Adoption isn’t anchored in utility; it’s anchored in identity and status.
As long as the cost of using the tool was a status cost, no improvement to the tool was going to pay it off.
And it’s worth being honest about how uncomfortable that diagnosis is, because it’s exactly the one the engineer’s reflex rejects: it implies the problem didn’t live in the code but in the people, and people don’t get refactored with a pull request. The temptation, the one I had, was to keep polishing the tool, because that’s what we knew how to do. It would have meant improving, with real craft, the answer to the wrong question.
The move: wrap the tool, don’t explain it
If the obstacle is status, the solution has to operate on status. So instead of asking people to use the Compass, I built, inside the same portal, a small internal business school: the Diveco Business School. I launched it as an adoption pilot: scoped, measurable, reversible.
The course that wasn’t about the tool
Its Level 1 course isn’t a course about the tool. It’s a guided tour through the tool: net sales, price per unit (PPU), the MTD/YTD/YAG traffic light, “my portfolio.” Every lesson made the user look at a real Compass view and answer questions about it. By the end, they hadn’t learned about the Compass; they had used the Compass start to finish, and the certificate said they now knew how to read it.
The scaffolding was deliberately that of a training program, not a product announcement, and every piece was placed on purpose. The exam turned “looking at the dashboard” into a goal with a threshold to clear. The certificate turned the effort into an achievement with a name. Notifications reminded people who were falling behind and congratulated people who finished. The certification funnel and the adoption funnel were, by design, the same funnel.
The certificate as a portable signal
The certificate, in particular, wasn’t decorative. It was a portable signal: it left the portal, it lived on the person’s LinkedIn profile, it represented them in front of people who would never open the Compass. That portability is exactly what the internal email lacked: it gave people a reason to want the outcome, not just tolerate the process. The email asked for a favor; the course offered an asset.
The second-order effect: the point
What changed wasn’t tool usage. That was the first-order effect, the expected one. The important one was the second.
Getting trained stopped reading as “I admit I don’t know this” and started reading as “I leveled up.” The certificate (the same old learning, now wrapped in a different frame) turned a gap into a showable achievement. People posted it to LinkedIn. An act that used to cost status started producing it. That’s the full inversion: I didn’t lower the cost of adopting the tool, I flipped its sign.
When the tool went from suspect to referee
And behind that individual status shift came the one I’d been chasing without knowing how to name it. The tool became the reference. Before, defending a figure was a recurring exercise: someone would question it in a meeting and the data unit would spend half an hour reconstructing where it came from. After, the shape of the conversation changed. The question stopped being “where did you get that number?” and became “what does the Compass say?” When someone disputed a figure, the tool was the referee, no longer the suspect. The data stopped needing a lawyer.
The fight for the data unit’s credibility, the one fought number by number, cooled down on its own. Not because the numbers got better; they were the same numbers. Because the organization now used them from a different place.
That’s the point of the whole story, and it’s worth saying plainly: I didn’t build a better tool, I built the conditions for people to trust the one that already existed. The Commercial Compass already decomposed every revenue deviation by Shapley value and already reconciled the four business units against the corporate total; the problem was never there. What was missing was a status reason to open it, and that reason came from an internal business school whose Level 1 course walked people through the tool view by view and ended in a certificate they could post on LinkedIn. The certification funnel and the adoption funnel were, by design, the same funnel. A data unit’s authority isn’t earned by being right, which is a necessary and notoriously insufficient condition. It’s earned when the organization adopts your numbers as its own.
Four lenses on the same fact
This is the first installment of a series. The next ones take the same story apart from three different disciplines, because the episode says different things depending on where you stand to look at it.
- Engineering. How that persuasion was actually built: the exam with server-side burned attempts, the idempotent certificate, the notification pipeline that only bothers people who are falling behind. Behavior was designed the way you design a system, not the way you draft an email. (Next installment.)
- The organization. What this episode reveals about how an institution decides which conduct is “initiative” and which is “skipping the process”: the same act, two labels, depending on who benefits and whether it worked.
- The career. What it says about running a career on building evidence before consensus exists, and where that move stops being a useful prototype and starts being governance debt.
Three angles, one spine: adoption isn’t deployed, it’s designed. Building the tool was the easy part.