Build a Cross-System Signal Radar That Decides What Needs Your Attention

Every engineering director I know starts the morning the same way: Jira, then GitHub, then Slack, then Asana, then maybe a spreadsheet someone pinned in a Google Chat room three weeks ago. By the time they've assembled a mental picture of what actually needs intervention, 40-50 minutes have evaporated — and half of what they flagged turns out to be fine.

This pattern is a cross-system signal radar. It uses parallel Claude Code subagents to pull data from five systems simultaneously, feeds everything into an orchestrator that runs confidence scoring, and produces a two-minute brief color-coded as RED, AMBER, or GREEN. The entire pipeline runs before you open your laptop.

For many VP or Director-level engineering leaders, the approach can save in the range of 30-60 minutes per day^[3] — though the actual gain depends heavily on how many tools you currently scan and how disciplined your team is about keeping them current. The real payoff is not just the time — it is the reduction in missed signals. When you manually scan dashboards, you are pattern-matching against yesterday's mental model. An automated radar catches the things that changed shape overnight.

Dashboards were designed for operators who stare at screens all day. Engineering leaders are not operators. They context-switch between strategy, hiring, architecture reviews, and stakeholder management. A dashboard demands continuous attention; a leader needs processed conclusions.

The 2025 SANS Detection & Response Survey found that 46% of all alerts across organizations turn out to be false positives.^[1] In engineering operations, the number tracks similarly: stale PRs that are actually waiting on a design decision, "blocked" Jira tickets that someone forgot to update, Asana tasks that look overdue but were intentionally deprioritized.

The average organization runs eight observability tools.^[2] Engineers spend more time toggling between dashboards than actually resolving the problems those dashboards surface. For a director overseeing 40-80 engineers across multiple squads, the cognitive load is multiplicative — every additional tool adds another tab to check, another notification channel to monitor, another mental model to maintain.

The architecture has three layers:

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 all 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 your preferred channel — email, Slack, or a pinned Google Doc that updates daily.

Each collector subagent is defined as a markdown prompt file that Claude Code loads as a task. The key design principle: each collector knows nothing about the others. It queries one API, extracts the signals that matter, and returns a standardized JSON payload. This isolation makes the system easy to extend — adding a sixth source means writing one new collector file, not refactoring the orchestrator.

Here is what each collector extracts:

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

A blocked Jira ticket is AMBER by itself. But if the same feature also has a PR that has been open for five days with zero reviews, that combination is RED. The blocker is not the ticket status; it is a review bottleneck that is stalling an entire feature. The orchestrator catches this because it sees both signals simultaneously.

The confidence scoring pass works in three stages:

Here is the mistake that kills most alert systems: people set thresholds based on what feels reasonable, ship it, and never adjust. 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 core 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. You want the system to over-report in the first week.

Notice the structure of each RED and AMBER item: source attribution, confidence percentage, temporal context, and a concrete suggested action. The leader reads this in 90 seconds and knows exactly what needs their attention and what the first move should be.

The GREEN summary is deliberately compressed into bullet points. If everything is healthy, you do not need details — you need confirmation that the radar actually checked.

Once the radar works for one director, the natural question is: can every engineering manager get their own? Yes, but with a critical architectural change.

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

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

This also unlocks a powerful 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?

The signal radar pattern is not complicated. Five focused collectors, one smart orchestrator, a delivery mechanism, and — critically — 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 fundamentally changes how you start your day. Instead of 45 minutes of anxious dashboard-scanning, you get a 90-second brief that tells you exactly what needs intervention and why.^[4] The signals that matter find you. Everything else stays GREEN.