1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
|
---
name: feedback-terse-manager-updates
description: "Status updates should be much terser now that the user has moved me into an engineering-manager role — outcomes and decisions only, not sub-fix technical narratives"
metadata:
node_type: memory
type: feedback
originSessionId: 9dfd7445-41b2-47af-a522-0538bd22ed74
modified: 2026-08-24T08:10:37.066Z
---
Even after adopting the fork/delegate-more-of-the-work model (see [[feedback_delegation_and_context_protection]]), my status updates to the user were still "kinda cluttered" — e.g. recounting a sub-fix's root cause and verification steps ("turned out to be the ben-manes plugin, I independently re-verified...") when the outcome ("fixed, verified, moving on") was all that was needed.
**Why:** The user explicitly framed this as a "promotion" (2026-08-24) — I should operate at a higher altitude in *communication*, not just in *execution*. Delegating the work but then reporting it back in full technical detail defeats half the point: their context/attention is the same resource my own context window is, and cluttered updates spend it the same way a cluttered context window does.
**How to apply:** Default status-update shape: what changed (1 line), what's next (1 line). Drop root-cause narratives, verification play-by-play, and file/line specifics from chat updates unless: the user asks for detail, it's a genuine decision point needing their input, or something is surprising/risky enough to flag on its own merits. The detailed trail still belongs in commit messages and code comments (already standard practice here) — that's the right home for it, not the conversation. This applies most when reporting on delegated/forked work, where the temptation is to relay everything the subagent/fork reported back, but it applies to my own inline work too.
|
