The 1:1 Brief: Walk In Knowing What Changed Since Last Time

The burned-out engineer says it again: "I mentioned this three 1:1s ago." That sentence is not a feedback failure. It is a memory failure compounded by a tooling gap. The manager skimmed Jira, glanced at last week's standup, and walked in trusting their working memory to surface the pattern. Working memory loses to recency every time.

The fix is not better listening. It is a per-EM intelligence brief that runs 30 minutes before each scheduled 1:1. It pulls team Jira metrics, recent GitHub pull requests, the most recent 5/15 report, recognition mentions, retro concerns, and every open action item. Then it does the part that working memory cannot: tags each data point as new since last 1:1 or continuing pattern or resolved. The output is a one-page brief that says exactly what changed and what persisted. You walk in with the conversation already triaged.

Engineering managers touch four to seven tools in any given week. Jira for sprint work. GitHub for code review. Google Docs for 5/15s. Slack for pulse checks. Whatever HR platform owns performance notes. Preparing for one 1:1 means context-switching across all of them — and that assumes you remember which tool holds which signal.

Jellyfish's research on engineering intelligence puts EM meeting prep at roughly 3+ hours per week of work that could be partially or fully automated.^[3] Across six direct reports getting weekly 1:1s, that is a meaningful chunk of management time burned on information gathering rather than the conversation itself.

The deeper failure mode is recency. When you prep manually, the loud Slack thread from yesterday wins over the quiet pattern of three sprints with declining velocity. Whatever caught your eye dominates. The intelligence brief cuts the bias by surfacing data systematically — not by what was loudest.

The brief has six sections, one per data source. The data is not the value. Raw numbers are easy. The value is the annotation layer: every metric and every item carries a tag — new since last 1:1, continuing pattern, or resolved. Anything unchanged drops out of the executive summary. What persists gets escalated. What recovered gets acknowledged. The brief filters before you read it.

The engine compares current state against a snapshot frozen at the moment the previous 1:1 ended — not against rolling averages, not against last week. The snapshot is the load-bearing piece. It is what makes the diff meaningful instead of decorative.

Generation runs in three steps. First, retrieve the stored snapshot from the last meeting: every tracked metric, captured at end-of-1:1. Second, fetch the current values from each integration. Third, run the diff and assign tags.

The diff produces three categories:

The split between new since last 1:1 and continuing pattern is where the leverage is. One sprint of low velocity is noise. Three consecutive sprints of declining velocity is a structural problem, and the conversation it requires is fundamentally different.

The tag logic runs on a rolling window. A metric crossing a threshold for the first time gets new since last 1:1. If the same metric was flagged in the previous brief and remains flagged, it escalates to continuing pattern. When a previously flagged metric returns to normal, it gets resolved — and the brief surfaces it explicitly, so the recovery actually gets acknowledged in the meeting.

This three-state model stops two specific failure modes. First, you stop re-litigating something already discussed and dismissed as a temporary blip. Second, you stop letting a temporary blip quietly become the new baseline. Three consecutive continuing pattern tags on the same metric escalate to a fourth tag: persistent trend — structural intervention required. At that point the conversation is not about the metric. It is about the system producing the metric.

Any system that aggregates individual performance data is a surveillance system unless explicit governance says otherwise. Used carelessly, the brief turns into the thing engineers most reasonably distrust: a manager-side dossier they cannot see. Three rules keep it on the right side of that line. None of them is optional.

First, both parties get the brief at the same time. The engineer's inbox receives it the same minute the manager's does. No hidden metrics. No five-minute manager preview. The same artifact, the same timestamp. This collapses the information asymmetry that makes data feel adversarial.

Second, the brief reports what changed, not what it means. Velocity dropped 18% is data. "This person is underperforming" is interpretation. The brief never crosses that line. Maybe they were onboarding a teammate. Maybe the sprint was estimation-heavy. Maybe nothing happened and it is noise. Interpretation belongs in the conversation, where context lives.

Third, the brief never feeds performance reviews directly. This is a meeting prep tool, not an evaluation instrument. Write the boundary into team documentation. Reinforce it when reviews come around. The moment engineers suspect the brief is building a case, they start gaming every metric it tracks.

We learned this rule from a violation. In an early deployment a manager cited a two-week velocity dip in a mid-year review. The engineer found out. Within a month, half the team was padding Jira estimates to smooth their velocity curves. The brief's data quality on that team never recovered. The governance rules are not advice. They are what keeps the data trustworthy.