Tailoring the Pitch: How to Speak to Execs vs. Engineers vs. Support
You just finished a major project. The "Logout" button on the mobile app was intermittent, and you finally fixed it by refactoring the auth middleware.
Now you have to tell the company. You send a Slack message to the #general channel: "Refactored the auth middleware to address race conditions in the session handler. Logout issues resolved."
To you, this is perfect. It's accurate. It's concise. But here's what happens on the other end:
The CEO wonders why you spent three days "refactoring" instead of shipping the new checkout feature.
The Support Lead doesn't know if this fixes the ticket from 45 minutes ago or if they should keep telling users to "restart the app."
The Senior Engineer wonders if you handled the edge case for OAuth tokens during the refactor.
The same information, received by three different people, creates three different gaps. This is the "Just Say What Happened" trap. In a cross-functional organization, accuracy is only half the battle. The other half is resonance.
1. Why "just saying what happened" fails in cross-functional orgs
In the early days of your career, you are rewarded for technical accuracy. In a coding bootcamp or a junior role, if the code works and you can explain how it works, you've succeeded. You are speaking to people who share your context: your instructors or your immediate peers. You are all looking at the same small slice of the world, and your language reflects that shared focus on implementation.
But as you move into senior roles, your primary job shifts from "doing the thing" to "ensuring the thing has the intended impact." Impact is subjective. To a CFO, impact is a number on a spreadsheet—specifically, how much money was saved or how much revenue was unlocked. To a Designer, impact is a smoother transition or a more intuitive user flow. To a Customer Success Manager, impact is fewer angry emails on a Friday afternoon and a higher Net Promoter Score.
When you fail to tailor your pitch, you are essentially asking your audience to do your job for you. You are handing them a bucket of raw data—the "what happened"—and expecting them to extract the value themselves. But executives are busy, engineers are focused on their own sprints, and support reps are already overwhelmed by the queue. If you make them work to understand your value, they eventually stop trying.
The Communication Silo: Most professionals communicate in the "dialect" of their own department. When you speak your department's dialect to someone outside of it, you aren't just being "technical"—you're being opaque. You are forcing the listener to do the work of translating your output into their value system. This creates friction, slows down decision-making, and ultimately makes you less visible to leadership.
The most effective people in any company—the PMs who get every resource they ask for, the EMs who are universally respected, the Ops leads who seem to know everything—all have one thing in common: they are multilingual. They don't just "send updates." They "frame outcomes." They understand that the goal of communication isn't just to be accurate; it's to be effective. Effective communication is the shortest path between a thought in your head and a desired action in theirs.
2. The three audiences: what each one actually needs from you
To communicate effectively, you have to stop thinking about what you did and start thinking about what they need. It's a mindset shift from "What's in my head?" to "What's in their world?" Every department has its own "currency"—the metrics and outcomes that determine their success. If you don't speak their currency, your message will feel like a tax on their time.
The Executive
Primary Focus: Strategic Impact & Risk"Executives care about the "What" and the "So What." They are managing a portfolio of projects and need to know if yours is on track to deliver its business value."
Outcome
What happened or will happen?
Risk
What could stop it?
Decision
What do you need from me?
The The Executive's Currency: Growth, efficiency, and risk mitigation. They are looking at the health of the entire business unit.
The Engineer
Primary Focus: Implementation & Constraints"Engineers care about the "How" and the "Why." They need to understand the logic, the architecture, and the technical debt being incurred."
Constraint
What are the technical limits?
Approach
How are we solving it?
Trade-offs
What did we give up?
The The Engineer's Currency: Stability, scalability, and code quality. They are looking at the health and maintainability of the technical stack.
The Support Rep
Primary Focus: User Impact & Logistics"Support teams care about the "Who" and the "When." They are the front line and need to know exactly what to tell a frustrated user at 2 PM on a Tuesday."
Customer Impact
Who is affected?
Timing
When is it changing?
Contact
Who do I ping for help?
The The Support Rep's Currency: Resolution time, user sentiment, and documentation. They are looking at the daily friction points for our customers.
When you understand these profiles, you realize that a single update cannot serve all three effectively. If you include the technical constraints for the executive, you lose them in the weeds. If you focus only on customer impact for the engineer, they'll feel you're "hand-waving" the hard work of the implementation. The key is to have the same "truth" but different resolutions.
3. A worked example: one project update, three versions
Let's look at a real-world scenario. Your team just finished migrating the primary database from a legacy instance to a modern cloud-native one. It took two months, involved three "all-hands" weekend shifts, and resulted in a 30% reduction in query latency.
The Executive Version
"We successfully completed the database migration this morning. We are now running on the new architecture."
Why this works: It starts with the outcome. It confirms the "mission accomplished."
The "So What": "This migration reduces our operational overhead by $12k/month and eliminates the single point of failure that caused last month's outage. No further capital expenditure is needed for this quarter."
The Engineering Version
"Database migration complete. Cut over to the new RDS instance at 04:00 UTC."
Why this works: It provides the technical "when" and "what."
The Detail: "We encountered a locking issue on the user table during the final sync, but resolved it by adjusting the replication window. Latency is down 30% on average, though we're seeing some P99 spikes we need to tune in the connection pool tomorrow."
The Support Version
"The app is back to full speed following this morning's maintenance."
Why this works: It focuses on user experience and status.
The Logistics: "Users should no longer see the 'connection timed out' errors on the dashboard. If anyone reports a slow-loading profile page, please tag @engineering-on-call immediately. The system is stable, but we'll be monitoring closely for the next 24 hours."
4. The 60-second pre-communication checklist
You don't need an hour to tailor a message. You just need 60 seconds of intentionality. Before you hit "Send" on that email or Slack message, run through these six questions:
Who is the primary audience for this message?
What is the single most important piece of information they need?
What is the "So What?" for this specific person or group?
Are there technical terms I need to define or remove?
What is the specific action I am asking them to take?
Does the level of detail match their proximity to the work?
Most people communicate by "dumping" their thoughts onto the page. By using this checklist, you shift from broadcasting to targeting. You are no longer just making noise; you are providing signal.
5. How to read the room in real-time
Sometimes you're in a meeting, not an inbox. The rules of tailoring still apply, but the feedback loop is faster. In-person or Zoom-based communication requires a different kind of vigilance: The Real-Time Read. If you're presenting a project and you see someone's eyes glaze over, or you notice them reach for their phone, you've likely missed their "frequency."
Learning to read the room is about monitoring the energy level of your audience and adjusting your level of abstraction in response. It's not about what you planned to say; it's about what they need to hear in that moment to remain engaged.
Signal: Glossy Eyes
You're likely too deep in the "How." If you're talking to an executive and they start checking their phone, stop the technical explanation and jump immediately to the "So What." You need to move from the 500-foot view (implementation) back up to the 30,000-foot view (business value). Skip the slides about the architecture and go straight to the slide about the results.
Signal: Rapid-Fire "How" Questions
You're likely too high-level for the technical experts in the room. They don't believe your "Outcome" yet because they haven't seen the logic or the trade-offs. If an engineer starts asking about edge cases or load-testing data while you're presenting a strategy, don't brush them off with "we'll handle that later." Briefly dive deep to show them you've done the work, then resurface.
Reading the room also means understanding the "Hidden Audience." Often, you're speaking to a group where different personas are present simultaneously. In these cases, your pitch needs a tiered structure: a high-level summary for the execs (BLUF), a tactical breakdown for the managers, and an appendix or a "happy to dive deeper" offer for the engineers.
The best communicators are like radio tuners—they adjust their "dial" until the static disappears and the message comes through clearly. They aren't afraid to stop in the middle of a sentence and say, "Wait, let me take a step back—I think I might be going too deep into the weeds here. Does this level of detail help you, or should we talk about the impact instead?" This kind of self-awareness is a hallmark of senior leadership.
6. The "translation layer" skill for cross-functional people
In high-growth companies, the most valuable employees aren't just the ones who are best at their primary craft. They are the ones who act as the Translation Layer between departments. They are the "glue" that holds cross-functional teams together.
Think about a Product Manager. Their entire job is translation. They take a nebulous "Business Need" from the CEO (e.g., "We need to increase user retention"), translate it into "Technical Requirements" for the Engineering team (e.g., "Implement a personalized notification engine with these specific triggers"), and then translate the "Technical Reality" back into a "Roadmap" for Marketing and Sales (e.g., "New engagement features launching in Q3").
If the PM speaks only "Executive," the engineers won't know what to build. If they speak only "Engineering," the CEO will feel the product is moving too slowly or that the team is focused on the wrong things. The "Translation Layer" is what prevents organizational friction. It ensures that everyone is working toward the same goal, even if they're looking at different parts of the map.
But you don't have to be a PM to be a translator. A Senior Engineer who can explain why a technical debt payoff is worth a two-week sprint delay to a Sales Lead is far more valuable than a Staff Engineer who can only talk about complexity and code patterns. An Ops Lead who can explain the logistics of a new product launch to the Support team in a way that minimizes tickets is a hero in any organization.
"Your career ceiling is often determined by the number of 'languages' you can speak fluently. If you only speak 'Developer,' you will likely stay a Developer. If you speak 'Developer,' 'Business,' and 'Customer Support,' you are a leader. The broader your translation layer, the larger the problems you are capable of solving for the company."
This isn't about "dumbing things down." It's about contextual intelligence. It's about having the empathy to realize that the person you're talking to has a different set of pressures, a different set of goals, and a different set of KPIs than you do. When you bridge that gap, you're not just communicating; you're building a more cohesive and efficient organization.
Every job interview is a pitch. Know who you're pitching.
Whether you're speaking to a recruiter, a hiring manager, or a future peer, tailoring your message is the key to standing out. Career Capybara helps you master these high-leverage communication skills.
Tailoring the pitch is not a "soft skill." It is a hard, measurable advantage. It reduces the number of follow-up questions in your inbox. It speeds up approval cycles. It builds trust across the organization.
The next time you have a major update, take a breath. Don't just type out what you did. Ask yourself: "If I were the person reading this, what would make my life easier?"
Answer that question, and you'll never have to worry about being misunderstood again.