The Dashboard Isn't the Intervention

Most intervention software is bought, deployed, and then quietly not used. The gap isn't features. It's the distance between a dashboard that reports a problem and a person who acts on it.

Eli Wood headshot

Eli Wood

June 24, 2026 4 min read
A glowing software dashboard on one side and a classroom of students on the other, with an educator bridging the gap between them by placing an action card

Bought, deployed, unused

There is a quiet failure mode in education software that almost never shows up in a sales deck. A district buys a multi-tiered intervention platform. It gets rolled out. There's training. And then, six months later, the logins taper off, the data goes stale, and the kids who were supposed to be caught by the system are caught by the same overstretched teacher noticing the same way she always did. The software didn't fail a feature comparison. It failed at the only thing that mattered: getting used.

The reflex is to blame adoption on change management — more training, better onboarding, a champion in the building. Some of that helps. But the deeper problem is structural. Most intervention tools are built as reporting systems. They are very good at telling you that a student is struggling. They are almost silent on the part that is actually hard: deciding what to do about it, for this student, this week, with the time and people you actually have. A dashboard that surfaces a problem and then stops has handed the hardest work back to the busiest person in the building.

Insight is cheap; the next right action is expensive

The useful frame is to separate the rules engine from the judgment engine. The rules engine is the part that flags: this student's reading growth has flattened, this group is below the tier-two threshold, this intervention's window is closing. That work is real and software should do it tirelessly. But flagging is the cheap half. The expensive half is judgment — given everything true about this child and this classroom, what is the next right move, and who does it. That is where adoption actually lives or dies, because that is the moment a human either acts or closes the tab.

Applied AI earns its place by moving into that second half without trying to own it. Instead of surfacing a problem and stopping, it can assemble the next decision: here is the student, here is what the data shows, here are two interventions that fit your roster and your minutes, here is the one I'd start with and why. It compresses the distance between knowing and doing — which is the distance where every under-implemented system goes to die. The point is not to make the call for the educator. It is to make the call cheap enough to actually make.

This only works if the human stays in the loop on the judgment, because intervention decisions are exactly the kind where being wrong is costly — you can mis-tier a kid, pull them from the wrong block, intervene on a problem they don't have. So the model prepares; the educator decides. And every recommendation has to be explainable — which signals drove it, what it's assuming — because a teacher will not act on a black box, and shouldn't. Start where the judgment is both expensive and repetitive: the weekly "what do we do about these twelve kids" decision that every interventionist faces and no dashboard has ever actually answered. Explainability is what turns a flag into an action someone is willing to take.

A two-day starting point

The trap is to respond to low adoption by building more dashboard. The fix is to pick a single recurring decision that real users avoid making in the current tool — the weekly tiering review, the "is this intervention working or do we change it" call — and build one thin capability that carries it from data to a recommended next action with its reasoning attached, and hands the decision to a named human.

In two days you can have that running on a real roster and watch what happens at the exact moment educators currently disengage. You'll learn whether the obstacle was insight (it wasn't) or the cost of the next action (it was), and you'll have the one workflow that pulls people back into the system because it finally does the hard part with them. Get that right once and you have the pattern: automate the flagging, support the judgment, show the reasoning — and adoption stops being a training problem and becomes a product property.

Black Flag Design builds applied-AI products for judgment-heavy work where the hard part is getting people to act. If your tool is bought but under-used, spend two days with us closing the gap between insight and action — we call it a Foundation Sprint.

About the author

Eli Wood headshot
Eli Wood

CEO, Black Flag Design

Eli Wood leads Black Flag Design, a creative technology company focused on shipping ambitious digital products, AI systems, and design-forward software with a direct point of view on how technology changes work.

Related stories

More from the journal

Pen-and-ink sketch of a small clockwork robot working at a tool-covered workbench late at night while a human sleeps peacefully on a couch in the background, a wall clock reading 2:00 above
ai April 24, 2026 13 min read

The Agent Stays Up Late, Not Me

Every senior engineer knows the right way to set up a codebase. None of them do it. Here’s the four-stage framework we use — The Ratchet — to take a vibe-coded project all the way to a thing you’d trust in production, and the punchline about why this only just became worth doing.

Most teams have always known they should be running tests, type-checking, security audits, accessibility checks, dead-code analysis, prose linting, and a coverage floor. Most teams run two of those. Here’s why that math has finally inverted, and the four-stage framework we use to ratchet a vibe-coded project to a hardened one.

Keith Pattison

Keith Pattison

Founder, Black Flag Design

Read
Black Flag Journal
claude code April 20, 2026 5 min read

What a Year of Claude Code Trails Tells You About Your Team

Claude Code leaves evidence — sessions, commits, PRs, review notes. Read it like a logbook and you'll find what devs actually need to know before they go deeper.

After a year of shipping with Claude Code across real client work, the signal isn't in any single session — it's in the trails. Here's what those trails told us about where Claude Code shines, where it drifts, and the habits devs should build before they lean in harder.

Eli Wood headshot

Eli Wood

CEO, Black Flag Design

Read
Black Flag Journal
playbook April 20, 2026 6 min read

The Black Flag Playbook: Six Principles for Shipping with AI

Battle-tested principles for teams building real software with AI-generated code. Human judgment, tight scope, and weekly evidence — the disciplines that keep AI-built systems reliable.

The six rules we use to ship production software with AI. Small scope, weekly demos, human-led oversight, and continuous improvement — drawn from six months of real client engagements.

Keith Pattison

Keith Pattison

Founder, Black Flag Design

Read