The question is not whether your detection program produces metrics. It does. The question is whether those metrics connect to the work happening at the analyst level. For most teams, they do not.

That gap is where improvement dies.

The first time I sat with an analyst and timed a single phishing investigation, the number was about 45 minutes. The SLA said we targeted 30. The MTTR dashboard said our average was 25. Both of those numbers were technically accurate. Neither of them explained the 45 minutes, or the fact that the analyst had no idea the 45-minute investigation was unusual. To him, that was just how long it took.

When you ask where the time went, the answer is always specific. In that case: about 10 minutes of pivot between the email gateway and the SIEM because there was no direct link between the alert and the raw log. About 8 minutes to find the user's manager because the directory query returned a deprovisioned account with the same display name. Six minutes re-running a VirusTotal lookup that had timed out silently. The investigation itself took about 22 minutes. The rest was friction. Not skill. Not complexity. Friction.

That is the pattern. If you time real investigations, what you find is that the underlying security work is often fast. Analysts know their targets. They know the appearance of a phishing email, the meaning of a suspicious login pattern, and the requirements of a DLP hit. The time goes to the scaffolding around the work: the tool pivots, the missing integrations, the context that lives in the wrong system or does not exist at all. 

Aggregate metrics cannot reveal these insights. A 28-minute MTTR average stems from 40 investigations ranging from 8 minutes to 2 hours. It is weighted by incident type, analyst experience, time constraints, and the recency of playbook updates. The average is real, but it is not actionable. You cannot look at a 28-minute metric and pinpoint what to fix.

Now, a single timed investigation gives you a real, actionable starting point. That isn't because the math represents the whole picture. It's because the example is specific. You can point right at that 11-minute tool pivot and say: right there is a missing integration. You can look at those eight minutes of directory confusion and say: we have a data quality problem in our identity system. Those are issues you can actually fix. The average just covers up those problems. The stopwatch tracks them down. 

The pattern that does not show up in dashboards

Security operations programs invest heavily in detection coverage. They tune rules, build use cases, manage alert fatigue. Less investment goes into the mechanics of how an analyst actually moves through an investigation once it lands in the queue. The assumption is that if analysts are skilled and the playbooks are written, the investigation will be efficient. That assumption is usually wrong.

Skill is not the bottleneck; the real holdup is process friction. You only catch that kind of friction when you sit down and watch someone do the work in real time.

The teams that improve the fastest are not the ones with the most sophisticated tooling. They are the ones who sit with analysts regularly, time real work, and treat friction as a defect to eliminate rather than a background condition of the job. They build saved searches for queries that analysts run manually every day. They integrate systems that analysts pivot between constantly. They update playbook steps that describe actions that have not been true for two tool generations.

None of this requires a platform purchase. It requires a stopwatch and a willingness to look at where the time actually goes.

What changes when you make this a practice

The first timed investigation is a baseline. The second one tells you whether the friction you found is consistent or situational. After five or six across different investigation types, you have a map of where your process is broken. Not a MTTD chart. A map. Specific friction points with specific causes.

The second-order effect is cultural. When analysts see management track and address process friction, they begin reporting those inefficiencies. They stop treating a 47-minute investigation as the standard baseline and start flagging that 11-minute tool pivot as a problem worth raising. That transition transforms a person from an analyst who merely executes a process into an analyst who owns the workflow. Ultimately, the stopwatch is not just a measurement tool; it serves as a clear signal that daily operational friction is worth fixing.

Start with one investigation. Write the number down. Then go find out where it went.