The 1:1 Intelligence Brief: What Data Says Before You Walk In

Most engineering managers walk into their 1:1s half-prepared. They skim a few Jira tickets, glance at last week's standup notes, and hope the conversation finds its own shape. It works often enough that nobody questions the process — until the meeting where a burned-out engineer finally says, "I mentioned this three 1:1s ago."

The per-EM 1:1 intelligence brief takes a different approach. Thirty minutes before each scheduled meeting, the system pulls together team Jira metrics, recent GitHub pull requests, the most recent 5/15 report, recognition highlights, concerns flagged during the last sprint, and any open action items. Every data point gets annotated as either new since last 1:1 or continuing pattern. The result is a one-page brief that tells you exactly what changed and what persisted — so you can walk in ready to have the conversation that actually matters.

Engineering managers typically juggle between four and seven tools during any given week. Jira for sprint work, GitHub for code review activity, Google Docs for 5/15 reports, Slack for pulse checks, and some flavor of HR platform for performance notes. Preparing for a single 1:1 means context-switching across all of them — and that assumes you remember where each signal lives.

According to Jellyfish's engineering intelligence research, engineering leaders report spending roughly 3 or more hours per week on meeting preparation that could be partially or fully automated^[3]. Multiply that across a team of six direct reports, each getting a weekly 1:1, and you're looking at a meaningful chunk of time burned on information gathering rather than actual leadership.

The deeper problem is recency bias. When you manually prepare, you over-index on whatever you saw most recently. That one loud Slack thread from yesterday overshadows the quietly accumulating pattern of missed sprint commitments. An intelligence brief fixes this by surfacing data systematically, not based on what happened to catch your eye.

The intelligence brief is organized into six distinct sections, each pulling from a different data source. What makes it useful is not just the data — it's the annotation layer. Every metric and item carries a tag: new since last 1:1, continuing pattern, or resolved. This lets you skip the things that haven't changed and zero in on what demands attention right now.

The core of the intelligence brief is its delta detection engine. Rather than presenting raw numbers, it compares the current state of every metric against a snapshot taken at the time of the previous 1:1. This snapshot-comparison approach is what transforms a data dump into an actionable brief.

When the system generates a brief, it first retrieves the stored snapshot from the last meeting. This snapshot contains the exact values of all tracked metrics at that point in time — velocity, blocked count, open PR count, action item status, and so on. The engine then fetches the current values and runs a diff.

The diff produces three categories of findings:

The distinction between new since last 1:1 and continuing pattern is where the real value lives. A single sprint with low velocity is a data point. Three consecutive sprints with declining velocity is a trend that demands a different kind of conversation.

The tagging logic works on a rolling window. When a metric first crosses a threshold, it gets tagged as new since last 1:1. If the same metric was already flagged in the previous brief and remains in the flagged state, it escalates to continuing pattern. When a previously flagged metric returns to normal, it gets tagged as resolved — which is just as important to acknowledge in the meeting.

This three-state model prevents two common failures. First, it stops you from re-raising something that you already discussed and agreed was a temporary blip. Second, it forces you to notice when a "temporary blip" quietly becomes the new normal. Three consecutive continuing pattern tags on the same metric trigger a special annotation: persistent trend — consider structural intervention.

Any system that aggregates individual performance data carries risk. Used carelessly, an intelligence brief becomes a surveillance dashboard that erodes the psychological safety you need for honest 1:1 conversations. Three guardrails keep the brief in its proper lane.

First, the brief is visible to both parties. The engineer sees the same data you do, delivered to their inbox at the same time. There are no hidden metrics. This transparency turns the brief from a managerial weapon into a shared starting point.

Second, the brief does not prescribe conclusions. It shows that velocity dropped 18% — it does not say "this person is underperforming." The interpretation happens in the conversation, where context lives. Maybe they were onboarding a new teammate. Maybe the sprint was estimation-heavy. The brief provides signals; humans provide meaning.

Third, the brief data never feeds into performance reviews directly. It is a meeting preparation tool, not an evaluation instrument. This boundary must be explicit in team documentation and reinforced in practice. The moment engineers suspect the brief is building a case against them, they'll game every metric it tracks.