A junior engineer asks you a question. The complete answer is ten steps long. You write all ten, get told "this is overwhelming," and watch them go to ChatGPT instead. Or you write three sentences, get told "you skipped some details," and they break something in production.

There's a third move: compress to three sentences while keeping the load-bearing detail. It's the most useful technical-communication skill there is, and almost nobody teaches it explicitly.

Why long checklists lose readers

When someone asks a question, they're carrying cognitive load already — they're confused about the thing, often a bit anxious about it, and trying to figure out next steps. A ten-step reply adds load. Each step demands evaluation: is this relevant to me? Have I done it? Should I do it now? By step seven, the reader has decision fatigue and stops reading carefully.

The other failure mode: a long checklist signals that the writer doesn't know which step matters most for the reader's specific situation. It abdicates the diagnostic to the reader. Senior engineers compress because they know which step is load-bearing for this person.

The compression algorithm

When you've got a long answer in your head, run it through these passes:

Pass 1: Identify the one cause that's most likely.

Not the most general principle. The most likely specific cause given the symptoms in their message. If the reader described idle connection pool exhaustion under load, the modal cause is idle-in-transaction. Lead with that, not with "there are many reasons connection pools exhaust."

Pass 2: Add the one verification step.

Tell them the single thing to check that confirms or denies the lead diagnosis. "Run X, look for Y" — concrete, doable in 30 seconds. Not "investigate the connection pool state" — that's vague and reads as advice without commitment.

Pass 3: Add the one most likely next branch.

If the verification step rules out the lead diagnosis, name the second-most-likely cause in one sentence. Don't enumerate the third, fourth, fifth. Stop at two.

That's three sentences total. It contains 80% of the value of the ten-step version, with 30% of the load.

A worked compression

Original 10-step answer:

For connection pool exhaustion under load, check:
1. Pool size — increase max_connections
2. Idle timeout — lower idle_timeout
3. Connection leaks in ORM — verify lifecycle
4. Long-running transactions — check pg_stat_activity
5. PgBouncer pooling mode — try transaction mode
6. Query duration — index missing queries
7. Server resource limits — check ulimit
8. Network — verify no firewall dropping
9. Application threading — check thread pool
10. Monitoring — set up pg_stat_statements

Compressed:

Most likely idle connections held by transactions that aren't being released. Run SELECT pid, state, query_start FROM pg_stat_activity WHERE state = 'idle in transaction' — anything older than a few seconds is your culprit, usually an ORM error path that doesn't release. If that's clean, second guess is idle_in_transaction_session_timeout not being set.

The compressed version:

Names the top diagnosis with confidence ("most likely")
Gives the exact command to verify
Names the second branch in case the first is wrong
Skips items 3-10 entirely

The ten-step list isn't lost. It exists in the writer's head as the source of the compression. The compression is the part the reader sees.

When compression is wrong

Compression isn't always the right move. It's wrong when:

The reader explicitly asks for a checklist ("what should I check?")
You're writing documentation, not a reply (the form expects breadth)
The diagnosis is genuinely uncertain — three causes are roughly equally likely, and dropping any of them would mislead
The reader is at a stage where they need to learn the underlying model, not just fix this issue

In those cases, write the long answer. The skill is knowing which mode you're in.

A self-check

Before you ship a long technical answer, ask: if I had to pick one cause and one verification step, which would they be? If you can pick them, write the compressed version and add the long version as a follow-up if asked. If you genuinely can't pick — three things are equally likely — that's a signal to ask one diagnostic question back instead of writing a checklist.

The deeper point

Compression looks like brevity but is actually diagnosis. A senior engineer's two-sentence answer feels confident because they've already done the diagnosis in their head and are sharing the result. A junior's two-sentence answer feels guessy because they haven't done the diagnosis.

The path to compressed answers isn't "write less." It's "diagnose more before you write." Once you've nailed the most likely cause for the specific reader, compression follows naturally.