Weak signals worth investigating

Sit through enough postmortems and the same finding keeps turning up: some metric, an error rate or a queue depth, had been creeping the wrong way for three weeks before it tripped an alert and paged someone. An engineer had noticed the trend and mentioned it in passing, nobody had looked into it, and the weeks in between were lead time nobody spent. The incident was expensive, but the early version of it, back when it was just a trend on a chart, was almost free.

Teams behave like the systems they run: the senior engineer who resigns in October went quiet in July, and the subsystem that will eat next quarter shows up as three small patches this quarter, each one reviewed and merged by people who never compared notes. An expensive team problem almost always ships a cheap early version of itself first, and the leaders who look like they saw it coming are the ones who investigated the cheap version.

There is no shortage of writing about the signs themselves: practitioner checklists enumerate them, retention articles list the behaviors of someone halfway out the door, metrics vendors will sell you an alarm for review latency, and strategy writers have been on weak signals since Igor Ansoff in the 1970s. Nearly all of it stops at noticing, and none of it says what to do on the ordinary Tuesday when something registers as off and would not survive being said out loud yet. You cannot raise it, because there is nothing concrete to raise, and you cannot ignore it, because it keeps registering.

This playbook is built for that moment: treat the signal as a hypothesis, and spend exactly one cheap action testing it. Everything else here is either setup for that one action or a guardrail around it.

Learn normal before you read anything

A weak signal is a change from the team's normal, and you cannot spot a change without knowing what normal is. Before any signal means anything, you need to know what this team and these people look like when things are fine: who talks in design reviews and who stays quiet, how fast reviews normally turn around, what planning sounds like when the team is healthy, whether a given engineer writes paragraphs or one-liners on a good week.

Little of that baseline can live in a dashboard. Flow metrics hold the quantitative slice, and they are worth having, but the baseline that matters here is behavioral and personal, and you build it only through ordinary attention: reading the review threads you would read anyway, sitting in the meetings you would sit in anyway, and noticing what they look like on a normal week.

Picture a staff engineer who has pushed back loudly and usefully on design decisions for two years, and who has now been agreeable for a month. No single meeting has anything wrong with it; each one, taken alone, looks like a good meeting. The signal only exists against the baseline, because for this person, a month of agreement is the anomaly.

This is exactly where the warning-sign checklists go wrong: they read the behavior itself rather than the change in it. A terse engineer who was always terse is not news, and neither is a camera that was never on. Without a baseline, every item on every checklist reads as a warning, which is how those lists turn conscientious managers into anxious ones.

Collect at three levels, and read the drift

Signals cluster at three levels, and most of us only collect the first.

• Person-level. The ones the checklists cover: the senior who stopped pushing back, the 1:1 agenda that used to be full and now empties out, the camera that used to be on in every call, written updates shrinking from paragraphs into one-liners.
• Work-level. These live in artifacts rather than people: review latency sliding week over week, pull requests drifting far above or below someone's usual size, the same subsystem patched three times in a month.
• Room-level. These belong to the group rather than to any member: the question nobody asks in planning, meetings that end early with no dissent, humor drying out of the team channel.

At every level, what counts is the drift rather than the single instance: one quiet meeting is an observation, but three consecutive weeks of quieter meetings is a signal; a single slow review is just a Tuesday, but a median that moves in one direction for a month is not.

Stopping at the person level is the expensive mistake, and the reason we make it is that person-level signals arrive with a face attached, while room-level signals belong to nobody. The question nobody asked in planning costs one sentence to investigate, and precisely because no one owns it, no one asks it.

Spend one cheap check

When a signal repeats, or when two independent signals point the same way, it has earned an investigation rather than a reaction. Treat it as a hypothesis you are buying information about, and spend exactly one cheap action on it: an open question in the next 1:1, a read through the last two weeks of review threads, sitting in on one design discussion you would otherwise skip. Cheap means the action is reversible, private, and carries no accusation.

Say planning covers a risky migration with a hard cutover, and across forty-five minutes nobody asks who owns the cutover itself. The silence is the signal, and the cheap check is one direct question before the meeting ends: who owns the cutover night? If the answer is a name and a plan, the signal clears at the cost of five seconds, but if it is a pause and then three people looking at each other, you have bought weeks of lead time on an incident for the price of one sentence.

Do not draw a conclusion from the check, and do not step in on the strength of it. You are buying information, and stepping in on a guess spends credibility you cannot buy back if the guess turns out wrong.

The check fails when it carries a judgment inside it. "I noticed you have gone quiet lately, is everything okay" sounds caring, but what it tells the person is that they are being watched and their quietness is being scored, and people respond to being scored by acting normal on purpose. Once a team is acting for you, you cannot read it at all. The open question in the 1:1 does not mention the signal; it opens a door ("what is taking most of your energy these days") and leaves it to the person to walk through or not.

Read the work before the person

When the check needs a first target, start with artifacts: diffs, review threads, design-doc comments, meeting notes. Not because people are dishonest, but because the work grounds the eventual conversation in something concrete. If the artifact trail shows a real thing, you can talk about the thing; if you start with the person instead, you are asking them to respond to a vibe, and there is no good answer to "you seem off."

Say the median time to first review has slid from a few hours to a full day over six weeks. That is a work-level drift, and the artifact trail is sitting in the review threads. Two weeks of reading them turns up one senior reviewer on the critical path of most changes, answering later and shorter each week, and the signal that looked like "the team is slowing down" resolves into one overloaded person quietly functioning as a bottleneck. The conversation that follows is about load rather than about anyone's commitment, which is a much easier conversation to have.

The same rule that governs measurement governs investigation: read the work you would read anyway as a leader, and do not pull activity data on an individual. Charts of commit hours and counts of messages are technically artifacts, and pulling them is surveillance. Teams can tell the difference between a leader who reads the work and a leader who monitors the people, and the moment they decide you are monitoring, you are back to being performed for.

Write it down and give it a horizon

The common outcome of a cheap check is ambiguity: the signal neither confirms nor clears, and a week later, three other fires in, you have forgotten it, and the drift you half-noticed keeps growing unwatched.

So I keep a private watch note, four fields per entry:

• the signal I noticed
• the date
• the check I spent on it
• what would confirm or clear it

Each entry gets a horizon of two weeks or a month. When the horizon arrives, the entry either turns into a real next step (a performance conversation, a workload change, a staffing decision) or it gets deleted. Memory alone will not hold a three-week drift across a dozen people, which is the entire reason the note exists.

Mine is deliberately shabby, a dozen lines in a private note, and shabby is the correct amount of engineering for it. In a typical month most entries die quietly at their horizon and one or two escalate into a real conversation, and the deleting is the note doing its job.

The watch note is not a performance file. A performance file accumulates evidence toward a conclusion; the watch note is a list I expect to delete. If an entry survives two horizons without ever escalating, the likelier explanation is not that the problem is unusually subtle but that I am seeing things, and the entry gets deleted on those grounds alone.

Check your own state before trusting a signal

You are the one doing all of this reading, and you drift too. Tired and anxious leaders read too much into weak signals: a slow reply looks deliberate, a declined invite feels aimed at you, and soon you are reading a story into neutral behavior. The loop feeds itself, because a leader who treats withdrawal as suspicious makes people withdraw further, and the deeper withdrawal then confirms the original suspicion.

So check your own state before trusting what you think you are seeing, especially in a rough quarter. If three new entries appear in my watch note during a week when I am underslept and over-pressured, at least one of them is probably about me rather than about the team. Push far enough down this road and people start hiding perfectly normal behavior from you, just to stay off whatever list they suspect you are keeping.

When not to run this

This playbook stops at two boundaries. The first is surveillance: if a check would require activity data on a person, or reading things you would not read in the ordinary course of leading, stop, no matter how strong the signal looks. Whatever you would learn is not worth teaching the team to hide things from you.

The second boundary is paranoia: if the watch note keeps growing and entries keep surviving their horizons, you are adding entries faster than you clear them, and the problem is you. The fix is rest and a sober look at your own state, rather than more vigilance.

Most weak signals are noise, and the playbook expects that: one cheap check, one horizon, then delete. It was never going to catch everything, and a manager who investigates everything becomes one of the signals a team learns to work around. The measure I hold it to is smaller: most rows deleted on schedule, one or two real conversations a month, and the occasional expensive problem that turned up with a date already next to it in the note.