Great next step

Published: November 2025 · Author: Nick Daly · Reading time: ~8 min read · Blog

How to know you actually understand what you read (instead of just recognizing the words)

There’s a quiet professional hazard that doesn’t get talked about much: false understanding.
You read a long article, a strategy memo, a technical brief, a vendor analysis—maybe even something an AI helped draft—and it feels clear while you’re in it. You’re nodding along. The sentences are familiar. You can follow the logic in real time.
Then, later, someone asks a simple question: “So what’s the point?” And you can’t answer cleanly.
You remember phrases. You remember the vibe. You might even remember a chart. But you can’t produce a crisp explanation that would help someone make a decision.
That gap is not a sign you’re bad at reading. It’s a sign you were relying on recognition instead of retention.

Recognition is easy: “Yes, I’ve seen ideas like this before.” Retention is harder: “Here’s what it means, why it matters, and what we should do.”
The fastest way I know to close that gap is the teach‑back: after you read or listen to something, you explain it in your own words—briefly, like you’re telling a colleague in a hallway.
But most people stop too early. They write a summary that still sounds like the original text: vague, abstract, and full of borrowed phrasing.
This is where text‑to‑speech becomes unexpectedly useful. You can listen to your own teach‑back the same way someone else would hear it. The holes show up immediately.
With read‑aloud.com, it’s simple: write your teach‑back, copy it, paste it, press Start. If it sounds fuzzy, you don’t understand it well enough yet—or you haven’t expressed it clearly.
This isn’t about sounding smart. It’s about being able to use what you read.

Why smart people still fall for “I get it”

If you’re mid‑career, you’ve read enough to develop pattern recognition. That’s a strength—until it becomes a trap.
A lot of modern writing is “fluent.” It has good structure. It uses familiar concepts. It flows. You can follow it while you’re reading, which tricks your brain into thinking you’ve absorbed it.
But follow‑along understanding is not portable. It doesn’t survive a meeting.
The teach‑back forces compression. If you can compress the idea into 30 seconds, you own it. If you can’t, you don’t. That’s not insulting. It’s just a clean test.

What a “teach‑back” actually is (and what it isn’t)

A teach‑back is not:

The 30‑Second Teach‑Back template (steal this)

Keep it to four sentences. That limit is part of the value.

  1. The point is: ___
  2. It matters because: ___
  3. The key tradeoff / constraint is: ___
  4. Next step: ___
    That’s it. Four sentences. If you can do that honestly, you understand the thing.
    If you can’t, you’ve found the gap before it embarrasses you.

Try this on read‑aloud.com (the part that makes it work)

Here’s the exact loop:

Step 1: Read/listen to the source in one chunk

Don’t try to summarize an entire 20‑page doc at once. Pick a section you can hold: a heading’s worth, or 3–6 paragraphs.

Step 2: Write the 4‑sentence teach‑back immediately

Do not re-open the source while writing. This matters.
If you re-open the doc, you’ll copy its language and bypass your own thinking. The teach‑back is supposed to reveal what you actually retained.

Step 3: Paste your teach‑back into read‑aloud.com and listen once

Listen at a normal speed. The goal is to hear it like a colleague would.
While you listen, mark anything that sounds like:

The non-obvious insight: listen for missing nouns and missing “because”

When teach‑backs are weak, it’s usually because of one of these:

1) Vague nouns

Words like “alignment,” “efficiency,” “stakeholders,” “outcomes,” “capabilities” are often placeholders.
They can be useful in a long doc, but they’re deadly in a short explanation. In audio, they sound like fog.
Fix: replace vague nouns with concrete ones.

A real example: bad teach‑back vs good teach‑back

Imagine you read a brief that argues you should run smaller experiments instead of big launches.

Bad teach‑back (sounds fine, isn’t useful)

“The point is that we should improve how we launch features so we can drive better outcomes and reduce risk. It matters because we want to move faster without breaking things. The tradeoff is balancing speed and quality. Next we should align with stakeholders and define a plan.”
When spoken, this is mush. It’s all abstract nouns. It doesn’t actually tell someone what to do.

Good teach‑back (clear, actionable)

“The point is we should ship changes in smaller slices instead of big launches, because failures become easier to isolate and roll back. It matters because our last two launches caused support spikes and slowed the team for a week each time. The tradeoff is we’ll spend more time on instrumentation and release planning up front. Next step is to pick one upcoming feature and define a two‑step rollout with a clear metric and rollback trigger.”
That second version has teeth. You can disagree with it, but you can’t say it’s unclear.

A “quality bar” that keeps you honest

After you listen to your teach‑back, ask yourself this:
Could someone make a decision from this?
If your explanation ends with “we should align” or “we should consider,” it’s probably not decision‑grade yet.
Another good bar:
Could I send this as a Slack message without being asked, ‘What do you mean?’
If not, rewrite.

What to do when you can’t write a teach‑back (and you’re not dumb)

Sometimes you genuinely can’t teach‑back because the source is one of these:

  1. Too big (you tried to summarize an entire report)
  2. Too big (you tried to summarize an entire report)
  3. Too big (you tried to summarize an entire report)
  4. Poorly written (it’s unclear, contradictory, or over-polished)
  5. Poorly written (it’s unclear, contradictory, or over-polished)
  6. Poorly written (it’s unclear, contradictory, or over-polished)
  7. Missing evidence (it makes claims without support)
  8. Missing evidence (it makes claims without support)
  9. Missing evidence (it makes claims without support)
  10. Not actually relevant (your brain doesn’t care, so it won’t retain)
  11. Not actually relevant (your brain doesn’t care, so it won’t retain)
  12. Not actually relevant (your brain doesn’t care, so it won’t retain)
    The fix depends on the cause:
    • If it’s too big: summarize one section at a time.
    • If it’s poorly written: write what you think the claim is, then list the questions you still have.
    • If it’s missing evidence: your teach‑back should explicitly say “This claim is asserted but not supported.”
    • If it’s not relevant: stop. “I chose not to spend more time on this” is a valid outcome.
      Mid‑career leverage is knowing what to ignore.

Turn teach‑backs into a personal advantage

If you do this regularly, two things happen that matter professionally:

  1. You start showing up to meetings with crisp explanations instead of vague opinions.
  2. You start showing up to meetings with crisp explanations instead of vague opinions.
  3. You become the person who can translate dense material into decisions.
  4. You become the person who can translate dense material into decisions.
    That’s rare. And it’s valuable.
    You don’t need to do it for everything. Do it for:
    • vendor evaluations
    • strategy memos
    • technical proposals
    • research summaries
    • AI-generated briefs you might forward
      Basically: anything that could influence a decision or be quoted later.

The 30‑Second Teach‑Back checklist

When you want to know whether you actually understood something: