diff options
Diffstat (limited to 'feedback_terse_manager_updates.md')
| -rw-r--r-- | feedback_terse_manager_updates.md | 15 |
1 files changed, 15 insertions, 0 deletions
diff --git a/feedback_terse_manager_updates.md b/feedback_terse_manager_updates.md new file mode 100644 index 0000000..34d2922 --- /dev/null +++ b/feedback_terse_manager_updates.md @@ -0,0 +1,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. |