Why an operating view should help run the work, not merely report on it A spreadsheet can contain every number you need and still fail to tell you what is happening. That distinction became important to me long before “dashboard” became a word people attached to every collection of colored boxes. Operations generate information constantly.
Jobs start. Jobs finish. People become available. People become unavailable.
Work waits. Exceptions appear. Customers respond. Customers do not respond.
Documentation gets completed. Documentation gets missed. Cycle times change. Tomorrow's workload starts forming while today's work is still underway.
The information exists. The problem is whether the operation can see itself. That was the problem behind Control Room. The goal was not another dashboard.
It was an operating view.
NOT A CLASSROOM — AN ENGINE ROOM
I eventually described the concept with a phrase I still like: Not a classroom — an engine room. That is the distinction. A classroom explains what happened.
An engine room is where you operate the system. Traditional business reporting often arrives after the useful decision window has closed. The shift happened. The week happened.
The quarter happened. Now assemble the numbers. Make the slides. Explain the variance.
That has value, but it is not control. Control requires enough visibility to change what happens next. What is scheduled? What is dispatched?
What is active? What is completed? Who is available? Where is the exception?
Who asked for help? What documentation is incomplete? What is the response time? What is the cycle time?
How many jobs are moving? Where are the delays? Are we growing? Are we ready for tomorrow?
Those questions describe an operation, not a presentation.
THE SPREADSHEET WAS NOT WRONG
I have a lot of respect for spreadsheets. I have built enormous portions of operating systems in them. They are flexible, inspectable and fast. The problem is not the spreadsheet.
The problem comes when information designed for analysis becomes the interface for live execution. A table may contain the answer. That does not mean the answer is visible. If a manager has to know which tab, which column, which filter, which time range and which exception code to inspect before they can understand the current state, then expertise is compensating for the interface.
That works until it doesn't. The expert goes home. The building changes. The operation scales.
The number of inputs grows. The spreadsheet becomes a ritual. Copy this. Paste that.
Refresh this. Send that. Color this cell. Build the weekly view.
Now the information system has become work. Control Room was an attempt to reverse that relationship. The work should generate the information. The information should help operate the work.
MEASURE FIRST. REASON SECOND.
One of the principles I use is: Measure first. Reason second. That sounds almost too simple. It is not.
Humans are extraordinarily good at explaining things before establishing what happened. Volume was high. Staffing was low. Customers were difficult.
The system was slow. Training was weak. Maybe. First establish the state.
How many? How long? Where? When?
Compared with what? Which segment? Which employee? Which job type?
Which point in the process? Then reason. A useful Control Room does not replace reasoning. It protects reasoning from beginning with fiction.
The operating view gives people a common state to reason from. That matters enormously when multiple teams are involved. Without a common state, every department can be correct from its own perspective and the business can still be wrong.
THE EXCEPTION IS THE WORK
A well-designed operation should not require a manager to stare equally hard at everything. Most work is normal. Normal work should move. The manager's attention belongs where the system cannot resolve itself.
The exception. The delayed job. The missing documentation. The person asking for help.
The route that is failing. The customer who has not received the expected response. The task that did not transition. The resource that is unavailable.
That is why I think good operating software should be opinionated about attention. Do not make the user search the entire system to discover what is abnormal. Surface the abnormal condition. Then provide enough context to act.
This is similar to how I learned to operate physical systems. You do not improve a fulfillment center by staring equally at every package. You find where flow is stopping. You follow the bottleneck.
Software should help the operator do the same thing.
QUARTERLY REPORTING SHOULD BE AN OUTPUT, NOT A PROJECT
One of the things that bothered me was how much management time could disappear into reporting. The organization already had the information. Then a human had to reconstruct it into another form so somebody else could consume it. Every quarter.
Again. Again. Again. There is judgment in reporting.
There is also enormous repetition. Those are not the same thing. If the system already knows when work was scheduled, dispatched, started and completed, the manager should not manually rebuild those timestamps into a quarterly story. If the system already knows how many jobs occurred, the manager should not count them again.
If the system already records exceptions, the manager should not reconstruct the exception history from memory. Generate the baseline. Let the human explain. That is a better division of labor.
Software handles repeatability. Humans handle meaning. A floor manager's value is not their ability to copy information between systems. Their value is knowing why the number matters and what to do about it.
THE WAITLIST WAS THE SIGNAL
Control Room eventually attracted a large internal waitlist — roughly 2,000 people within about a month, as I remember it. That number matters less to me as a popularity metric than as evidence of unmet need. People do not line up for another dashboard because they are emotionally attached to dashboards. They line up because their current work hurts.
Something is fragmented. Something is repetitive. Something requires too much manual translation. Something is difficult to see.
Something takes twenty minutes that should take two. The waitlist said the friction was not isolated. The need existed across more than one person's workflow. That is how useful internal software often starts.
Not with a product strategy. With somebody saying: Why is this so hard? Then enough other people see the solution and say:
I need that too.
THE APP THAT CAME BEFORE IT
Control Room did not appear out of nowhere. One of its ancestors was a much smaller app I built around the needs of an employee who could not read. That tool was eventually broken apart — I have described the implementation as being shredded into roughly 125 pieces, with links and CSS removed. But the design idea survived:
The interface should fit the work and the person doing it. Do not require the human to navigate the organization of the underlying systems. Bring the useful state to them. That principle scales surprisingly well.
For one employee, it means: Can you make the next correct action obvious? For a manager: Can you make the next important exception obvious?
For an operation: Can you make the current state legible? For an executive: Can you make the trend visible without destroying the underlying context?
Same design problem. Different altitude.
A CONTROL ROOM IS NOT A SCOREBOARD
Scoreboards are useful. They answer: How are we doing? A control room has to answer more.
What is happening? Why does it matter? Where should attention go? What can still be changed?
What has already become history? What is likely to happen next? Those are operational questions. A metric that cannot change a decision may still belong in a report.
It probably does not deserve prime real estate in a live control surface. That is an important filter because dashboards tend to accumulate. Someone asks for a number. Add a tile.
Someone else asks for another number. Add another tile. Soon the dashboard is a digital junk drawer containing everything anybody has ever wanted to know. The operator has more information and less visibility.
A control room should be designed around decisions. What decisions happen here? What state does the person need before making them? What exception should interrupt their attention?
What history helps them interpret the exception? What action follows? That is interface architecture.
THE OPERATION SHOULD LEAVE A TRAIL
Another thing I value is that good operating systems create useful history as a byproduct. If work transitions through defined states, the system can retain those transitions. Now the business can answer questions later without reconstructing the past from anecdotes. When did delays begin?
Which job types are changing? Where does work dwell? Which exceptions repeat? How often does someone ask for help?
How long does recovery take? What did yesterday's problem do to today's readiness? That history improves forecasting. It improves training.
It improves process design. It improves customer communication. It improves the next version of the software. This connects to a broader principle I use in business systems:
Do the work once. Let the value keep working. A completed job can create revenue. It can also create documentation. Knowledge.
Training. Customer education. Operational data. Evidence.
A better forecast. A better next job. That is much more powerful than treating every task as disposable the moment it is complete.
THE CONTROL ROOM SHOULD KNOW TOMORROW EXISTS
A lot of operations software is obsessed with now. Now matters. Tomorrow is already being created by now. A job delayed today may become tomorrow's backlog.
Missing documentation today may become tomorrow's customer call. A staffing gap tomorrow may change what should be dispatched today. A piece of equipment that is not recovered tonight may become the morning constraint. So readiness belongs in the operating view.
Are we ready for tomorrow? That question is deceptively good. It forces the system to look across boundaries. Today's output is not necessarily today's success if it creates tomorrow's failure.
That lesson came from physical operations too. A shift can make its own metrics look excellent by leaving somebody else a mess. A building can optimize itself by sending a problem downstream. A department can transfer work and call the transfer completion.
Control Room thinking tries to resist that. The state includes consequences.
AUTOMATION SHOULD REMOVE CLERICAL GRAVITY
There is a force inside organizations that pulls skilled people toward clerical work. Every new system creates another login. Every new metric creates another report. Every new requirement creates another field.
Every new meeting creates another preparation ritual. Individually, each request is reasonable. Collectively, they can consume the people hired to run the operation. I think of that as clerical gravity.
Good automation should push against it. Do not automate the manager's judgment. Automate the scavenger hunt required before the manager can use judgment. Do not automate the employee's humanity.
Automate the repetitive state transitions that make the employee spend less time being human. Do not automate communication into meaningless noise. Automate the assembly of accurate context so the communication can be better. That is the kind of software I like.
THE BEST CONTROL ROOM DISAPPEARS INTO THE WORK
The highest compliment for operational software is not: This dashboard is beautiful. It is: Of course that's how we do it.
The tool becomes part of the operating rhythm. People stop thinking about the fact that information used to live in five places. They stop remembering that the quarterly report used to take hours. They stop thinking about the old scavenger hunt.
The friction disappears. That is success. A control room should not become a monument to the person who built it. It should become infrastructure.
THE SPREADSHEET BECAME SOMETHING ELSE
The evolution from spreadsheets and small tools toward Control Room was not about abandoning spreadsheets. It was about recognizing when the information had become operationally important enough to deserve an interface built around the work. The raw material was already there. Jobs.
People. Exceptions. Times. Delays.
Documentation. Customers. Tomorrow. The question was whether those pieces would remain scattered facts or become a coherent operating state.
That is what a control room does. It makes the operation visible to itself. Not so somebody can admire the numbers. So somebody can act.