The expertise tax
On the slow conversion of builders into explainers, and what we’re doing about it.
I shipped a feature on a Tuesday this spring. By the following Friday I had explained it eleven times — to a new hire, to two customers, to a seller who needed it for a call that afternoon, to a partner’s engineer over email. Never twice to the same person, and never quite the same way, because each of them needed a different piece of it.
None of those conversations was a waste, and that is exactly what makes the problem slippery. Each one was a good use of somebody’s time: a person who needed real product knowledge got it from the person who had it. The waste only shows up in aggregate, when you count what the sum of those conversations displaced — which, for me, was most of that week’s actual building.
If you are the founder, the product manager, or the product leader who has been there longest, you know the pattern, because you are the person the rest of the company is built to ask. Salespeople want the value story for tomorrow’s call, straight from the source. Marketers want the messaging checked against what actually shipped. Sales engineers want the honest edges of a capability before they promise it to a technical buyer. New hires want all of it at once. None of them is wrong to ask — where else would it come from?
You became the expert by building the thing. Then explaining the thing slowly started replacing building it. I think of it as an expertise tax: the recurring cost of being the one who knows, paid in the hours you meant to spend on something else. This post is about the shape of the tax, why the standard fixes haven’t held it down, and the bet we’re making with Deputy.
The shape of the tax
It is worth being precise about which conversations are the tax, because the fixes fail when they aim at the wrong ones.
The draining questions share three properties. They recur — many people ask the same kind of thing, week after week, each convinced their version is new. They need your expertise, and your expertise keeps moving — the answer lives in your head and part of it changed last sprint, which is why a document written in March never quite has it. And you would gladly hand them off — answering enables someone else’s work, and nothing about the conversation requires that it be you, except that only you know.
“How should they set this up for a multi-site deployment?” — a sales engineer, mid-evaluation. “What happens if they’re still on the old version?” — a seller, an hour before a renewal call. “Is this how we’d describe the new workflow?” — a marketer, drafting the launch page. That register of question — how, what-if, is-it-supposed-to — is the tax. The answers take judgment, the judgment is yours, and the asker is unblocked the moment they have it.
Plenty of expert conversations don’t fit that shape, and the distinction matters. Whether to build or partner, what to ship next, how to price — those are decisions. They recur too, and they certainly need your expertise, but you would never hand them off, because making them is the part of the job you keep. The test I use: if what bothers you is that the question keeps coming back, it’s tax. If the question itself is your job, it’s yours.
Why the usual fixes slip
Every team under this tax reaches for the same four tools, roughly in order. We tried all four. Each one helps, and each one leaks.
Writing it down is the first move, and the right one — until the wiki meets its second quarter. Documentation answers the questions you had when you wrote it, and keeping it true turns out to be a job nobody actually holds. I’ve written a separate postabout why rot wins, but the short version is that knowledge changes in places documents don’t watch.
Recording it comes next: the demo video, the onboarding course, the walkthrough deck. Recordings scale beautifully and teach adequately, with one hard ceiling — they are finished the moment you make them. The recording cannot pause when the viewer is confused, cannot go deeper when the viewer is ahead, and cannot take the follow-up question, which is where the actual teaching was always going to happen.
Then a chatbot over the docs. This one is close to the right idea, and the current generation is genuinely better than the search box it replaced. But a bot over stale docs inherits the staleness, and when a question runs past what the docs contain, most of these systems answer anyway, in the same confident voice they use when they know. For questions about your own product, delivered to your own customers, that failure mode is expensive out of proportion to its frequency.
Eventually you hire for it — enablement, solutions engineering, support tiers. This works, and at some scale it is exactly right. It is also expensive, and for the first long stretch the new hires file the hard questions straight back to you, because the judgment they need takes years of context to absorb. The tax doesn’t disappear; it acquires a payroll line and a queue.
What I wanted instead
Somewhere in year two of paying this tax I wrote down what I actually wanted, and it did not read like a knowledge base. It read like a person I had trained.
As a spec: it learns the way I already teach — I record the demo or give the walkthrough I was going to give anyway, once, and that is a working start. It teaches the way people actually learn — one-on-one, at the asker’s pace, taking questions in the middle rather than at the end. It speaks only from a record I can read — every answer traces to a line in a briefing I edit and approve, which means I can read, in advance, every word it will ever say. When a question runs past that record, it asks me instead of improvising, and the question waits with me, marked pending. And every answer I send back gets folded into the record, so I never answer the same question twice.
That spec became Deputy.
The trade
The core of it is a trade. Today you teach everyone, one conversation at a time. Instead: teach one Deputy, and everyone else gets taught one-on-one — their questions, their pace, the moment they need it — while the teaching stays on the record.
In practice a Deputy teaches the way you do, just in more places at once. It gives your demo and clicks through the live product when someone asks where a setting lives. It presents your actual deck, pausing mid-slide for questions. It holds working sessions over live voice, sketching diagrams as it talks. It sits in your meetings and answers when asked, and it camps in the Slack channel where the questions were already arriving. Up close, one of those sessions looks like this:
The other half of the trade deserves plain terms: the briefing is yours to keep true. But look at what the teaching actually consists of. The demo was one you were giving anyway. The meeting was on your calendar regardless. The Slack answer took the forty seconds it always takes. Deputy drafts from all of it and proposes every change as a diff, so the one genuinely new verb in your week is approve, tapped on work it already did. The tax doesn’t go to zero; it collapses into moments that ride on things you were doing anyway, and it lands on the record, where paying it once counts.
A week with one
It’s worth making this concrete, because the arrangement sounds abstract until you watch a week of it run. Mine starts with the walkthrough I was giving a design partner anyway — the only difference is that I hit record first. By Wednesday that walkthrough has run several more times for people I never scheduled: a new account executive took it at six in the morning her time and stopped it mid-slide to ask how permissions work across workspaces; a partner’s engineer took the technical cut and spent most of the session inside the sandbox.
My own part of the week comes down to two kinds of moments. Mornings open with a diff or two to approve — yesterday it read my notes from a roadmap call and proposed striking the line that call had made stale. That is coffee-length work. And about once a day a real escalation finds me: a question past the briefing, waiting with me, answered out loud in thirty seconds on the way to lunch. Both kinds of moments used to be half-hour calls.
The strangest change is the quietest one. The questions still arrive at the same rate — salespeople before calls, marketing checking a claim before it goes on the website, a sales engineer chasing an edge case at midnight — but the answers come with citations and don’t come from me. What reaches me is only what’s genuinely new: a handful of questions a week, each of which becomes a briefing line and never comes back. I still teach constantly. The difference is that each lesson lands once, and stays taught.
What this doesn’t do
A stand-in for your expertise earns trust partly by what it declines. Deputy won’t make your decisions — build-versus-partner stays in your head, where it belongs. It won’t answer past the briefing, which means early on it says “let me check” more often than a general chatbot would; we consider that a feature and wrote up why. And it won’t replace you in the rooms where the conversation is the job — design reviews, negotiations, the calls where you are deciding rather than explaining. The aim is narrower and, I think, more honest: take the eleven explanations, keep the one that needed you.
Why a blog
Mostly because the problem is bigger than any one product, ours included. Enablement, documentation, trust in AI systems — teams are re-deriving the same lessons in parallel, and the vendors mostly publish victory laps. I’d rather write the way I’d talk to another founder: here is the pain, here is what the industry has tried, here is what we’re building and where it does and doesn’t fit. Deputy will show up where it’s relevant; this is a product blog. But if all you take from it is better language for the tax you’re paying, that’s a fine outcome.
If explaining your product has quietly become a second job, this is the job Deputy takes.
Join the waitlistWe'll let you know the moment Deputy's open to you.
Or ask the live Deputy on the landing page