Find the question behind the question
When a PM asks about an index, they may really be asking why a feature is slow, whether the fix is risky, or why it cannot be applied everywhere. Those questions call for different explanations. Start with the shared context and, when necessary, ask what they need to decide.
Use an observable outcome as the opening. “Search checks too much data before finding the right result” establishes a problem. Beginning with balanced trees requires the listener to assemble the reason for caring while also learning the mechanism.
Explain one layer at a time
A useful first layer often has four parts: the problem, the idea, an example, and a trade-off. You can then offer a second layer if it changes the decision. This gives the listener a way to ask for detail without being flooded by it.
Define terms at the moment they become necessary. An unexplained acronym is not automatically more precise than ordinary language. “A stored copy of a result” can establish the idea of a cache before you discuss expiration, invalidation, or eviction.
Use an analogy, then mark its boundary
An index at the back of a book is a useful starting analogy for a database index: it helps locate information without reading every page. It does not explain every database implementation, and it does not need to.
Say where the analogy stops if that boundary affects the decision. Unlike a printed book, an application keeps changing its data, so its index also needs updating. That limitation is an opportunity to explain the write cost rather than an embarrassment to hide. Avoid stacking several analogies that make the audience switch mental models.
Check for understanding through the decision
Instead of asking only “Does that make sense?”, ask whether the explanation resolves the original question. “Does this give you enough context to compare faster search with the extra work on updates?” invites a more useful response.
If the listener wants more detail, expand the layer they ask about. If they need to relay the explanation to someone else, give them a short summary that preserves the consequence and the trade-off. The result is a shared understanding, not a performance of expertise.
Keep the decision in the explanation.
- Why it matters: the problem the audience recognizes.
- Core idea: one sentence in familiar language.
- Concrete example: show the idea at work.
- Trade-off: what gets harder or more expensive?
- Decision check: what can the audience do with this explanation?
Same situation. Clearer explanation.
We will add a B-tree index on the composite columns so the optimizer can choose an index scan instead of a sequential scan, depending on cardinality.
As the customer table grows, search can spend too much time checking unrelated rows. An index works like the index in a book: it points toward the matching information. That can make this search faster, but the database also has to update the index when the data changes. We should test it against this query and its update workload before adding it broadly.
Illustrative examples. Adapt the facts and commitments to your situation.
Common mistakes to catch
- Confusing unfamiliarity with lack of intelligence.
- Using a long analogy without explaining the real system.
- Removing the trade-off to make the story sound simpler.
- Answering a mechanism question when the audience needs a decision.
Now try saying it out loud.
Use the framework for one attempt. Listen back, choose one improvement, and try again.
Practice this conversationA couple of useful questions
Is jargon always bad?
No. Shared terminology is efficient when everyone understands it. Introduce or replace a term when it adds learning effort without helping the current decision.
What if the concept is genuinely complex?
Name the complexity and give the listener a map. Explain the parts in the order they need them, summarize the relationship between layers, and offer a deeper follow-up rather than pretending the system is simple.