- If a manager spends most of their time asking how far along the work is, the system isn't doing its job yet.
- The manager's new role is to look only at what is out of the ordinary and fix the rules behind it, instead of chasing tasks one by one.
- Decision authority has to change at the same time. Spell out who can decide what on their own, without asking.
Stop managing through activity
If your team leader spends half a day every week going around asking "How far along is this?", that time may look like diligence, but it is a cost, and it exists because nobody can see the status of the work at a glance. A good system makes the question unnecessary.
Asking who sent how many emails, held how many meetings or used how many AI prompts makes the team produce activity rather than value. Managers should start with an Outcome Contract: who receives the result, what has to be delivered, the minimum quality, when it must be done, and which constraints must never be broken. For example, "close complaints within 24 hours, with no customer data leaked and the fix working the first time" is clearer than "reply quickly".
Next, split the flow of work into standard work and exceptions. AI helps prepare data, set priorities and draft the standard work, while the manager spends time on bottlenecks, allocating resources, Coaching and high-impact decisions. The role is just as big as before; it moves from controlling every step to designing a system that can be trusted.
Build a management rhythm around exceptions
Try switching from looking at every piece of work to looking only at what is out of the ordinary. A doctor doesn't examine every patient every day; they look at the cases whose readings are abnormal. The time left over can go into fixing root causes.
| Rhythm | Topics | What not to do |
|---|---|---|
| Daily, 15 minutes | Work at risk of missing its SLA, and who owns it | Reporting on every task, one person at a time |
| Weekly | P90, errors, backlog and root causes | Looking only at averages |
| Monthly | Cost/Outcome, customers and capacity | Counting licenses or prompts as business results |
| Quarterly | Cancel, expand or redesign workflows | Continuing a project because you have already invested in it |
A good dashboard has to lead to action. Every metric has an owner, a threshold and a Playbook for when it goes out of range. The Review Queue should show the reasoning, the evidence, the options and the deadline, instead of handing the manager long blocks of text to read all over again. A system that sends too many alerts makes people mute it and miss the ones that matter.
Set decision rights and develop your people
Write Decision Rights at four levels: AI recommends; AI drafts and a person approves; AI handles standard cases and people review exceptions; or the system acts within set limits, with spot checks. Work that involves money, people, safety or reputation should always have an owner who can be identified by name or role. Don't use the phrase "Human in the loop" without saying what the person has to look at and how many minutes they have to do it.
For the development team · Technical detail
Managers need to build Psychological Safety so employees can safely push back on AI, and should reward people who find errors in the system. Turn experts from the people who fix every problem themselves into the people who build checklists, Evaluation Sets and the knowledge base. Create growth paths such as Reviewer, Process Owner, Knowledge Curator and Automation Champion, so that sharing knowledge isn't seen as making yourself redundant.
Coaching questions
- What reasoning led you to this answer?
- What evidence would change your mind?
- In which cases should the system stop and hand over?
- Which step should be cut out instead of made faster?
- What knowledge should become a team standard?
A 30-day plan to change the way you manage
For the development team · Technical detail
Week one: choose one Outcome and cancel the status reports that duplicate what the system already shows. Week two: build a dashboard of five metrics (Volume, Lead Time, P90, Quality and Exceptions). Week three: write the Decision Rights and the Escalation path. Week four: trial a Weekly Improvement Review, picking just one Root Cause and following up on the result.
Measure the time managers spend chasing work against the time they spend on Coaching, customers and improvement. If time is freed up but then filled with new meetings, the results won't change. Have the team record its decisions, its assumptions and what actually happened, so the quality of decisions improves. The dashboard should never become a tool for monitoring individuals.
Managers in the AI era don't need to write code, but they do need to be able to read how a work system runs, see the risks in the data, explain who is accountable for what, and lead people through uncertainty. These abilities are what turn technology into capacity instead of one more expense.
MANAGER'S NOTE · What the dashboard won't tell you
A red number is an invitation to go and look at the real work
When P90 gets worse, don't start by asking who is slow. Open the five cases at the back of the queue. You may find that the team is waiting for customer information, or that special approval rules are clashing with each other. Good managers use the dashboard to choose where to go and observe, and they still have the conversation.
One Outcome Card
Write the Outcome, the customer or recipient, the Quality Guardrail, the Owner, the target P90 and the top three exceptions on a single page. Open every weekly meeting with this card. If an agenda item doesn't connect to the card, ask whether it needs a meeting at all.
A question to ask more often: "Where does the system make it hard for you to decide?" works better than "Why aren't you using the system?", because the first question brings Design Flaws to light while the second usually gets only a defensive answer.
From knowledge to a problem-solving system that works in practice
The underlying problem
Managers need to see decisions and exceptions, instead of drowning in status reports that the system should be able to summarize on its own.
A step-by-step approach
- Define the Outcome Contract and the Decision Rights for people and for AI.
- Design an Exception Dashboard that points to the reason, the Owner and the Next Action.
- Change the meeting rhythm to a Daily Exception, a Weekly Improvement and a Monthly Value Review.
Building screens that help managers decide, instead of screens that add reporting work
A good Manager Cockpit starts with a conversation about which Outcomes matter, what the manager has to decide every day, and which information goes missing when an exception happens; choosing the charts comes later. DNA Maker works with executives and team leaders to turn this thinking into a KPI Dictionary, Decision Rights and an Escalation Flow that everyone can read and understand. Setting the business goals stays with the client. We help connect those goals all the way down to work status, evidence and the people responsible, without turning the dashboard into a tool for watching employees.
Once the decision structure is clear, we can develop a Manager Cockpit, a Decision Dashboard and an AI Agent that summarizes status, points out bottlenecks, prepares a Brief before meetings and routes issues to the right person with authority. The system might be a Web Application for the whole organization or a Mobile Experience for frontline supervisors, with Integration, Alerts, a Decision Log and role-based permissions. DNA Maker helps from the Workshop, Information Design and Prototype stages through to Software Development and Continuous Improvement. If you have plenty of reports but still can't answer "What do we need to decide today?", we can help turn that data into conversations that lead to action.
SOFTWARE ENGINEERING GLOSSARY
Software engineering glossary
There is no need to memorize this table. It is here so that executives, work owners and the development team can talk without each reading the terms differently. Read the meaning, the example and the question on the right, because these questions often bring hidden scope, risks and costs to light before development starts.
| Term | What it is | A simple example | What to ask the development team |
|---|---|---|---|
| Dashboard | A screen that brings data together to help with decisions. | A manager sees all the work at risk of missing its SLA on one page. | What does the user have to decide after seeing this screen? |
| KPI | A performance measure linked to a goal. | Measuring the time taken to close a case instead of the number of emails sent. | Is this number linked to an Outcome, and does everyone define it the same way? |
| Escalation | Passing an issue up to someone with authority when it goes beyond set limits. | An amount over the credit limit is sent to the manager. | Which conditions send an issue to whom, and how quickly do they have to respond? |
| Decision Log | A record of decisions and the reasons behind them. | Keeping a record of why an exception was approved. | What level of reasoning and evidence do we need to keep? |
| Role-based View | Different screens for different roles. | Executives see the overall picture; teams see their own work. | How much data does each role need to see to do its job? |