"You are too in the weeds" — decoded

People hear this as “you know too much detail” and quietly resent it, because the detail is the job.

That is not what it means. The problem is who is doing the summarising.

The actual complaint

You spent two weeks on something. You understand its structure: the constraint that mattered, the three dead ends, the reason the obvious approach fails. When you report, you present it at roughly the depth you worked at.

The listener has fifteen minutes, five other topics, and no context. They now have to build the summary themselves, live, while you are still talking. That is work you could have done and did not, and “too in the weeds” is what it feels like from their chair.

Reframed that way it stops being an insult about your judgement and becomes a straightforward request: compress it first.

Why the instinct runs the other way

For technical work, the instincts that cause this are correct instincts, which is why the feedback lands so badly.

Precision is right. Caveats are right. Explaining why the obvious approach fails is right, because otherwise someone proposes it again next week. In a design document, in code review, with peers who share the context, leading with the detail is not a flaw.

The mistake is not switching modes. The same material needs a different shape for a five minute update to people who will not touch it.

What to change

Lead with the conclusion, always. “It’ll be ready Thursday.” “We should use the second approach.” “This is blocked on procurement.” One sentence, no preamble.

Then the one thing that could change it. Not all six risks. The one that is most likely to matter. “The only thing that would move it is if the vendor comes back with a different schema.”

Then stop, and let them pull. If they want the reasoning they will ask, and now the detail arrives as an answer to a question rather than an obstacle in front of the point. Identical content, completely different reception.

Match depth to the decision, not to the work. Ask what this person will do with the information. A director deciding whether to fund another month needs the conclusion and the risk. Your tech lead needs the dead ends. Same fortnight of work, two different reports.

The bit that feels wrong

Leading with the conclusion feels like overclaiming, especially when the situation is genuinely uncertain. You know how much sits behind the sentence, and stating it flatly feels like hiding all of it.

But the caveats do not disappear. They move behind the conclusion, where they are heard as qualification rather than as hesitation. Nothing is lost except the listener’s wait.

There is also a version of this that is actually about status, and it is worth naming honestly. Some people deliver detail to demonstrate the work was hard. If you have ever noticed yourself wanting the room to understand how much effort something took, that is the impulse, and the fix is different: the compression itself is the demonstration. Being able to reduce two weeks to one sentence is a harder skill than being able to describe two weeks, and it reads that way.

Checking it

The test is simple and countable. In your last update, how many sentences passed before you said the thing the listener needed?

If the answer is more than one, you have found it.