.agents/em-context.md

.agents/em-context.md

.agents/reports/[name].md

If the conversation reveals durable new context later, update

.agents/em-context.md

or

.agents/reports/[name].md

automatically. Save stable facts and patterns, not guesses, transient frustration, or unresolved interpretations.

• State the likely diagnosis or recommendation first
• Ask at most 2-3 targeted questions only if the missing context changes the advice
• Give the next concrete action and, when useful, exact wording the manager can use
• Mention the relevant framework briefly, but do not explain every part of it
• Offer a deeper version only after the direct answer

• Don't know where to start with engineering metrics → DORA: The Four Key Metrics (start here)
• Team feels slow but you can't point to data / engineers say they're blocked → DevEx: Three Dimensions
• Leadership asking how the team is performing → Tying Engineering Metrics to Business Outcomes
• Being asked to rank or score individual developers → The Problem With Productivity Metrics + What Not to Do
• Wondering whether surveys and qualitative data count → Qualitative Metrics Are Not Soft

1. Problem framing: what the user is trying to learn or prove.
2. Metric set: 2-5 team-level signals, mixing delivery, quality, and developer experience.
3. Interpretation: what each metric can and cannot tell you.
4. Action loop: how the team will use the data to remove friction.
5. Anti-pattern warning: what not to measure or communicate.

• SLOC (lines of code) — incentivizes verbose code, penalizes refactoring
• Velocity (story points per sprint) — measures effort estimates, not output; easily inflated
• Cycle time — better, but captures only one dimension of delivery

• Baseline your current state. Don't compare to benchmarks yet — just establish your own baseline.
• Pick the one metric where your team is furthest from high performance. Fix that first.
• Don't optimize all four simultaneously — that's how you get gaming instead of improvement.

• How often do you feel blocked waiting for someone else?
• How confident are you that your work won't break something unexpectedly?
• How clear is it to you what "good" looks like for your current project?

• Don't use metrics to evaluate individual developers. This destroys trust and optimizes for the metric at the expense of real work.
• Don't report raw velocity. It measures estimated effort, not output. Leadership will compare across sprints and ask why it dropped, forcing the team to inflate estimates.
• Don't pick a framework and implement all of it at once. Start with one or two metrics, establish a baseline, and use them to have conversations — not to produce dashboards nobody reads.
• Don't treat metrics as a substitute for judgment. A team with perfect DORA scores can still be building the wrong thing. Metrics measure delivery health, not direction.

• team-health

  — Productivity friction and DevEx signals often surface in team health conversations

• roadmap-planning

  — Delivery metrics inform capacity planning and deadline discussions

• meetings

  — Flow state is the DevEx dimension most directly affected by meeting culture