A structural engineering firm we worked with had a quiet, expensive problem. Roughly 40 percent of the data was missing from its budget control forms at any given time. Project managers were supposed to update the forms daily. They were busy on jobsites. They dropped the task. Leadership did not have time to check every form every week. Three change orders went uncaptured across two projects in a single quarter, and the firm closed the year $90,000 over budget on a single engagement that should have been profitable.

When the partners walked us through what had happened, the first instinct was to talk about the project managers. Were they not paying attention? Were they not following the documented process? Should we be having performance conversations?

We pushed back gently. The PMs were senior, capable people who had been with the firm for years. They were not lazy. They were doing the work the firm hired them to do, plus a daily compliance task that nobody had built a system to support. The form was in SharePoint. Updating it required opening a browser, finding the right folder, opening the right workbook, and entering data that lived in three other systems they would have to look up. Of course it dropped.

Why This Is a System Problem, Not a People Problem

If you put high performers in a system that makes the right action expensive and the wrong action cheap, you will get the wrong action most of the time. That is not a comment on the people. It is a comment on physics. Friction wins. It always wins.

The strategic question is not "how do we get our people to be more disciplined." That question has been the wrong question for the entire history of operations management, and managers who have been fighting it for 30 years are tired in exactly the way that makes them want to fire everyone. The right question is "what would it take to make the right action so easy that doing it correctly takes less effort than skipping it."

That question has a clean answer in 2026. The answer is a custom dashboard with the right data, the right defaults, and the right nudges built in.

What an Accountability Engine Actually Looks Like

We rebuilt the budget control workflow for that engineering firm inside their custom dashboard. Here is what changed at the system level.

The dashboard pulled budget data live from QuickBooks Time, the project plans from SharePoint, and the change orders from the project record. The form was no longer a separate thing the PM had to remember to update. It was the dashboard itself, pre-filled with everything the system already knew.

When budget burn crossed a threshold relative to plan, the dashboard flagged it on the PM's home view in red. They did not have to go look. The flag came to them.

When a field log indicated a possible change order, the dashboard drafted the change-order email to the supervisor and waited for the PM's approval. The PM read it, edited if needed, hit send. Twelve clicks became one.

When the PM hesitated on a decision, the dashboard surfaced the historical default for similar projects: how the firm had handled this exact situation across the last two dozen jobs. The right answer was right there. Choosing it was a single click. Overriding it was possible but required a reason.

When data was missing for two days running, the dashboard pinged the PM, then the PM's manager, on day three. Nobody had to check. The system checked.

None of this is exotic technology. It is the same data the firm already had, presented in a way that made the right action the path of least resistance and the wrong action visible to leadership without anyone having to manually surveil. The accountability layer was a dashboard, not a meeting.

What Changes Downstream

Six months after the dashboard went live, the partners stopped chasing compliance entirely. They looked at exceptions only, and there were not many because most exceptions resolved themselves before they reached the partner level. The PMs got more autonomy than they had ever had, because the dashboard surfaced the work without anyone needing to ask. The good performers loved it. They had always wanted the friction gone, and now it was.

Two of the previously underperforming PMs visibly improved. Once the structure made the right action obvious, the gap between them and the senior PMs closed. The third one self-selected out of the firm within four months. He did not like working in a system that made his pattern of dropping things visible. The partners did not have to manage him out. The system did.

None of this required a single performance review, write-up, or difficult conversation. The accountability problem solved itself when the accountability engine was built into the workflow.

Why This Is Different From "AI Surveillance"

We get this question often, and it deserves a clean answer. The dashboard is not watching the employee. It is watching the data. The data tells the truth either way. The PM either updated the budget or did not. The change order was captured or it was not. Surfacing those facts is not surveillance. It is honesty.

Surveillance is when a system tracks behavior that is not directly tied to outcomes. Mouse clicks, typing speed, time at the desk, screenshots of personal browsing. We do not build any of that. We have refused projects that asked for it. The accountability engine we are describing here measures only the work itself: did the budget get updated, did the change order get captured, did the variance get flagged.

If a PM is doing the work and the data is current, the dashboard never lights up at them. They might not even notice it is there. The good performers never feel watched, because they are not. The system only acts when something is off, and even then it acts on the data, not the person.

A Note on Throughput

This is not a structural engineering pattern. We have seen the same dynamic at very different businesses. An anonymized agricultural distributor we worked with had a post-trade-show engagement problem: leads collected on the floor sat in a spreadsheet for three weeks before anyone followed up. After we built an accountability layer that triggered the right outreach within 48 hours, with drafts pre-written from the show conversation context, post-trade-show engagement improved by roughly 95 percent.

95%
Improvement in post-trade-show engagement after a custom accountability layer was added at an anonymized agricultural distributor. Same sales team. Same leads. Different system around them.

Same pattern. The reps were not lazy. The system was making the right action expensive. When the dashboard prompted them with pre-drafted outreach within hours of the show ending, the right action became cheaper than not doing it. The accountability problem disappeared.

Where This Fails

We have walked away from engagements where the underlying issue was not actually accountability. It was the appearance of accountability. Leadership wanted a dashboard so they could point at it in board meetings and say they had implemented controls. They did not actually want the data to surface problems. When we showed early prototypes that flagged real issues, the conversation got tense. The flags were inconvenient. The pilot stopped.

We do not take those engagements forward. The accountability engine works only if leadership is willing to look at what it surfaces and act on it. If the goal is theater, we are the wrong vendor. We will tell you that during the discovery call, before either of us has spent money.

When leadership genuinely wants to know what is happening in the operation, the engine is among the most powerful tools we build. The frustration that comes from people not doing their jobs, the fatigue that drives executives to talk about skeleton crews, almost always traces back to a system that was making the right action too expensive. Fix the system, and most of the people you were frustrated with turn out to be people you want to keep.

Where to Start

If you are looking at your own operation and wondering whether this applies, the diagnostic is short. Pick one accountability problem that has been chronic. The form that never gets updated. The follow-up that always slips. The variance that gets caught too late. Walk through what it currently takes for the right person to do the right thing at the right time. Count the clicks, the systems they have to open, the data they have to look up. That number is the friction. The dashboard project is about driving that number to one or two.

You can see what we build on the Apps and Dashboards page, and how it connects to broader workflows on the Operations Platform page. The structural engineering case study walks through the full build that turned the budget control problem into the accountability engine described above.

If you want to talk through your own version of this, that is what we do on a discovery call. Bring the chronic problem. We will help you see whether it is a people problem, a system problem, or both. Most of the time it is the second one, and that is the kind of problem we know how to fix.