“Can you pull churn by customer?”

Sounds like a straightforward request. To a business leader, it may mean “I need to understand what’s going wrong before next quarter”. Or, “I have a hunch this customer is doing much better than the rest and I want to figure out why”. To an analyst, it can immediately trigger a completely different set of questions: What counts as churn? Which customer definition are we using? Are we looking at lost accounts or lost revenue, or some combination of both? What time period? What are we actually planning to do with the answer?

Both sides are valid. They’re just starting from different places.

I’ve spent a lot of my career floating around the space between these two sides. One thing I’ve noticed is that the communication breakdown between technical teams and business leaders usually isn’t because one side is incapable of communicating with the other. More often, each side is organizing the problem around the information that feels most relevant and important to them.

Technical people are trained to care deeply about how an answer was produced. Where did the data come from? What assumptions did we make? What happened to it along the way? Can we defend the result? On the other hand, business leaders are usually starting somewhere else entirely: What happened? Does it matter? What decision does this change?

That difference shows up in the way each side communicates. Technical explanations often build toward the conclusion because the logic is part of the proof. Business communication tends to want the conclusion early, because the listener needs to understand why the rest of the information deserves their attention.

Neither approach is wrong or less effective. The problem comes when we assume the person on the other side of the conversation naturally processes information the same way we do.

I have a background in business psychology. I love bringing in these concepts, particularly when it comes to boosting workplace effectiveness and communication. One that shows up constantly is the curse of knowledge: once you know something, it becomes surprisingly difficult to remember what it was like not to know it.

Technical teams run into this constantly. If you spend your day inside a data model, the relationships between systems feel obvious. If you have been debugging a problem for six hours, the fact that one table is duplicating records because of a join condition can feel like the most important part of the story.

The person sitting across from you (hopefully not for the entire six hours), may only need to know that customer counts are inflated and that it affects the forecast.

Business leaders fall into the same trap. They know the customer, the politics, the pressure behind the request, and why this quarter matters more than the last one. Because that context is obvious to them, it is easy to assume the analyst sees the same picture.

Alas! They do not.

Both sides leave information out because both sides assume the other person already has it. This is why I don’t think the solution is simply teaching technical people how to “speak business”. That framing is too one-directional. The bridge has to work both ways.

I noticed this years ago while building reports and presenting findings to stakeholders. Technical communication often follows the logic in the order it was discovered: here is the source, here is what we did to it, here are the assumptions, here is what happened, and therefore here is the conclusion.

This structure makes complete sense if your goal is rigor. It is how you prove the answer.

The business side often wants the reverse. Tell me what happened. Tell me why it matters. Tell me whether I need to act on it. If I have questions, then show me how you got there.

That did not mean removing the rigor. It meant changing the story sequence.

It also changed the way I built reports. I started stripping dashboards down to the information people actually needed to make a specific decision. I thought more about the hierarchy, cognitive load, and what somebody’s eye would land on first. I learned that a beautifully comprehensive report can still be a terrible communication tool if the audience has to hunt for the point.

Over time, I realized I was not really translating technical information into business language. I was helping both sides understand what the other needed.

One of the simplest tools technical people can borrow is BLUF: Bottom Line Up Front.

Do not start with the whole construction story. Start with the point your audience needs to know most.

Now I know where we are going. And if I want to know why, then take me into the mapping logic.

BLUF is not about dumbing things down or hiding methodology. It is simply recognizing that the order in which you discovered something is not necessarily the order in which somebody else needs to hear it.

A second useful idea is Schema Theory, which is a fancy way of saying that people understand new information by connecting it to something they already know. If you tell a business leader, “The issue is with the dimensional model and the join between these two tables,” you are asking them to step into your mental model before they understand the business consequence.

Try giving them the consequence first: “We are counting the same customers twice because two systems disagree about which account owns them”.

Now they have a frame. A 30,000—foot entry point. The technical explanation hasn’t changed, but the entry point has.

If you’re an executive or business stakeholder, one of the most useful communication habits is Audience Design: shaping your message and delivery around what the other person needs to know in order to respond well.

In this case, your audience is a technical analyst. Do not just tell them what you want to see. Tell them what you are trying to decide.

“Build me a churn dashboard” gives the analyst an artifact to make. An artifact that will break or become irrelevant as soon as you change the demand even slightly.

“We lost more renewals this quarter, and I need to know whether the problem is concentrated enough that we can intervene before next quarter” gives them a problem to solve.

This is where Commander’s Intent is also useful. The concept comes from military leadership, but the business application is straightforward: communicate the objective and the desired outcome instead of prescribing every step of the solution.

The person closest to the technical problem may know a much better way to answer your question than the one you had in mind. If you tell them exactly which dashboard, chart, field, and filter you want before they understand the purpose, you may get exactly what you asked for and still not get what you need.

That’s one of the most frustrating forms of “success”.

One more concept for you to learn today and then I promise you can go enjoy your weekend: Progressive Disclosure.

I’ve used this for years in reporting design. The idea is not to make the audience process everything at once. Give them enough information to orient themselves, then allow them to go deeper as needed.

A well-designed executive report should not force someone to read every calculation before they can understand what happened. A good technical conversation should not bury the caveats, but it also should not front-load every possible caveat or exception before the listener even understands why the conversation matters.

This is part of the reason why I have always cared so much about report design. Visual hierarchy is not decoration or an afterthought. It is communication. What you put first tells the audience what matters. What you group, emphasize, hide or defer changes how the information is processed, and ultimately, shapes the narrative.

The same is true in conversation.

There was a time when a highly technical person could be incredibly valuable while spending most of the day heads-down and relatively insulated from stakeholders. The work itself created the value.

That model is changing. If AI can help write the code, generate the first query, document the function, or produce a draft analysis (or even the entire dashboard), the technical person’s differentiator increasingly becomes the work the tool can’t do well on its own: understanding what the business is actually asking, recognizing when the answer is technically correct but practically useless, communicating uncertainty, and helping someone decide what to do next.

The irony is that as technical work becomes more automated, technical roles may become more human.

Business leaders are not off the hook. They will need to get better at explaining intent, context, and outcomes instead of throwing vague requests over the wall and expecting someone else to read their minds.

The bridge does not work if only one side crosses it.

Good communication between technical and business teams is not about forcing executives to become data engineers or asking technical people to turn every conversation into a TED Talk. It is about recognizing that the person on the other side of the table is solving a different part of the same problem.

When both sides get better at understanding what the other needs, we spend less time talking past each other and more time solving the thing we were trying to solve in the first place.

The bridge between technical work and business decisions is not a soft skill. It is becoming part of the work itself.

As producing information gets easier, the real differentiator becomes knowing what matters, why it matters, and how to make someone else understand it.