Skill.re
Using AI for Stakeholder Communication and Executive Briefings
The Communication Gap That Kills Projects
A VP of Engineering at a healthcare startup spent 45 minutes briefing the board on a critical security vulnerability. He showed architecture diagrams, traced the exploit path, explained the database schema implications. When he finished, the lead director asked: "So... should we be worried?" The room went silent.
He'd given a brilliant technical briefing. But the board needed a risk assessment. They needed to know: What's our exposure? How likely is this to be exploited? What happens if we get breached? What does it cost to fix? What happens if we don't fix it? He'd answered all the technical how-questions. Nobody cared. They needed the so-what.
This is the central problem in technical leadership: good technical work doesn't matter if the people making decisions don't understand why it matters. A CTO can architect a beautiful system. If the CFO doesn't understand the ROI, it doesn't get funded. An engineer can identify a critical performance bottleneck. If the CEO doesn't understand the business impact, it gets deprioritized. You can have the best idea in the room. If you can't translate it to someone else's language, it dies.
This lesson teaches you how to bridge that gap. Not by dumbing things down. By translating. By understanding that your CFO speaks cost-benefit language. Your CEO speaks strategy language. Your customers speak value language. Your board speaks governance language. The same technical fact needs to become different information for different brains.
AI becomes your translation partner. It helps you see the different dimensions of a problem. It helps you draft versions for different audiences. It helps you anticipate what each stakeholder will care about. Most importantly: it forces you to think clearly about what you're actually trying to communicate.
Why Engineers Fail at Stakeholder Communication
Engineers are trained to be precise. To handle complexity. To think in systems. This makes you great at building things. It makes you terrible at explaining things to people who aren't engineers.
You know what "technical debt" means. You can picture the exact place in the code that's a problem. You know the refactoring effort. You understand why it matters architecturally. To the CFO, "technical debt" means nothing. It's not on any balance sheet. To the CEO, it's a future risk, but how big? To the VP of Product, it's a question: "Will this slow us down?"
When you say "We need to migrate to microservices," you mean something very specific: decoupling monolithic architecture, enabling independent scaling, creating clear service boundaries, reducing deployment risk, improving fault isolation. The CFO hears: "This is a big expensive project." The VP of Product hears: "Will this slow down features?" The CEO hears: "Are we falling behind architecturally?"
The problem isn't that you're wrong. It's that everyone is asking different questions and you're answering in engineering language instead of their language. You end up talking past each other.
The SCQA Framework: Structure for Clarity
There's a proven structure used by strategy consultants, McKinsey, top communicators: SCQA. It works because it matches how human brains process information.
Situation: Here's the context. What's true about the world right now?
Complication: But here's what changed. Here's the problem that matters.
Question: So now we're faced with a choice or decision.
Answer: Here's what we should do about it.
This structure is powerful because it mirrors how decision-makers think. They want context first (don't confuse them). They want to know why you're bringing this up now (what changed?). They want to understand the decision point (what are we choosing?). Then they want your recommendation (what should we do?).
Compare these two approaches to the same issue:
The Engineering Pitch: "Our database is 85% CPU utilization under peak load. Queries are taking 200ms on average. We're sharding data across 12 instances. To handle next year's volume, we need to either add more instances or optimize query patterns. I recommend a three-month refactoring project to add appropriate indexes and denormalize high-frequency queries."
The SCQA Pitch: "We're growing 30% year-over-year. (Situation) Right now our database hits 85% CPU at peak hours, and latency impacts customer experience. (Complication) If we grow as projected, we'll run out of capacity in 6 months. We can solve this two ways: add more infrastructure ($400K annually) or optimize queries (3 months, engineering time). (Question) I recommend the optimization first. (Answer)"
The SCQA version takes a listener through the logic. By the time you suggest the optimization project, they understand why. They understand the timing. They understand the alternative. They can make an informed decision.
AI can help you structure SCQA pitches. You give it the technical facts. It helps you organize them into this pattern. It forces clarity.
The Translation Matrix: Same Fact, Four Languages
Here's a concrete framework for translating across audiences. Take any technical fact. Translate it four ways:
Fact: "We reduced API response time from 500ms to 100ms through query optimization."
For the CFO: "API optimization postpones a $600K infrastructure expansion by 18 months. New servers aren't needed until late next year instead of Q2. ROI: $600K saved in capital expenditure."
For the VP of Product: "Pages that depended on that API now load 4x faster. This directly improves user experience for dashboard and reporting features. We expect this to reduce customer complaints about slowness by 40%, freeing the support team from firefighting."
For the CEO: "We're now faster than competitors on a key user experience metric. This is a competitive advantage we can highlight in sales and improves customer satisfaction during critical onboarding experiences."
For Customers (in release notes): "Your dashboards and reports load much faster. Operations that used to take 30 seconds now take 6 seconds."
Same work. Four completely different stories. The CFO cares about capital efficiency. Product cares about customer satisfaction. The CEO cares about competitive positioning. Customers care about what changes for them. Each one is true. Each one is the same underlying work translated into a different stakeholder's priorities.
The Translation Matrix Exercise: Take your next major project. Write one sentence about it in engineering terms. Then translate it to: CFO language (cost/ROI), CEO language (strategy/competition), Product language (customer value), Customer language (what changes for me). You'll discover you don't fully understand the business impact until you translate. Use AI to draft translations, then refine them with your own judgment about what truly matters.
This translation matrix isn't dishonest. You're not changing the facts. You're connecting the same facts to what each stakeholder cares about. This is leadership.
The Case Study That Failed: Boeing 737 MAX Communication Breakdown
Boeing's 737 MAX is one of the clearest examples of how communication failure cascades into catastrophe. The technical problem: a new flight control system (MCAS) that could, under specific conditions, override pilot inputs. The engineering team understood the risk. But communication broke down across three critical boundaries.
Engineering to Management: Engineers flagged the risk. Management didn't allocate resources to fully test and document it. The message didn't translate to "this is a show-stopper." It sounded like "this needs work," which is always true. Result: the risk wasn't treated as critical.
Boeing to Regulators: Boeing didn't clearly communicate the scope of the system change to the FAA. Pilots weren't trained on MCAS because Boeing claimed it was a minor tweak. The communication was technically accurate but omitted the context that made it matter: this system, in these specific flight modes, could override experienced pilots. Result: regulators didn't require the training or testing that might have caught the failure mode.
Boeing to Customers: Airlines and pilots weren't clearly informed about the system or its failure modes. When incidents happened, the message was opaque. Result: confusion when crashes occurred, because nobody fully understood what the system did or could do.
Two crashes. 346 deaths. The technical issue was real but could have been managed. The communication failures meant the issue wasn't treated with the seriousness it deserved until it was too late. The lesson: when you have something important to communicate, your job is to make sure the listener understands not just what you said, but why it matters and what they should do about it.
In the Boeing case, each communication failure sounded like a minor information gap. "Didn't mention MCAS in training materials" sounds small. But that gap meant pilots didn't know what to do when the system misbehaved. "Didn't emphasize the override capability" sounds like a detail. But that detail would have changed regulatory testing requirements. "Treated the engineer concern as process feedback, not a critical issue" sounds like normal management. But that normal process meant a critical flaw got treated like routine technical work.
Your job: make sure your critical messages don't get lost in gaps.
How Amazon, Stripe, and Netflix Communicate
Three companies known for technical excellence also known for communication excellence:
Amazon: Jeff Bezos famously banned PowerPoint in favor of narrative memos. The six-page memo format forces clarity. You can't hide behind pretty slides. If you can't explain your idea in six pages for someone else to read in 20 minutes, the idea isn't clear enough. Amazon requires SCQA structure: the memo opens with situation and complication, poses a decision, then makes a recommendation. This forces engineers to think through not just the what, but the why and the so-what.
Stripe: Built a writing-first culture from the start. Documents, design specs, architecture proposals: all written prose. Not because writing is prettier. Because writing forces precision. When you write something down, you can't wave your hands and hope people understand. You have to be clear. Stripe credits this discipline to hiring stronger technical talent who can both code and explain their thinking. It's become a competitive advantage in recruiting.
Netflix: Pioneered the "context, not control" management philosophy, which is really a communication philosophy. Instead of telling people what to do, leaders describe the context, the decision criteria, the constraints, and let teams decide. This only works if the context is crystal clear. Netflix puts enormous effort into communication because if people don't understand the context, the whole system falls apart. A famous quote from Reed Hastings: "Most companies spy on their employees. We tell them the truth."
All three companies solved the same problem: how do you scale expertise? By making sure people understand not just what to do, but why it matters. This only happens with clear communication.
Audience Analysis Framework: Know Who You're Talking To
Before you communicate anything, you need to answer four questions about your audience:
1. What is their primary responsibility? CFO owns the P&L. VP of Product owns the roadmap and customer value. CEO owns competitive position and company survival. Board owns governance and shareholder value. This drives what they care about.
2. What decision do they need to make? Do they need to approve budget? Change timeline? Increase headcount? Accept risk? Different decisions require different information. Someone deciding on a $2M budget investment needs different information than someone being informed after the fact.
3. What will they worry about? The CFO will worry about ROI and hidden costs. The VP of Product will worry about timeline and feature velocity. The CEO will worry about competitive impact and execution risk. The board will worry about governance and disclosure. Meet them where they are.
4. What do they already know? Don't explain what they know. Fill in gaps. If you're talking to a CFO about infrastructure spend, don't explain what infrastructure is. Explain why this specific infrastructure choice is better than the alternative. If you're talking to a board, don't explain microservices. Explain why the architecture matters to the company's ability to scale.
Use these four questions to frame every stakeholder communication. It changes what you emphasize, what you explain, what you leave out.
Practical Communication Structures: What Works When
The Executive Summary (1-2 pages, 5 minutes to read): Used when the decision-maker is pressed for time. Structure: Hook (why now?), Context (what's the situation?), The Ask (what do you need?), Impact (what changes if you say yes?), Timeline (when?). Every sentence should advance one of these. Nothing else belongs.
The Board Memo (3-4 pages, 10-15 minutes to read): Used when you need approval or want boards to understand a major decision. Structure: Situation (state of the business), Complication (what changed), Decision (what are we choosing), Recommendation (what we propose), Risks (what could go wrong), Supporting facts (appendix). Board memos assume the reader is smart but not technical.
The Technical Deep Dive (10+ pages, 30+ minutes): Used to support the decisions made in memo form. Includes architecture, tradeoffs, implementation details. Usually read only by people who need to understand the how. But it should still open with why. Start technical documents with the SCQA: what problem are we solving, why now, what are the choices, what do we recommend?
The Customer Communication (1 email or page): What changes for them? When? Why is this good? Don't explain the technical details unless they directly affect the customer. Focus on outcome. "Pages load faster" not "we optimized database queries."
Each structure serves a purpose. The mistake engineers make: using the technical deep dive structure when a memo would work, then wondering why executives didn't read it.
The Wrong Audience Syndrome: You write a 20-page technical document for the executive team. They skim the first page, see technical details, and delegate. By the time your work reaches the people with authority to decide, context is lost. Rule: Match your communication structure to your audience's needs, not to how detailed your work is. The more detailed your work, the more important it is to front-load the summary.
AI as a Drafting Partner: Not a Template Machine
The wrong way to use AI for stakeholder communication: dump your technical work into a prompt, get AI to generate slides, send it. You'll get something that sounds professional and means nothing to anyone.
The right way: use AI as a thinking partner. Talk through what you're trying to communicate. Ask AI to find the gaps in your logic. Use AI to draft multiple versions and pick the strongest. Edit ruthlessly. Make sure it sounds like you.
Here's how this works in practice:
First pass (you to AI): "I need to brief the CEO on why we should move from monolithic to microservices architecture. Here's what I know: [your facts]. What am I missing? What would the CEO actually care about?"
AI might respond: "You have the technical benefits. You're missing: (1) what this enables competitively that we can't do now, (2) the timeline costs during transition, (3) how this affects hiring and team structure."
Second pass (you to AI): "Help me think through competitive angle. How does microservices architecture give us a product advantage over our competitors?"
AI might respond: "Faster iteration on independent services. Easier to scale specific parts. Easier to experiment. Can move faster than a monolithic competitor. But [competitor] might not be monolithic. What's your actual advantage?"
This is useful. You're not getting an answer. You're getting pushed to think clearly about whether you have an advantage or you're just doing modernization because it's sexy.
Third pass (you to AI): "Draft a 1-page brief to the CEO. The real advantage is that we can iterate on specific features (like payment flows) without touching the core platform. This matters because [your answer]. Timeline: 9 months, $1.5M, with reduced velocity for 4 months then 30% faster iteration. Risks: [your risks]."
AI drafts something. You read it, think "that's not quite right," mark it up. Maybe it emphasizes the wrong thing. Maybe it misses a key risk. Maybe it makes an assumption you don't agree with. You correct it. You iterate.
By the end, you have something that's both clear and true. The AI helped you think. But your judgment shaped what it became. This is the right use of AI.
The wrong use: "Write a CEO brief about microservices." You take what AI generates and send it. You haven't thought it through. You're guessing it makes sense. It probably doesn't.
Anticipating the Questions They'll Ask
Before you present anything important, you should know what questions you'll get. Not all questions. But the obvious ones that should have answers ready.
The framework: for each stakeholder, ask yourself: "What would I worry about if I were in their position?"
For the CFO on a $2M engineering investment:
- Why now? Why not next year? (Competitive, scaling, talent retention?)
- $2M seems high. Could we scope it differently?
- What if it takes longer than planned?
- How do we measure success?
- What's the impact on other projects?
For the CEO on a technical decision:
- Does this help us win in the market?
- Are competitors ahead or behind on this?
- What's the risk if we don't do it?
- What's the risk if we do it and it goes wrong?
- How does this affect our ability to ship customer features?
For the Board on a major company decision:
- How is this being governed? Who's overseeing it?
- What's our downside exposure?
- Is there disclosure to investors?
- What would a competitor do here?
- If this fails, what's the impact to the business?
Have answers ready for these questions before you present. Not defensive answers. Clear, factual answers. You'll feel more confident. And when someone asks, you won't hesitate. You'll show that you've thought it through.
Communicating Bad News and Tradeoffs: The Structure That Works
Sometimes your message is bad. A project is delayed. We missed targets. We have a tradeoff. You can't make it good. But you can make it clear and honest. This structure works:
1. Name the situation directly. "Our system reliability initiative will miss the March deadline. We'll deliver in June instead."
2. Explain why without defensiveness. "We underestimated the complexity of migrating legacy systems. The scope is larger than our initial estimates."
3. Show you have a plan. "Here's what we're doing about it: [specific actions]. This adds 3 months but de-risks the project."
4. Name the impact on them specifically. "For the board: this affects shareholder communication timeline. For Product: this delays the reliability SLA we promised customers. For Finance: this extends the budget cycle by one quarter."
5. Give them options if they have choices. "We can cut scope to hit March (but reliability gains are smaller). We can add resources to accelerate (but adds $300K cost). We can hit June with full scope. What's your preference?"
This structure works because you're giving people facts, you're acknowledging the impact on them, and you're showing you have options. You're not asking them to feel bad for you. You're asking them to make an informed decision about tradeoffs.
The mistake engineers make: burying bad news. "We'll probably need a bit more time on the reliability work." That sounds like casual estimation. It makes people think you're not serious. Be direct: "This will miss the deadline." Then explain and offer options.
Translating Metrics to Meaning: Why Numbers Without Context Are Useless
You have metrics. Executives need meaning. "Database response time improved 4x" means nothing to anyone outside your team. "Response time improved from 500ms to 125ms" still means nothing. "Features that used to take 30 seconds now take 8 seconds, improving user experience noticeably" starts to mean something. "This cuts the time to complete critical operations by 73%, directly impacting customer satisfaction scores and reducing support tickets by 22%" means something specific.
The translation path: metric → impact on user experience → impact on business metric → impact on decision.
Example 1: Infrastructure
- Metric: "Reduced CPU utilization from 85% to 40%."
- User impact: "Peak hours are no longer slow."
- Business impact: "Postpones $600K infrastructure spend by 18 months."
- Decision impact: "Saves capital in next year's budget cycle. Lets us reinvest in products instead."
Example 2: Deployment
- Metric: "Reduced deployment time from 30 minutes to 5 minutes."
- User impact: "Bugfixes ship faster."
- Business impact: "Mean-time-to-resolution for incidents drops from 90 minutes to 40 minutes."
- Decision impact: "Significantly improves customer experience during incidents. Reduces SLA breach risk. Improves competitive positioning on reliability."
Example 3: Code Quality
- Metric: "Refactored payment module from 15K lines to 4K lines."
- User impact: "Payment flows more reliable."
- Business impact: "Adding new payment methods now takes 1 week instead of 3 weeks."
- Decision impact: "Dramatically increases our ability to support customer requests for new payment options. Competitive advantage in enterprise sales where payment flexibility matters."
Every metric should travel that path. If it doesn't, the metric doesn't matter to the decision-maker. You might care about CPU utilization. They care about what it means.
What to Do Monday Morning: Verb-Starting Action Items
Map the stakeholder landscape for your next big initiative. Who needs to understand what? In what order? What's each person's decision or buy-in? Write it down. This changes how you communicate.
Take one metric from your work that matters (uptime, performance, cost). Translate it four ways: what it means for users, what it means for the business, what it means for the CEO, what it means for the board. This forces you to see the dimensions of your work.
Draft a one-page summary of your next project using SCQA: Situation, Complication, Question, Answer. Have an executive read it cold. Ask: "Do you understand what we're doing and why?" If not, your structure needs work.
Before your next important meeting, predict three questions the audience will ask. Write one-sentence answers. Practice saying them out loud. This is confidence-building and forces clarity.
Record yourself briefing a peer on a technical decision. Play it back. Did you explain the why before the what? Did you connect the technical to the business? Did you name the impact on them? Edit and try again. This feels awkward. It builds the skill faster than anything else.
Frequently Asked Questions
Q: Isn't emphasizing different things for different audiences just telling them what they want to hear?
No. It's professional communication. A surgeon explaining a procedure to a patient emphasizes different things than when explaining to an insurance company, but both conversations are honest. The patient cares about recovery time and side effects. Insurance cares about cost and necessity. The surgery is the same. The explanation matches the listener's actual decision point. This is translation, not deception.
Q: What if I genuinely don't know what will matter to a stakeholder? How do I figure that out?
Ask them. Before the big meeting, schedule 15 minutes: "I want to brief you on X. What's your main concern? What would help you make a decision?" You'll learn what they care about. Most people are happy to tell you. This singles conversation saves hours of miscommunication. And it shows them you care about their decision, not just pitching your idea.
Q: Should I always use AI to draft stakeholder communications?
Use it to challenge your thinking and draft options. Not as a ghostwriter. Read everything AI drafts. Does it sound like you? Did it catch something important you missed? Is it honest? If AI generates something and you wouldn't feel comfortable saying it in person, don't send it. The communication has to feel authentic.
Q: What if the stakeholder's concerns are legitimate but solving them would mean changing the project?
Listen. The best technical decisions aren't made by engineers in isolation. If a CFO says "your timeline adds $500K to my budget and that's not feasible," that's not a problem with your communication. That's a real constraint you need to work with. You adjust the proposal to the constraint. "OK, here's how we do it in 6 months instead of 9 at $250K cost." This is leadership, not getting your way, but solving the real problem.
Q: How do I communicate technical limitations without sounding like I'm making excuses?
Name the limitation, explain why it exists, offer what you can do instead. "We can't hit that performance target because the underlying database isn't designed for that query pattern. What we can do: hit 90% of the target in 2 months, or hit full target in 4 months if we redesign the schema. What's the tradeoff you prefer?" You're not making excuses. You're being honest about constraints and offering options.
Q: What if I present something and the stakeholder asks a question I genuinely don't know the answer to?
"That's a great question. I don't have the answer right now. Can I get back to you by [date]?" Then get back to them. This is stronger than guessing. You show you take their question seriously. You follow up. They respect that more than a confident wrong answer. And you learn something about what matters to them.