Chapter 1: Teaching a technical concept

Whether you are onboarding a junior, presenting to a team, or answering "so what does this actually do?" from a product manager, the task is the same: take something you understand and make it land in a mind that does not yet. This chapter gives one structure that works for almost any technical concept in about ten minutes, and a worked example.

The structure

Step	Time
1. The problem	60 s
2. The naive approach and why it fails	90 s
3. The concept	2 min
4. One worked example	4 min
5. One thing that goes wrong	90 s
6. Recap in one sentence	30 s

1. The problem (60 seconds)

Start with a situation the audience recognises, before naming the concept. People remember solutions to problems they have felt. "You have 4,000 pages of internal documentation and nobody can find anything" is a problem. "Today I will explain retrieval-augmented generation" is a lecture title.

2. The naive approach and why it fails (90 seconds)

Describe what a reasonable person would try first, and the specific way it breaks. This does two things: it validates the audience's own first instinct, and it creates the gap the concept will fill. "You could just paste all 4,000 pages into the prompt. It does not fit. And even if it fit, the model would lose track of the middle."

3. The concept (2 minutes)

Now name it, and give the one-sentence version. Then the two or three moving parts, with the plainest possible words. No acronyms that were not defined in the previous sentence. Draw it if there is a whiteboard; the drawing should have fewer than six boxes.

4. One worked example (4 minutes)

Walk through a single concrete case from start to finish. Real inputs, real outputs, real numbers. One example done completely beats three examples done partially. If you can show it running, show it running; if not, narrate exactly what would appear on the screen.

5. One thing that goes wrong (90 seconds)

Every concept has a characteristic failure. Naming it does two things: it shows the audience that you have actually used this, and it gives them the first thing to check when it fails for them. "The most common way this breaks is that the chunk cuts a table in half, and the model makes up the other half."

6. Recap in one sentence (30 seconds)

The one sentence they should be able to repeat tomorrow. If you cannot write it, you have not finished preparing.

Choosing the level

The same structure works for a senior engineer and a finance director; what changes is the words in step 3 and the example in step 4.

Audience	Step 3 vocabulary	Step 4 example	What to leave out
Non-technical	"Finds the right pages, then writes an answer from them"	A question they would actually ask, and the answer with the source link	Vectors, embeddings, chunking - unless asked
Developers, new to AI	Embedding as "turning text into coordinates so similar text is nearby"	The pipeline as code, 20 lines, run live	Re-ranking, hybrid search, eval details
Experienced ML / AI engineers	Full vocabulary	The eval set and the gate, because that is what they have not seen	Steps 1-2 can be 30 seconds total

The most common mistake is pitching too high: using a word in step 3 that you did not define, and losing the room without knowing it. The second most common is pitching too low to experts, who then disengage. Two defences:

• Ask one calibrating question at the start. "Who here has written code that calls a model API?" Hands tell you the level.
• Watch for the glaze. When eyes go to phones, you lost them two sentences ago. Stop, back up, and say "let me put that differently".

Worked example: explaining RAG to a mixed audience

The audience: a product manager, two backend developers, a support lead. Ten minutes, whiteboard.

1. Problem. "Support gets forty questions a day that are answered somewhere in our handbook. Finding the page takes longer than answering from memory, so people answer from memory, and the answers drift."

2. Naive approach. "First idea: ask an AI model. It has read the internet; surely it knows. Problem: it has not read our handbook, so it makes something plausible up. Second idea: paste the whole handbook into the question. It does not fit - the handbook is 300 pages and the model can read about 100 at a time. And when we tried with a 90-page version, it answered from page 2 and page 88 and ignored the middle."

3. Concept. "Retrieval-augmented generation. Two steps instead of one. First, find the five paragraphs most likely to contain the answer - like a very good search. Second, give the model only those five paragraphs and the question, and tell it to answer from them and say which one it used." (Draw: question → search → five paragraphs → model → answer with [1] [2].) "The search is the clever part. It does not match words; it matches meaning, so 'vacation' finds the page about 'annual leave'."

4. Worked example. (Live, if possible.) "Here is the question: 'Can I carry unused leave into next year?' The search returns these five paragraphs - you can see 4.2 and 4.3 from the handbook are in there. The model's answer: 'Up to five days can be carried over, with manager approval [1].' And [1] is a link to section 4.2. Click it - there is the sentence." Then one more: "Now 'What is the capital of France?' - the search finds nothing relevant, and the model says 'I could not find this in the documentation.' That refusal is a feature. It means we can trust the answers it does give."

5. What goes wrong. "The most common failure: the search finds the right page but the paragraph was cut in half when we indexed it, so the model sees the start of a table and invents the rest. We check for that with a test set of fifty questions we know the answer to."

6. Recap. "Find the right five paragraphs first, then let the model answer from those - and only those."

Ten minutes. The product manager can now explain it to her director. The developers know what to build. The support lead knows what "I could not find this" means when she sees it.

Teaching the practices from this course

Everything above applies to teaching the delivery loop, spec-driven development or the governance model. A few specifics:

• Teach with the learner's own task. "Bring a ticket from your backlog" beats any prepared example. Write the spec together; run the loop together; review the diff together.
• Make the first failure happen on purpose. Let the assistant fabricate an API or drift scope in front of the learner, then show the check that catches it. One witnessed failure teaches more than ten warnings.
• Give them the rules file. The team's rules file is the fastest onboarding document you have. Read it together, line by line, and tell the story behind each line.
• Pair for the first week. Review their diffs with them, out loud. The judgement you are transferring is not in any chapter; it is in the forty small decisions you make while reading a diff.

Summary

• Problem, naive approach, concept, one worked example, one failure, one-sentence recap.
• Set the level with a calibrating question; watch for the glaze; back up when you see it.
• One example done completely beats three done partially.
• Teach with real tasks, witnessed failures, the rules file and a week of pairing.