Hello ,
Early in my career, I learned something important: knowing SQL syntax and being able to use it strategically in real time are two different skills.
Wednesday, 2pm. Q2 review meeting.
CMO: “Our booking conversion is down 23% from Q1. What’s causing it?”
Everyone looks at me. I’m the “analytics person.”
My internal thought process:
I can write queries, but I’m not sure how to approach this question on the spot. Should I look at customer segments? Time periods? Conversion points in the funnel?
My actual response:
“I’ll pull the data and get back to you by Friday.”
I’d completed 3 SQL courses. I could write queries. I understood JOINs.
But I hadn’t yet learned to translate business questions into analytical approaches in real time.
Then I developed a framework that changed how I approached these situations. Not by learning more SQL syntax, but by learning how to think like an analyst in real time.
Let me share what finally clicked.
The Pattern I Was Stuck In
Here’s what I was doing wrong:
Learning SQL syntax without business context
I knew what LEFT JOIN did
I didn’t know WHEN to use it or WHY
Practicing on generic datasets
“Find the top 5 customers in the Northwind database”
Cool. Now what?
Treating SQL as a programming language, not a business tool
I thought success meant writing perfect queries
I didn’t realize success meant answering executive questions
The Pattern I Needed to Break:
1. Executive asks data question in meeting
2. I ask for time to analyze it
3. I spend days trying different query approaches
4. I deliver results that partially answer the question
5. Executive asks follow-ups I didn’t anticipate
6. I realize I need to develop a better analytical framework
What I learned: The gap wasn’t my SQL skills. It was the thinking framework between hearing a business question and knowing which analytical approach would answer it.
Other people in the room seemed to have this framework already. The finance director knew which metrics mattered. The marketing lead understood how to segment data.
I needed to develop that same analytical intuition.
The Meeting That Changed Everything
Then came the $50,000 mistake I almost made.
Friday morning. CEO’s office.
CEO: “I read your analysis. You’re recommending we target expert-level customers with our $50k Q3 marketing budget?”
Me: “Yes. The data shows we have 268 expert customers—that’s our biggest segment.”
CEO: “And they’ll respond to adventure travel marketing?”
Me (confidently): “The numbers support it.”
CEO: “Okay. Let’s launch Monday.”
Thursday night, 11pm. Reviewing the query one more time:
Something felt off. I ran another analysis—this time looking at ACTIVE customers, not just total customers in the database.
That’s when I saw the problem.
Expert customers: 268 total, 34 active in last 6 months.
I was about to convince the CEO to spend $50k marketing to people who’d already churned.
The difference? I’d counted customers instead of thinking about the business question: “Which customers should we spend money trying to reach?”
That’s when I realized: Writing queries ≠ doing analysis.
The Shift That Changed My Career
What finally clicked wasn’t learning more SQL. It was learning how to think about the business question beneath the data question.
When presenting to executives, you need three layers:
Layer 1: The Business Question (Start Here)
Before showing any data, state the question you’re answering.
Bad opening:
“I ran a query joining customers, bookings, and payments to calculate retention…”
Good opening:
“You asked which customer segments should we target for retention. Here’s what I found…”
Frame everything around THEIR question, not YOUR process.
Layer 2: The Insight (This Is What Matters)
State your findings in plain business language. No SQL terms.
Bad insight:
“The ROW_NUMBER() window function partitioned by customer segment showed that expert-level customers have a 47.3% repeat booking rate.”
Good insight:
“Expert-level customers book again at nearly 2x the rate of beginners – 47% vs 24%. That’s our most valuable retention segment.”
See the difference? Same data, completely different framing.
Layer 3: The Recommendation (Make It Actionable)
Executives don’t just want insights. They want to know what to DO with them.
Bad ending:
“So that’s what the data shows. Any questions?”
Good ending:
“Based on this, I recommend we focus our retention emails on expert customers first. A 10% improvement in their retention would generate $200K more revenue than targeting beginners.”
You’ve now moved from data analyst to business advisor. That’s the career shift.
Real Example: Summit Adventures
Let me show you this framework in practice.
The Technical Analysis:
I wrote a query finding that cultural expeditions generate $374,134 in revenue with 139 bookings, while hiking generates $351,951 from 125 bookings at a higher average value ($2,095 per booking vs $1,959).
How I used to present it (wrong):
“I joined expeditions to expedition_instances using the expedition_id foreign key, then to bookings via instance_id, then to payments using booking_id. After filtering for completed payment_status and grouping by expedition_type with SUM aggregation, I found cultural has the highest total revenue…”
Executive eyes glaze over. Meeting moves on.
How I present it now (right):
“Question: Which expedition types should we prioritize for Q2 marketing?
Insight: Cultural expeditions generate the most total revenue ($374K from 139 bookings) while hiking trips have 7% higher average value per customer ($2,095 vs $1,959). Photography leads in volume with 193 total bookings across 97 trip instances.
Recommendation: Focus marketing budget on cultural expeditions (proven revenue leader), upsell hiking trips to premium customers (highest transaction value), and expand photography offerings (highest volume demand). This three-pronged approach maximizes revenue, transaction value, and booking volume simultaneously.”
Executive leans forward. Discussion begins. Decisions get made.
The Mistakes I See Every Week
Mistake #1: Leading with methodology
Your stakeholders hired you BECAUSE you know SQL. They don’t need proof. They need results.
Save the technical details for documentation or if someone specifically asks “how did you calculate this?”
Start with the answer, not the process.
Mistake #2: Using technical jargon
Every time you say “I joined the tables,” you lose attention.
Replace technical terms with business language:
❌ “I grouped by customer segment”
✅ “I compared our three customer segments”
❌ “The aggregate function showed”
✅ “The total came to”
❌ “After filtering null values”
✅ “Looking only at customers with complete data”
Mistake #3: Presenting data without context
Showing “47% retention rate” means nothing without comparison.
Always provide context:
Compared to what? (Industry average, last quarter, other segments)
Is that good or bad? (State your interpretation)
What’s the impact? (Revenue, customer lifetime value, competitive position)
Mistake #4: No clear next step
If your presentation ends with “here’s what I found” and no recommendations, you’ve done half the job.
Executives are busy. Make it easy for them to act on your work.
The Shift in How I Work
Looking back, what changed wasn’t becoming a SQL expert.
It was developing the analytical thinking framework that lets you respond to business questions in real time.
The meeting six months later:
CMO: “Q3 bookings are trending below target. What do we know?”
This time, I was ready.
“I looked at three things:
1. Volume vs Value – Booking volume down 18%, but revenue per booking up 12%. We’re not losing money, we’re losing transactions.
2. Segment Analysis – 240 expert customers haven’t booked in 90 days. That’s where we’re losing volume.
3. Product Gap – We’re underperforming in expert-tier expeditions. Gap in product offering for our highest-value segment.
Recommendation: Fast-track 3 expert-level expeditions for Q4. Target those 240 inactive experts with early-bird pricing. Projected recovery: $142K from 30% conversion.”
CMO: “That’s exactly the analysis we needed. Let’s move forward.”
The shift? I stopped seeing myself as “the SQL person” and started seeing myself as “the person who helps leaders make data-informed decisions.”
Same technical skills. Completely different positioning.
This changed:
How I was included in strategic meetings
What projects I was assigned to
How my work impacted actual business decisions
My salary and promotion trajectory
Technical excellence gets you in the door. Communication skills get you in the room where decisions are made.
Three Practices That Build This Skill
Practice 1: The “Executive Summary” Discipline
For every analysis you do, write a 3-sentence summary BEFORE sharing results:
1. What question did I answer?
2. What did I find?
3. What should we do about it?
If you can’t articulate this clearly, you’re not ready to present.
Practice 2: Remove the SQL
When presenting findings, pretend SQL doesn’t exist. Explain your insights as if you discovered them through conversation, not queries.
The HOW matters to you (learning, documentation, reproducibility). The WHAT matters to them (business impact).
Practice 3: The “So What?” Test
After stating each finding, ask yourself: “So what? Why does this matter?”
Keep asking until you reach business impact. That’s the level executives care about.
The Career Impact
Technical analysts who can’t communicate stay in junior roles forever, writing queries for other people’s decisions.
Technical analysts who master communication become:
Strategic advisors
Department leads
Directors of analytics
Business partners executives trust
Same SQL skills. Different career trajectory.
The difference is learning to translate data into decisions.
Your Next Presentation
Next time you’re preparing to share SQL analysis:
1. Write your executive summary first (question, insight, recommendation)
2. Remove all SQL jargon from your talking points
3. Add business context to every number
4. End with clear next steps for decision-makers
5. Keep your query available if anyone asks for methodology
Your SQL skills got you the insights. Your communication skills will get you the career.
Until next time,
Brian ([say hi on twitter!](https://twitter.com/briangraves))
—
P.S. This kind of strategic thinking is woven throughout SQL for Business Impact. Every module includes not just SQL techniques, but how to frame insights for business impact. Learning SQL is important. Learning to USE it strategically is what transforms your career. Check out the course at [sqlforbusinessimpact.com](https://sqlforbusinessimpact.com).
P.P.S. What’s your biggest challenge presenting technical work to non-technical stakeholders? Reply and share your story – I might feature it in a future email (with your permission). I read every response and learn from your experiences too.
Want More SQL Insights Like This?
Join thousands of analysts getting weekly tips on turning data into business impact.