Where we start
An engineer's output is a pipeline other people trust without checking. That makes the first meeting more dangerous for you than for anyone else in the data team: a wrong assumption in an analyst's chart is visible on the page, but a wrong assumption in a pipeline runs every night, quietly, and gets copied into everything downstream. The running case for all six sessions is Harbourline, an invented chain of 38 pharmacy and clinic outlets across Singapore and Malaysia, and its operations director Adeline Tan, who has never seen a schema and does not need to. She has a request. You have 45 minutes with her. Everything in the six sessions is about what you ask in those minutes, so that what you build settles which copy is real instead of moving the disagreement faster.
★ What you walk out with tonight. A one-page Six Doors sheet for "our numbers never match", or for a request of your own: the data-state row written widest, the outcome question placed first, with the reason beside it, a plain teach-back line attached to every question, and the order you will walk them in. Session 3 puts that sheet in front of Adeline and counts what it gets out of her.
Two tunes, and the word match
5 min liveIn a 1990 Stanford study reported by Chip and Dan Heath, Elizabeth Newton split people into tappers and listeners. Tappers tapped the rhythm of a well-known song on a table; listeners had to name it. Tappers predicted listeners would get about half. Listeners got 3 of 120. The tapper cannot stop hearing the tune, so the taps sound obvious; the listener hears knocking. When Adeline says "match" she is tapping a tune you cannot hear, and when you answer with a word like "reconcile" you are tapping one she cannot.
LiveThe tune behind "match", and why neither side can hear the other's3 min▶
Newton's tappers were not bad at tapping. They could not un-know the song while they tapped, so every knock arrived with the melody attached, and they judged the listener's chances from inside that experience. Economists had named the effect a year earlier: Camerer, Loewenstein and Weber called it the curse of knowledge, the finding that better-informed people cannot fully set their information aside when predicting what less-informed people will understand.
"Match" carries two tunes. Adeline's is the letter on her desk: last month the auditor asked which revenue number was right, in writing, and she could not answer him. Her "match" means "one number I can defend, by a date, to a person". The engineer's tune is the machinery: two tables, a key to join them on, a job that runs nightly. His "match" means "the rows line up". Both are real. Only one of them is the request.
The gap is not closed by either side learning the other's vocabulary. It is closed by questions that make the tune audible: the last time two numbers did not match, which two, who noticed, and what happened next, asked in words that need no translation, with the reason for asking said out loud. That is the rest of tonight.
Self-studyWhy the engineer's version of the gap is the expensive one2 min▶
An analyst who misreads the request ships a chart nobody opens. It is visible, it is cheap to throw away, and the next meeting starts from the embarrassment. An engineer who misreads it ships a pipeline, and a pipeline does not look wrong. It runs green every night. It loads two numbers that disagree into one table, where they now disagree faster, in more places, with a timestamp that makes both look official. The disagreement has not been settled; it has been automated.
That is the failure every page in these six sessions is written against: a pipeline that moves the disagreement faster instead of settling which copy is real. The engineering is rarely the hard part. Deciding which copy is real is a business decision, it needs facts only Adeline and her team hold, and the first meeting is the only cheap place to get them.
The integration that stalled. Harbourline is a constructed case, but this shape is common enough to be a pattern. Two years ago a vendor ran an "integration" project to connect Harbourline's systems. It stalled the week Kenneth, the only IT person, went on leave, and it never restarted. Whatever else went wrong, the stall says the whole project hung on one person, and a person is the one single point of failure nobody draws on a system diagram. Adeline only mentions it once she trusts you, and only if you ask whether they have tried this before. It is the single most useful fact for predicting where your project will stall, because it is usually the same place.
The data-state door, opened widest, but not first
6 min liveEvery discovery meeting is a corridor of six doors: Outcome · Decision · Current way · Data state · Constraints · Success and partnership. The corridor, and the question that opens each door, is drawn once in the analyst's session 1; walk it there if you have not. Tonight spends its minutes on door 4, data state, because it is where an engineer's work is decided: every system a number passes through, who can log in to each, how often each is read, and which copy is declared real. It is your widest door. It is not your first.
LiveOpen questions first, because door 4 holds the sensitive facts3 min▶
The instinct is to open with the systems, because the systems are what you will touch. Resist it for three questions. Door 4 is where the facts people guard live: who holds the only login, which copy of a file is actually used, who fixes numbers by hand without telling anyone. Adeline does not hand those to a stranger who opened with "what is your stack". She hands them to someone who has shown they understand what she is worried about.
So the first question is an outcome question in the past tense: "Tell me about the last time two numbers did not match. Which two, how far apart, and who noticed?" Its teach-back: "A mismatch is two systems answering two different questions. I need the exact pair before I can say which one is right." In four or five minutes you learn which mismatch matters (month-end revenue, about two percent, and an auditor who has now asked in writing), you earn a notch of trust, and every data-state question after it lands on a warmer table.
On Adeline's sheet the most sensitive data-state fact, that Kenneth is the only IT person, holds the only POS admin login, and is leaving in January, needs the highest trust of anything she knows. She has not told her own team. Asked cold, "who can log in?" gets you a name. Asked after trust, it gets you the risk.
LiveThen every system one sale touches, and which copy is real3 min▶
Once she trusts you, open door 4 wide and walk one sale through it: "Which systems does one sale touch, from the till to the bank to the ledger?" At Harbourline the answer is a cloud POS with a CSV export per outlet and an API nobody has used; a bank that settles cards two days late and receives cash weekly; a ledger in a cloud accounting package run by an outsourced bookkeeper in Kuala Lumpur, who exports once a month; and, off to the side, a stock spreadsheet. Then ask how often each is read today and by whom, because that frequency is a ceiling you inherit until a contract or a login changes it.
Leandro DalleMule and Thomas Davenport's 2017 frame for data strategy, as reported, sets a single source of truth against multiple versions of the truth, each fit for a purpose. Both are legitimate designs. What is never a design is having several versions by accident with nobody saying which one wins, and that is Harbourline: finance's number and the POS number are both honest, built along two paths, and nobody has declared which one the auditor gets. The engineer's job at door 4 is not to pick. It is to find out who can decide, and to get it decided before anything moves.
Self-studyWhere the business sits, and why the first build is small2 min▶
Joe Reis and Matt Housley, in Fundamentals of Data Engineering (O'Reilly, 2022), describe organisations as starting with data, scaling with data, or leading with data, and argue the engineering should fit the stage; the framing here is as reported, not read chapter by chapter. Harbourline is plainly starting: 38 CSV files pasted on Monday, a 2019 macro, one IT person, no budget this quarter. A starting business does not need a platform first. It needs one declared real copy of one number, reproduced exactly, with a second person who knows how it is made.
That is also why data state is asked in plain words. Session 2 turns door 4 into a ladder of questions that a person who has never seen a schema can answer, and draws the system map from her replies.
Three copies of one spreadsheet. In the same constructed case, three versions of the stock spreadsheet are in circulation, and the one Priya treats as real lives on her laptop. A leading question ("stock lives in the POS, right?") gets a polite "sure" and puts a false belief in your notes. An open one ("where do the stock numbers live, and which copy is the real one?") gets the laptop, and a teach-back worth saying out loud: "A file that exists three times has no real copy until someone declares one. I need that declared before I move it anywhere."
The order is worth measuring. On session 3's bench, the same questions in any order at all average 27.6 points (the shuffles range from 5 to 45); walked door by door they score 47; tuned for an engineer, three trust-earning questions and then data state widest, they score 51. The ordering is the finding. The numbers belong to a constructed company, not a real one.
The teach-back line for an engineer
4 min liveEvery open question in the bank carries a second sentence: a plain statement of why you are asking. Said out loud before the question, it does three things at once. It turns the question into a reason rather than an interrogation, it earns trust, and it teaches Adeline one true thing about how data work is decided. An engineer's teach-back lines are mostly about hand-offs, logins and timing, which are exactly the things she has never had explained and most needs to understand before she can decide which copy is real.
LiveThree lines an engineer says in almost every meeting2 min▶
A teach-back line is plain: no word she would have to ask about, so "the file" not "the extract", "log in" not "credentials", "two days late" not "latency". It is true: a real principle of the craft, not a pleasantry. And it is one sentence, because two is a lecture and she stops answering. These three carry most of door 4.
Before "Which systems does one sale touch, from the till to the bank to the ledger?": "Every hand-off between systems is a place a number can change. I am counting the hand-offs."
Before "Who can log in to each of those, and pull an export?": "Access is the first blocker on most data projects, so I ask early and I ask by name."
Before "Where does finance's revenue number come from, step by step?": "Two numbers built along two paths usually disagree about timing long before they disagree about truth." Said to Adeline, that last one changes the meeting. She came in believing one side was wrong. She leaves knowing that both may be right about different days, which is the first step to deciding which day the auditor gets. Session 4 builds the rest of the set and chooses the one concept per meeting worth explaining properly.
Self-studyJargon and leading questions, the engineer's two habits2 min▶
Session 3 sorts every question into five kinds: open, closed, vague, jargon and leading. Engineers are most exposed to two. Jargon is the question you would ask a colleague: "Do you have change data capture on the POS, or should we batch?" It costs minutes while she works out what you mean, and it costs trust, because she is now a little less sure you understand a pharmacy. Leading questions are the dangerous kind because they feel efficient: "The POS is the source of truth, right?" gets a "sure", and a belief that is wrong goes into your notes. On this bank the POS is not the source of truth; the two percent is settlement timing.
The fast yes-or-no interview on the bench records five false beliefs of exactly this shape, and each one is a thing you would build on: pull everything daily, the vendor API is in use, finance is simply wrong, stock lives in the POS. Six weeks later each is a pipeline that is correct about a world that does not exist.
The two percent that was not an error. Still the constructed case. Adeline has spent months treating the gap between finance and the POS as somebody's mistake. It is mostly timing: card settlements reach the bank two days after the sale, cash is deposited weekly, and refunds are processed in the accounting system, which the POS never sees. A reconciliation job built on "finance is wrong" would have flagged the same honest difference every month, forever. A single question about where finance's number comes from, asked with its reason, turns a blame problem into a definition problem, and definitions can be decided.
The engineer's sheet for "our numbers never match"
★ 22 min · everyone writesOne page, six rows, one of them wider than the rest. Use Adeline's request, or a "connect the systems" request from your own inbox, and build the sheet you will carry into the meeting. Every line is written before the meeting; the meeting is for listening.
Write the request as it was received, in her words. Not your translation. If it arrived as "our numbers never match", do not write "reconcile POS and ledger". You will want her sentence back at the end of the meeting, to see how far the real request was from it.
Place the outcome question first, and write the reason beside it. The reason is for you, not for her: it stops you skipping the question when the systems start to look interesting.
Write the data-state row widest: four or five questions, each with its teach-back. Every system one sale touches, who can log in, how often each is read, and which copy is real. Write them so a person who has never seen a database can answer every one.
Write the order you will walk tonight. One outcome question, a question each at decision and current way so you know whose number wins and how it is made today, then door 4 widest, then the rest. Session 3 runs exactly this order against Adeline and counts it.
Rehearse the first thirty seconds against her opener. Say your first question out loud with its teach-back. If it took more than twenty seconds, it is two questions; split it.
Keep the sheet after the meeting. Session 2 turns the door 4 answers into a map of every system a number passes through, session 5 turns her answers into three candidate projects, and session 6 turns the filled-in sheet into the one-page brief you send within 24 hours. The same page carries all of it.
Before session 2
30 min- Finish the sheet for your request: the outcome question first with its reason, the data-state row widest, a teach-back line on every question, and the order. Bring it printed; session 3 puts it on the bench.
- Find the tune. For a "numbers never match" request of your own, write what you think "match" means to the person who said it: whose question does the mismatch stop them answering, and by when? Then write what it meant to you when you first heard it.
- Count the hand-offs in one number you already move. Follow one record from where a person or a till creates it to where someone reads it, and number every hand-off. Mark the one where timing differs most.
- Find the declared copy. For one file or table you load today, find out who, by name, declared it the real one. If nobody did, write that down; session 2 starts there.
Three questions
Clear all three and session 1 gets stamped in your passport.
1 · Adeline says "our numbers never match". Why is "match" two questions, not one?
The curse of knowledge runs both ways. Neither reading is wrong, and neither side notices the other one. A nightly job that loads both numbers into one warehouse satisfies the engineer's "match" and leaves the auditor's letter unanswered.
2 · Data state is the engineer's widest door. Why do open questions from other doors go before it?
On Adeline's sheet, the fact that Kenneth holds the only POS admin login and leaves in January needs the most trust of anything she knows. Asked cold, "who can log in?" gets a name. Asked after trust, it gets the risk.
3 · Why does the engineer count hand-offs rather than systems?
The two percent between finance and the POS is mostly timing. Each system is right about its own day; the disagreement lives in the arrows between them, and that is why the teach-back line is "I am counting the hand-offs".
What this session teaches, and where it came from
Every fact on this page, and its verification tier, is recorded in the course's source map.
Session 1 cheat sheet · pin this
Door 4 is the one you know how to open and the one she cannot answer in your words. Session 2 is a ladder of plain questions that gets the real state of Harbourline's data out of a person who has never seen a schema: which numbers are typed by a person and which come out of a till, who owns the product codes, which copy of the stock sheet is real, who holds the only login. You draw every system a number passes through from her answers, and that map is the first thing you send her.