Six Dashboards Are Not Observability. They Are a Tax.

Forty-five minutes. That is what most engineering directors pay every morning before standup, walking the same loop: Jira, then GitHub, then Slack, then Asana, then a spreadsheet someone pinned in a chat room three weeks ago. The output is a mental model of what needs intervention. Half of what gets flagged is fine.

That loop is a manual triage pipeline running on the most expensive infrastructure in the org. It is also the wrong shape. Reading dashboards trains you to pattern-match against yesterday's picture. The signals that matter are the ones that changed overnight, and the human eye is bad at deltas.

The replacement is structural. Five collector subagents fan out across five systems in parallel. An orchestrator pulls the payloads, cross-references them, scores confidence, and emits a 90-second brief tagged RED, AMBER, GREEN. Total wall-clock: under a minute. The pipeline finishes before the laptop opens.

For a director scanning five or more tools, the time recovered lands somewhere between 30 and 60 minutes a day.^[3] The actual gain depends on how many surfaces you currently check and how disciplined the team is about keeping them current — claim the time savings only after you measure them. The bigger payoff is harder to count: signals that crossed system boundaries overnight no longer require a human to notice them.

Dashboards were designed for SOC analysts and on-call engineers — people whose job is to stare at the screen. Engineering leaders are not those people. They context-switch between hiring, architecture review, stakeholder management, and the next quarter's plan. A dashboard demands continuous attention. A leader needs a processed conclusion.

The 2025 SANS Detection & Response Survey clocks 46% of all alerts as false positives.^[1] Engineering operations track close to that number. Stale PRs blocked on a design call. "Blocked" Jira tickets nobody bothered to close. Asana tasks marked overdue that the team intentionally deprioritized. Signal-to-noise is bad on every surface, and it compounds across them.

The average org runs eight observability tools.^[2] For a director overseeing 40 to 80 engineers across squads, that is eight tabs, eight notification channels, eight mental models — all kept warm in the background while real work happens. The cost is not the time per tool. The cost is the cognitive overhead of holding the union of all of them in working memory before the first 1:1 of the day.

Three layers, sharply separated:

Layer 1 — Collectors run as parallel Claude Code subagents. Each one talks to exactly one system and returns a normalized signal payload. They run simultaneously, so total collection time equals the slowest API response (usually 3–8 seconds), not the sum of all five.^[5]

Layer 2 — Orchestrator receives the five payloads, cross-references them (a blocked Jira ticket and a stale PR on the same feature is worse than either alone), runs a confidence scoring pass, and assigns RED/AMBER/GREEN.

Layer 3 — Output formats the brief as a concise summary delivered to a chosen channel — email, Slack, or a pinned Google Doc that updates daily.

The coupling rule is non-negotiable: collectors know nothing about each other. Adding a sixth source means writing one new collector file, not refactoring the orchestrator. The system that resists growth is not a radar — it is a project liability.

Each collector subagent is a markdown prompt file Claude Code loads as a task. The design constraint is strict: each collector knows nothing about the others. It queries one API, extracts the signals that matter, and returns a standardized JSON payload. That isolation is what makes the system extend cleanly — adding a sixth source is one new collector file, not an orchestrator rewrite.

What each collector pulls:

The orchestrator is the most important piece, and the one most teams get wrong on the first attempt. Its job is not to summarize. Its job is to correlate and judge.

A blocked Jira ticket is AMBER on its own. The same feature with a PR open five days and zero reviews is RED. The blocker is not the ticket status — it is a review bottleneck stalling an entire feature. The orchestrator catches this because it sees both signals at once.

The scoring pass runs in three stages:

Here is the failure mode that kills most alert systems: thresholds get set on what feels reasonable, the system ships, nothing gets adjusted. Within two weeks the brief either cries wolf so often that leaders ignore it, or it misses a real incident because the thresholds were too relaxed.

The calibration loop is not optional. It is the feature that separates a useful radar from another notification channel.

Start intentionally too sensitive. Set every threshold at the aggressive end. PR open longer than 24 hours? AMBER. Two blocked tickets? RED. Business metric down 5% week-over-week? RED. The system should over-report in the first week. Tightening down is easy. Discovering missed signals after the fact is not.

Each RED and AMBER item carries the same four fields: source attribution, confidence percentage, temporal context, and a concrete suggested action. The leader reads the brief in 90 seconds and walks out knowing what needs attention and what the first move is.

The GREEN summary compresses to bullets on purpose. If everything is healthy, the leader does not need details — they need confirmation that the radar actually checked. A brief with no GREEN section is ambiguous: did the system find nothing, or did it fail silently?

Once the radar works for one director, the question is whether every engineering manager can run their own. Yes — with one architectural rule.

Collectors can be shared. A single Jira collector pulling all blocked tickets is more efficient than one per manager. The orchestrator must be personalized. Each leader cares about different teams, different projects, and runs different threshold tolerances.

The cleanest cut is a profiles/ directory where each leader has a config file specifying their teams, projects, and custom thresholds. The orchestrator loads the relevant profile and filters collector output accordingly.

That structure also opens an organizational view: if every leader's radar data is logged, a CPO or CTO can run a meta-analysis across all briefs. Which teams consistently show RED? Which systems generate the most false positives? Which cross-team dependencies surface as correlated signals?

One uncomfortable finding from teams that have rolled this out at scale: some managers actively resist the brief format. Not because the data is wrong. Because scanning dashboards manually was giving them a reason to open conversations with their teams. The morning Jira ritual was also an excuse to ping a teammate, notice something off in passing, stay close to the work. Automating the scan removes that ambient contact. Worth knowing before you push it to fifteen managers at once. The fix is structural, not motivational: replace the lost contact surface with a deliberate one — a 15-minute pulse with each direct, on a schedule, owned by the leader.

The signal radar is not a complicated system. Five focused collectors, one orchestrator, a delivery channel, and a calibration loop that tightens the system over time. The hard part is not building it. The hard part is the discipline to log false positives and adjust thresholds every week for the first month.

Once calibrated, the radar restructures the morning. No more 45 minutes of dashboard-scanning. A 90-second brief lands before standup, names what needs intervention, and shows the work.^[4] The signals that matter find you. Everything else stays GREEN.

Triage in your head is a coordination tax. Pay it once, in code, and stop paying it every morning.