learn-sql-with-phoebe / Leader session 1 of 6
Learn SQL with Phoebe · Leader track · Session 1 of 6

What SQL actually is

You will never write production SQL - and you do not need to. But every dashboard, every metric, and every "the data says" claim in your company is a SQL query underneath. This track teaches you to read one, question it, and brief the people who write it. Six sessions, no code you have to memorize, run entirely on your own judgment.

🟢 Leader track C-level · managers · curious non-coders No install · nothing to write Start here
0-3 · Welcome 3-24 · What SQL is & why it lasts 24-42 · Read a real query 42-45 · Q&A
Part 0

How this track works

Six sessions that turn "SQL" from a black box your data team owns into something you can reason about. You will not write queries for a living - you will learn to read them, spot when a number is being computed in a misleading way, and ask an analyst for exactly the right cut of data. The examples all run against one small database, Daybreak, a coffee-subscription brand - and yes, a few live queries appear so you can see with your own eyes that SQL is less mysterious than it looks.

What leadership sees, and what actually produced it AVERAGE ORDER VALUE $4,182 THE DASHBOARD THE QUERY UNDERNEATH Which table did the rows come from? orders, or orders joined to subscriptions - a different denominator either way Which rows were filtered out? refunds, test accounts, the free tier - each one moves the average Were empty values counted or skipped? a skipped null shrinks the denominator and quietly lifts the number Which date range, and who chose it? last 30 days, last quarter, or since launch - three different stories Every metric on every dashboard is a question someone wrote in SQL. This track teaches you to read the part under the water.
🔍 Click to zoom - the number is the tip; the judgment lives underneath
Live - discussed in session Self-study - read after ▶ See it run - a real query, live For decision-makers
★ What you walk out with today A plain-English grasp of what a database and SQL are, the confidence to read a simple query and say what it returns, and the single most useful reframe in this whole track: every metric on every dashboard is a question someone wrote in SQL - and questions can be asked well or badly.
Part 1 · the mental model

A database is just organized tables 7 min live

Strip away the jargon and a database is a set of tables - spreadsheets with discipline. One table for customers, one for orders, one for products. SQL (Structured Query Language) is the plain-ish way people ask those tables questions: "which columns, from which table, matching which rules". That is the entire idea, and it has run the business world for 50 years.

The Daybreak database: three tables, one shared column customers COLUMNS customer_id name city signed_up the shared key who they are where they are when they joined orders order_id · customer_id · product_id · quantity · order_date products product_id · name · roast · unit_price The one rule that makes this a database and not three spreadsheets customer_id appears in two tables. That repetition is what lets a single question reach across both. Spreadsheets with discipline: fixed columns, one subject per table, and a shared key to join them.
🔍 Click to zoom - the shared column is the whole trick
The business question "Who are our top customers?" The SQL query SELECT ... ORDER BY ... A table of answers names + numbers, ranked The query is where judgment lives - and where numbers can quietly go wrong. Your job as a leader: read the middle box well enough to trust - or challenge - the right box.
🔍 Click to zoom - question in, query in the middle, answers out
LiveWhy every leader keeps meeting SQL3 min▶

You do not have to seek SQL out - it arrives on its own. The revenue figure in your board deck, the churn number in the QBR, the "active users" on the exec dashboard: each is the output of a SQL query an analyst wrote. When two reports disagree, the reason is almost always that two queries defined the same word - "active", "revenue", "customer" - differently. Being able to ask "how was this actually computed?" is a leadership superpower, and it starts with reading SQL.

  • SQL is the shared language of data teams: analysts, engineers, and scientists all speak it. Learning to read it is learning to sit in the room.
  • It has outlasted every trend: through big data, the cloud, and now AI, SQL is still how the numbers get made. AI copilots write SQL for you - which makes reading it more valuable, not less.
  • You are not learning to build: you are learning to read, judge, and commission. Different skill, enormous leverage.
Real world

The two "revenue" numbers. A leadership team spent a tense hour arguing about a $400k gap between finance's revenue and the product dashboard's. The cause was one line of SQL: one query counted refunded orders, the other excluded them. Neither was wrong - they answered different questions. The executive who spotted it was not a coder. She just knew to ask what the query counted.

Self-studyWhere SQL sits in the modern data stack2 min read▶

A quick map, so the vocabulary stops being intimidating. Your company's data usually flows: sources (the app, payments, ads) → a data warehouse (one big queryable store - Snowflake, BigQuery, Redshift) → SQL pulls and shapes the data → a BI tool (Tableau, Looker, Power BI) draws the chart. SQL is the layer in the middle that turns stored rows into the numbers everyone downstream trusts.

  • Warehouse: where all the data lives, ready to be queried. Session a6 goes deeper.
  • SQL: the question-asking layer. This is what your analysts spend their day writing.
  • BI / dashboard: the friendly face on top - but every tile is a saved SQL query underneath (session a4).
Part 2 · the one skill this session builds

Reading a query, left to right 6 min live

Here is the good news: a simple SQL query reads almost like English if you know the three anchor words. SELECT = "give me these columns". FROM = "from this table". ORDER BY = "sorted this way". You do not need to write it - you need to look at one and say, out loud, what it asks for.

customers - 15 rows, 6 columns name city signup_date plan Ava ChenSeattle2025-11-03Pro Liam FordAustin2025-12-10Basic Noah ParkPortland2026-01-05Pro Mia WongVancouver2026-01-18Basic Ethan RuizDenver2026-01-22Pro … 10 more rows below the cut SELECT name, city, plan FROM customers LIMIT 5 caps the rows the answer - 5 rows, 3 columns name city plan Ava ChenSeattlePro Liam FordAustinBasic Noah ParkPortlandPro Mia WongVancouverBasic Ethan RuizDenverPro SELECT picks the columns (signup_date is left behind), LIMIT 5 caps the rows. The answer is always a table.
🔍 Click to zoom - SELECT picks columns, LIMIT caps rows, a table comes back
LiveSee a real query run - and read it back3 min▶

Below is a live query against Daybreak's customer table. Read it first: "give me name, city and plan, from customers, at most five." Now press ▶ Run and watch the answer appear. You just read SQL and predicted its output - that is the whole skill of this session.

SELECT name, city, plan
FROM customers
LIMIT 5;
The read-aloud test If you can say what a query returns before running it, you can review it in a meeting. That is the bar for a leader - not writing it, reading it with confidence.
LiveThe same skill on a slightly bigger query3 min▶

This one sorts the products from most to least expensive. Read it: "give me name and price, from products, sorted by price high to low." Run it and check. The word DESC is the only new thing - it means descending, high to low.

products - catalog order nameprice Sunrise Blend16.00 Midnight Espresso18.00 Decaf Calm15.00 Cold Brew Kit34.00 Ceramic Dripper28.00 Oat Milk Pods9.00 Single-Origin Ethiopia22.00 House Decaf Beans17.00 ORDER BY price DESC 8 rows in, 8 rows out same rows, priciest first nameprice Cold Brew Kit34.00 Ceramic Dripper28.00 Single-Origin Ethiopia22.00 Midnight Espresso18.00 House Decaf Beans17.00 Sunrise Blend16.00 Decaf Calm15.00 Oat Milk Pods9.00 DESC re-ranks, it never drops: all 8 products come back, priciest first. Remove DESC and the same list flips.
🔍 Click to zoom - ORDER BY re-ranks the rows, it never removes them
SELECT name, price
FROM products
ORDER BY price DESC;
Real world

Why this matters in a review. When an analyst presents "top products by revenue", a leader who can read the query notices whether it sorted by revenue or by units, whether it filtered to completed orders, and what "top" was capped at. Those three questions catch most misleading charts before they reach the board.

Boardroom exercise

Read three queries as a group ★ 12 min · discuss together

No code to write - just read each query aloud, agree on what it returns, then run it to check. The goal is fluency at reading, and catching the small words that change the meaning.

Three anchor words, and the one that caps the answer Read left to right and say each line out loud as a question. Whatever comes back is always a table. 01 SELECT Which columns come back? SELECT name, city FROM customers 2 columns, all 15 rows THE TRAP SELECT * hides which column the number on the slide actually used. 02 FROM Which table is this about? SELECT name, city FROM customers 15 rows to choose from THE TRAP Wrong table, perfect syntax. Nothing warns you. The number runs. 03 ORDER BY In what order do the rows arrive? ORDER BY signup_date DESC newest customer first THE TRAP The order decides which rows a cap keeps. Sort first, then cut. CAP LIMIT How many rows do I want to see? SELECT name, city FROM customers LIMIT 5 5 rows of the 15 THE TRAP A capped list is not a total. Never read a LIMIT result as a sum. Take one word away and here is what you lose WORD READS AS TAKE IT AWAY AND SELECT "give me these columns" every column comes back and none of them is the point FROM "from this table" there is no query at all, and no answer to audit ORDER BY "sorted this way" the order is whatever the database felt like today LIMIT "just this many rows" all 15 rows here, and all 33 million back at work SAY IT OUT LOUD IN THIS ORDER 1 Which table? 2 Which columns? 3 What order? 4 How many rows? If someone hands you a single number, ask which table it came out of. That question is the whole leader track.
🔍 Click to zoom - the reference sheet to keep open during the group read

Query A: read it, predict the output in one sentence, then run. Did the group agree before running?

Query B: same, but notice the one word that changed versus Query A. What did it change in the result?

The leadership question: for each, ask "what business question does this answer, and what does it quietly leave out?"

LiveQuery A · newest customers first3 min▶ 
SELECT name, signup_date
FROM customers
ORDER BY signup_date DESC
LIMIT 5;
LiveQuery B · the whole product catalog3 min▶

The * means "every column". Read it, run it, and notice which products show NULL for roast - equipment has no roast, and the database says so honestly.

SELECT *
FROM products;
Between sessions

Take this back to your desk ◐ 15 min

Source material

What this maps to

The leader track distills the conceptual half of the major SQL curricula - the "what it is and why it matters" - without the syntax drills practitioners need. This session covers:

Six sessions, and what each one puts in your hands a1 What SQL is the reframe a2 Reading a query say what it returns a3 Judging a claim challenge a number a4 The dashboard behind find its rows a5 Asking the right cut get what you meant a6 Warehouses + AI what to trust you finish You will not write queries for a living. You will read them, and know when a number is being computed misleadingly.
🔍 Click to zoom - six sessions, each one a thing you can do afterwards
✓Mode SQL Tutorial - "Intro to SQL" framingPart 1 · what SQL and databases are, in decision-maker terms
✓SQLBolt / Khan - SELECT, FROM, ORDER BY (reading level)Part 2 · reading a query, not writing it
◐The modern data stack (warehouse → SQL → BI)Part 1 self-study; full treatment in session a6
Check yourself

Three questions before you go 🎯 ◐ 90 seconds

1 · When two company reports disagree on "revenue", the most common cause is...

Same word, two definitions in two queries. The leader's move is to ask what each query actually counted - not to assume one is simply wrong.

2 · What does a leader most need to be able to do with SQL?

Reading and questioning, not writing. That is the leverage: catching a misleading metric before it drives a decision.

3 · Every tile on a BI dashboard is, underneath...

Dashboards are friendly faces on SQL. Knowing that is what lets you ask the right question about any chart you are shown (session a4).

Leader session 1 cheat sheet · pin this

A database isorganized tables - customers, orders, products - with linked id columns.
SQL isthe plain-ish language for asking tables questions. 50 years old and still the default.
Read the 3 anchorsSELECT = which columns · FROM = which table · ORDER BY = sorted how.
The leader moveAsk "what does this query count, and what does it leave out?"
Every dashboard tileis a saved SQL query. The chart is just the friendly face.
NULLmeans "no value here" - not zero, not blank. Worth knowing by name.
Where SQL sitssources → warehouse → SQL → BI dashboard. The middle is where judgment lives.
Next sessiona2 · reading a query with a WHERE filter and a JOIN, without fear.