Research Report: Why Most Tech Professionals Are Terrible Communicators

Video

Source: Why Most Tech Professionals Are Terrible Communicators by A Life Engineered

Executive Summary

Technical professionals often stall in their careers not because of skill gaps, but because of a single communication habit: they explain in the order they experienced things rather than the order their audience needs them. They build up to the point. They provide more context than the listener requires. They start explanations from the beginning rather than from shared understanding. The result is that even technically excellent engineers become hard to follow, easy to ignore, and difficult to promote.

The video presents three complementary techniques for fixing this. The first — Bottom Line Upfront, or BLUF — is about order: say your conclusion first and let supporting detail follow only if asked. The second — just-in-time context — is about volume: give people exactly the information they need to do their immediate task, not everything you know about the subject. The third — the Zoom-in — is about depth: when you do need to explain complex material, start where the listener already is and go one layer deeper at a time instead of rebuilding the entire foundation.

The author spent nearly 20 years at Amazon, reaching principal engineer, and has since coached thousands of engineers on these exact patterns. The techniques are not communication theory — they are field-tested frameworks for closing the gap between what you say and what your audience actually understands.

Key Takeaways

• Career growth is blocked by communication, not technical skill. The pattern is consistent: engineers who can't get traction in leadership roles are often communicating bottom-up when their audiences need top-down.
• BLUF (Bottom Line Upfront): State your conclusion first. Everything that supports it comes after — and only if asked. Most people do the opposite because chronological order feels natural to the person who lived through the problem. It is not natural to the person who needs the answer.
• The audience doesn't need your journey; they need your destination. When a VP asks why features are slow, they want the answer in the first sentence, not after a two-minute build-up through data, investigation, and team conversations.
• Just-in-time context: Give people exactly what they need to do their immediate task — not a complete picture of your knowledge. A complete explanation and a useful explanation are almost never the same thing. Ask: "What does this person need to do with this information?" Let that filter everything you say.
• The Zoom-in: When depth is genuinely required, start from what the listener already knows, then go one layer deeper at a time. Three or four "zooms" typically get someone from zero to a working mental model without overwhelming them or dumbing anything down.
• These techniques compound. BLUF fixes order. Just-in-time context fixes volume. The Zoom-in fixes depth. Used together, they make complex technical communication feel easy to follow — not because the material is simplified, but because the direction is consistently top-down.

Detailed Analysis

Why Bottom-Up Communication Fails

Technical professionals default to chronological explanation because it mirrors their own experience of a problem. You encountered the issue, you investigated it, you reached a conclusion. Explaining it in that sequence feels natural and complete. But your audience does not need your experience of the problem — they need your output.

The video uses a VP asking why feature delivery has slowed as the running example. The bottom-up answer starts with accumulated technical debt, moves to a two-year history of shortcuts, eventually arrives at the authentication module, and concludes with the actual recommendation. By the time the recommendation arrives, the VP has been holding unconnected pieces of information without knowing where they lead. The result: the VP asks the same question again.

The failure is structural, not just stylistic. When you build up to a conclusion, you are asking the listener to hold your entire reasoning chain in working memory while waiting for the point. Most people cannot or will not do this. They interrupt, zone out, or walk away without the answer you spent three minutes delivering.

Technique 1: BLUF (Bottom Line Upfront)

BLUF inverts the structure. The recommendation or conclusion goes first. Supporting detail follows — but only because the audience now knows what it supports and can decide whether they want more.

The BLUF version of the VP example: "Feature delivery has slowed because we've accumulated too much technical debt, especially in the authentication module. We need about six weeks of dedicated cleanup to get velocity back to where it was. I'd like to propose pausing one feature track next quarter to make that happen." The VP now has the answer in the first sentence. If they push back — "Why six weeks? What's wrong with authentication?" — the conversation that follows is on their terms. They are asking for detail they have chosen to seek, which means they are primed to receive it. The same details that got lost in the bottom-up version will now land.

The practical exercise: in your next email, put your ask or your conclusion as the very first sentence. It will feel abrupt at first. It is not.

Technique 2: Just-in-Time Context

The second mistake happens even after people learn BLUF. They lead with the answer but then bury the audience in context they don't need.

The instinct behind over-explanation is reasonable: leaving things out feels sloppy when you understand a subject deeply. You know the subtlety. You know the edge cases. Including them feels responsible. But a complete explanation and a useful explanation are almost never the same thing. The person you are talking to is not trying to reach your level of understanding — they are trying to do something. Make a decision. Move on to the next step.

The test is one question: "What does this person need to do with this information?" Write it down if you have to: "The thing this person needs to do with this information is ____." Then let that sentence filter everything you say. If a piece of context doesn't serve that specific need, leave it out.

The video illustrates this with a product manager asking about technical debt before a planning meeting. The over-explained version gives a full taxonomy: deliberate debt, accidental debt, bit rot — with examples of each across three different systems. The PM does not need a taxonomy. They need to know what to say in a planning meeting. The just-in-time version gives them that: the shortcuts over the past two years are slowing delivery, the authentication module is the biggest problem, and fixing it properly is now a multi-month project for features that should take weeks. Same knowledge, different filter.

Technique 3: The Zoom-In

When depth is genuinely required, the Zoom-in is how you get there without losing people. The concern that cutting context means dumbing things down is addressed by the technique itself: you do not simplify the material, you change where you start.

The structure: start from something the listener already knows, go one layer deeper, break that layer into a small number of categories, pick the one that matters for this conversation, and go deeper into just that one. Repeat until they have enough.

The video's clearest example uses tensors. The mathematically correct definition ("a tensor is the tensor product of several vectors and co-vectors") is precise but useless for a front-end engineer moving onto an ML features team who needs to read PyTorch documentation by next week. Three zooms get them there: a vector is a list of numbers → a matrix is vectors stacked together, two dimensions like a spreadsheet → a tensor is what happens when you keep going, adding more dimensions, a container for numbers with any number of dimensions. That is enough to read the docs and write code. The formal mathematical definition is still true. It is just not what they need right now.

Applied to the technical debt example: velocity dropped because of accumulated tech debt (zoom) → the debt sits in three systems, authentication is the one hurting us (zoom) → authentication was a temporary prototype built three years ago, six services depend on it now, so any change requires coordinating all six (zoom). Three zooms. New engineering manager now has enough to make decisions. Starting from shared understanding and going one layer deeper each time — not rebuilding from the beginning.

The Structural Principle Behind All Three Techniques

The three techniques share a common underlying logic: communicate in the direction people listen, not in the direction problems develop. Problems unfold bottom-up — from symptoms to root causes, from evidence to conclusions. Communication should flow top-down — from conclusions to evidence, from answers to context, from shared ground to new depth.

BLUF fixes order. Just-in-time context fixes volume. The Zoom-in fixes depth. Used together, the result is communication that feels easy to follow — not because the material has been simplified, but because the structure matches how the listener actually processes information. As the author notes: the video itself was structured using all three techniques. If it felt easy to follow, that was why.

Timestamped Topic Outline

Sources & Further Reading

• No external sources were explicitly referenced in this video. The frameworks (BLUF, just-in-time context, Zoom-in) are original frameworks developed and taught by the author through his coaching practice.
• A Life Engineered coaching program: The author coaches tech professionals on communication, visibility, and promotion. Referenced in the video with a link in the description.
• Notion custom agents: The author briefly demonstrates a custom Notion agent he built to analyze newsletter data and suggest topics — referenced as a practical example of just-in-time information delivery, not central to the video's main argument.