Translation runs both ways. I was only good at one.

My degrees are a business administration degree in Baku and a business analytics master’s at UC Irvine, and I ended up doing engineering work. On paper that’s the ideal resume for a translator. In practice I was fluent in exactly one direction for years and didn’t notice, because the direction I was fluent in is the one people compliment you for.

The celebrated direction is business to technical. A stakeholder says they want to know which customers are about to leave, and you turn that into a grain, a set of sources, a definition of “about to,” a model, a dashboard. Every analytics job description describes this. At the agency I interned at it was most of the work, taking what account managers wanted and turning it into reporting that could serve eight-plus accounts without being rebuilt each time. I was good at it. I liked it. It rewards curiosity and asking annoying questions, and I have a lot of both.

The other direction is technical to business, and it is barely taught at all. Something in the system makes the thing they want expensive, or slow, or partially impossible, and now you have to explain that to somebody who has no reason to care about the reason.

The tell that I was bad at it was how often people were surprised. Not upset. Surprised. Somebody would ask on a Wednesday call whether the new report was ready, and I would say it needed a few more days, and their face would do the small thing faces do when the world has failed to match the model in their head. That happened to me a lot before I understood it was data about my own performance.

Because I had explained. I had explained thoroughly. I remember a message I sent about a delay that used the word “denormalized” three separate times, plus a sentence about fan-out on a join, and the reply I got was “ok”. Lowercase, no punctuation. I read that as agreement at the time. It was not agreement. It was a polite person deciding this wasn’t their department.

What I was doing was stating a technical fact accurately and calling it communication. “We can’t join those two systems on email because the CRM lets duplicates in” is true and it lands as an excuse, because the listener has no way to convert it into anything they can decide about.

The version that works gives them the tradeoff instead of the cause. You can have it Thursday with about six percent of accounts double-counted, or the following Tuesday with them resolved properly. Which error do you want to live with? Now they have a decision that belongs to them, in units they own, and something interesting happens: they frequently pick the fast wrong one, because for their purposes six percent doesn’t change the call they were going to make. I found that genuinely irritating the first few times. It was also correct, and it was never my decision to make.

The best run I ever had at this second direction was at a capital firm, where I documented lineage, business definitions, and the logic behind each KPI, then sat with people and taught them how to answer their own questions. Self-service went up around 60% within six months. Looking back, none of that was a documentation project. It was translation done at scale and in advance: instead of explaining the warehouse to one person per interruption, I explained each number once, in their vocabulary, in the place they’d be standing when they needed it. I’ve written more about why documentation only gets read at one specific moment, which is the same idea from a different angle.

Standardizing KPIs across Product and Growth at my last job taught me the harder version. Building the dbt models that produced one shared set of definitions was a couple of days of work. Getting agreement on what the definitions should be took much longer, because Product and Growth each had a definition of an active user and each was right for what they used it for. There was no technical argument to win there. The only useful move was explaining to each of them what they’d give up under the other’s definition, precisely enough that they could weigh it themselves.

I still catch myself doing the old thing. Someone asks why a number moved and I start with the upstream schema change, because that’s where my attention has been all morning, and I watch their eyes go somewhere else while I’m still on the second sentence. The repair is to start with what it costs them and stop there unless they ask.

Nobody schedules a meeting to tell you your estimate made sense. The only feedback the return trip ever gives you is an absence of surprised faces, which is a hard thing to put on a resume and a harder thing to feel proud of on a Friday.