The most technically rigorous work can be undermined by how it’s presented. An engineer who presents a beautifully designed migration plan to a VP using technical vocabulary, implementation details, and system architecture diagrams is often going to lose the room. Not because the work is bad, but because it’s pitched at the wrong level.

Non-technical stakeholders — product managers, finance leaders, VPs, C-suite executives — make decisions based on outcomes, risks, and tradeoffs at a business level, not at a systems level. Your job as a staff engineer is to translate between those worlds: to take something technically complex and make it comprehensible and actionable for people who don’t share your frame of reference.

This skill is harder than it sounds, and it’s one of the clearest differentiators between senior engineers and staff engineers who can operate at organizational scope.

The Core Shift: From “What” to “Why It Matters”

The central mistake engineers make when presenting to non-technical audiences is describing what they did or what they’re building, rather than why it matters to the business.

Technical frame: “We’re migrating from a monolith to microservices, which will allow independent deployability and better fault isolation.”

Business frame: “We’re making architectural changes that will allow the product team to ship features 40% faster and reduce the kind of system-wide outages we’ve had three times this year.”

Both sentences describe the same work. The first is meaningful to engineers. The second is meaningful to everyone. The technical frame makes the business impact implicit and forces the listener to infer the value. The business frame makes it explicit.

To make this shift, ask yourself for every significant piece of technical work: what does this enable, and what does it prevent? What can the business do after this is done that it couldn’t do before? What risk is reduced? What cost is avoided? These are the things your audience cares about.

Know What Your Audience Cares About

Non-technical stakeholders aren’t a monolith. Different roles care about different things, and good communication means matching your framing to your audience.

Product managers care about feature velocity, customer experience, and the technical constraints that shape the roadmap. They want to know: what does this unblock? What does it enable? How long will it take? What are the tradeoffs they need to factor into prioritization?

Finance and CFO-level stakeholders care about costs, cost reduction, and return on investment. Infrastructure changes, efficiency improvements, and reliability investments map to specific financial impact. Quantify this where you can: “This change reduces our cloud spend by $200K/year” lands far more powerfully than “This change improves our infrastructure efficiency.”

VPs and senior leadership care about strategic goals, organizational risk, and whether engineering is aligned with business direction. They want to know: is this necessary? What happens if we don’t do it? Is it the right investment of engineering resources relative to alternatives?

C-suite care about competitive advantage, major risks, and significant investments. They’re making decisions about resource allocation at a high level of abstraction. Keep communications at that level — one page, three bullets, what you need from them.

Structuring a Non-Technical Presentation

For any presentation to a non-technical audience, structure it to answer the questions they’re asking, in the order they’re asking them:

1. The problem (start here): What’s wrong or missing today? What’s the business impact of the current state? Make the problem concrete. “Our deployment process takes 4 hours and requires 3 engineers” is more compelling than “our deployment process is inefficient.”

2. Why now: Why is this the right time to address it? What’s changed? What’s the cost of waiting? This answers the unstated question: “Is this urgent enough to justify the investment?”

3. The proposed solution (high-level only): What are you going to do? Stay at the level of the outcome, not the implementation. One paragraph maximum.

4. The alternatives you considered: What else could you have done? Why are you recommending this approach? This signals you’ve thought about it rigorously.

5. What success looks like: How will we know this worked? What metrics will change? By how much? By when?

6. What you need: What decision or resource do you need from this audience? Make the ask explicit.

Quantify Impact Wherever Possible

Quantified impact is always more compelling than qualitative impact. When you say “this will improve reliability,” your audience has to estimate what that means. When you say “this reduces the probability of an outage from 3 per year to less than 1, and each outage costs us approximately $80K in lost revenue and engineer time,” the business case makes itself.

Some impact is genuinely hard to quantify — “this architectural investment creates more flexibility for future features” is a real benefit that’s difficult to attach a number to. But engineers often skip quantification even when the data exists:

  • Engineering time saved per week × loaded cost per hour = annual savings
  • Reduced incident frequency × incident cost (revenue loss + MTTR × headcount cost) = reliability ROI
  • Faster deployment × number of deployments per month × feature value → time-to-value improvement

You don’t have to be exact. An order-of-magnitude estimate (“roughly $500K/year”) is far more compelling than “significant cost savings.”

Handling Technical Questions from Non-Technical Audiences

Non-technical stakeholders sometimes ask technical questions they don’t fully understand. How you respond matters:

Translate, don’t simplify condescendingly. Answer the question they’re actually asking (usually a risk or impact question), not the technical question literally. “How long will the migration take?” is really asking “what’s the risk to our timeline?” or “when will we see the benefit?”

Name the real question behind the question. “That’s a great question — I think what you’re asking is whether this creates risk for the Q3 release. The answer is X.”

Don’t use technical vocabulary without definition. If you use a technical term, immediately explain it in plain language: “We’re containerizing the service — which means packaging it in a way that makes it much easier to scale and deploy independently.”

It’s okay to say you’ll follow up. If someone asks a highly specific technical question, “I’ll get you the specific numbers after this meeting” is better than a long improvised answer that loses the room.

Making Presentations Visual

Non-technical presentations almost always benefit from fewer words and more visual structure. Some principles:

  • One message per slide. If your slide has three points, it probably needs to be three slides.
  • Use before/after comparisons. “How things work now” vs. “how they’ll work after” is a cleaner structure than a technical description.
  • Replace architecture diagrams with impact diagrams. A diagram showing “what our system looks like” is for engineers. A diagram showing “what this change enables for the product team” is for everyone.
  • Use metrics prominently. A large number on a slide — “3× faster” or “$200K saved” — is immediately comprehensible and memorable.

The Slide You Almost Never Include

Staff engineers often include a slide (or section) that shows technical depth: the architecture, the data model, the implementation approach. The instinct is to demonstrate rigor, to show that the work has been thought through.

This slide almost always hurts your presentation with a non-technical audience. It’s visually complex, requires context the audience doesn’t have, and distracts from the business case you’re building.

If the audience is a mix of technical and non-technical, put the technical detail in an appendix. Say: “I have the technical architecture in the backup slides if anyone wants to dig in after. For now, I want to focus on the business impact.”

Rehearsal and Calibration

Before a high-stakes presentation to senior non-technical stakeholders:

  • Do a dry run with someone who matches your audience. A product manager or finance partner is better than another engineer for this.
  • Ask your dry-run audience: what were you unclear about? What were you unclear about the stakes? These are the gaps you need to fill.
  • Practice answering the hard questions: “Why now instead of later?” “What happens if we don’t do this?” “What’s the cheapest way to get most of the benefit?” If you haven’t thought through these in advance, you’ll answer them poorly under pressure.

The Relationship Between Presentation and Outcomes

The goal of presenting technical work to non-technical stakeholders is not to inform — it’s to drive decisions that enable the right outcomes. Information alone doesn’t move organizations; alignment, prioritization, and commitment do.

Staff engineers who communicate technical work effectively at the business level get their projects funded, their decisions made quickly, and their teams given the space to do the work. Engineers who present the same work at the technical level often find themselves in repeated meetings trying to re-explain, watching decisions get made without the full context, and wondering why good technical work isn’t getting the organizational support it deserves.

The presentation skill is not separate from the technical skill. It’s part of what it means to work at the scope that justifies the staff engineer title.