We put in over 15 miles of snow farming fence at 8,954 feet above sea level without mechanical assistance, this was winter maintenance work at a ski resort, preparing terrain before the season opened. The work was cold, physically demanding, and genuinely beautiful. The system that made it possible was embarrassingly simple: a colour-coded map on the wall showing every section, with arrows indicating progression through numbered positions.
At that scale, in that environment, you need a system that works; the map showed everyone exactly where they were in the work and what came next. No ambiguity, no confusion about which section to work on or where materials needed to go.
I've been solving visibility problems for a decade in radically different contexts, manufacturing floors, maintenance teams, distributed ERP implementations. The symptoms look different every time: missed deadlines, frustration, broken trust, people working hard and getting nowhere. But the cause is always the same. When work is invisible, people fill the gaps with assumptions. They assume they're failing, that others don't care, that the work doesn't matter.
You can't fix morale or trust or delivery by addressing those symptoms directly. You have to make the work visible.
The Maintenance Team
The maintenance team worked almost entirely on production supervisors' direction. There were constant questions about whether they were completing planned preventative maintenance (PPMs) and attending breakdowns promptly. Both sides had their perspective, and from where each stood, they were right.
Production supervisors thought maintenance was unresponsive and only worked on what they wanted to. Maintenance felt understaffed and pulled from pillar to post, constantly interrupted, never able to finish anything. Neither side could see the full picture.
We implemented a Jira helpdesk to make the work visible. Maintenance could log jobs, track what they were working on, and see their queue. They accessed it on their phones—no need to go back to an office or find a PC. That mobility mattered, but what mattered more was what the system gave them: a priority list they could show to supervisors when someone tried to pull them off a job.
The reality neither side could see became immediately obvious once we had the data: constant context switching was destroying throughput.
Context switching is normally a software development term, but it applies to physical work as well. The team would attend a breakdown, start work, only to be pulled to a different, more urgent breakdown by another supervisor. Then interrupted again. Too much work in progress, nothing getting finished.
There was a physical cost to this. Packing up tools. Moving to a new location. Unpacking. Then the mental cost when they eventually returned: where was I with this job? What had I already checked? They were working hard—there were days, even weeks, where it felt like no matter how hard they worked they couldn't keep up. The frustration was visible.
Before the helpdesk, production supervisors from different areas would argue about whose issue was the highest priority. Once we could see all the work in one place, we started grading breakdowns. Critical equipment got priority, but other than that the maintenance team finished a job before moving to the next one.
The impact of finishing work was significant, more things were running because jobs didn't sit half-done. Morale improved because people could actually complete something instead of being perpetually interrupted.
But the data revealed something else: most of the breakdowns were on banding machines—small units but critical to the process. Without the ticket system, we wouldn't have been able to identify that pattern easily, and we certainly wouldn't have been able to quantify it. We trialled preventative maintenance on the banding machines first, and it significantly lowered breakdowns.
They didn't have ringfenced time for PPMs before this, which meant there were more breakdowns, which created more urgent work, which left even less time for PPMs. A reinforcing downward spiral.
It took time to build trust after the helpdesk went in, but the visibility of priorities helped. This evolved into the maintenance board being reviewed in daily production meetings. Everyone could see what production was working on and what maintenance was working on. They understood each other's pressure points and could work together to solve problems rather than argue about whose fire was bigger.
The maintenance team wasn't broken because people were bad at their jobs. Production supervisors weren't unreasonable. Maintenance wasn't lazy or unresponsive. Nobody could see what was actually happening. Once the work became visible, the problems became solvable.
Physical Systems for Physical Work
In the print factory, visibility took different forms depending on what needed to be visible.
As an estimator, I used to cut cards representing machine run time and place them on the production board. The board had physical space allocated for each machine's time. It was a simple system, but it prevented a specific, expensive problem: scheduling two jobs on the same machine at the same time.
On the factory floor, we set out a specific number of pallet spaces behind machines. This created a visual queue for team leaders, they could see immediately when they needed to get more work to a machine. Without that system, you'd get peaks and ravines: machines buried behind mountains of work in progress or running completely dry. Setting the right levels was tricky, especially for groups of machines like the folders that we knew had to be kept fed, but once it was visible, it was manageable.
Physical work made visible through physical systems. The principle was the same whether it was cards on a board or pallet spaces on a factory floor: people needed to see what was happening so they could make decisions without guessing.
Scale and Simplification
As teams scale or become distributed, the same principle applies but requires more deliberate effort. Communication gets harder, so the message has to be clearer. The tools and formats matter, if people have to learn new systems on top of understanding new work, visibility suffers.
The principle at scale is the same as at the individual level: if people can't see what's happening, they fill the gaps with assumptions. At enterprise scale, those assumptions just cascade further and break more things.
The Five Thieves
I read Making Work Visible[^1] whilst thinking about the ERP rollout. Dominica DeGrandis identifies five "thieves of time": too much work in progress, unknown dependencies, unplanned work, conflicting priorities, and neglected work. I realised I'd been fighting all five of them for years without having names for them.
Too much work in progress was the maintenance team being pulled from job to job without finishing anything, and pallet spaces behind machines preventing overload. Unknown dependencies showed up in ERP quarterly planning when teams needed things from each other that nobody had surfaced. Unplanned work was banding machine breakdowns before we implemented PPMs—you can't eliminate it, but you can see it coming and plan capacity for it. Conflicting priorities appeared in production supervisors arguing about whose breakdown mattered most before we had a grading system. Neglected work was the PPMs that didn't happen because there was no ringfenced time, creating more breakdowns, creating less time for PPMs.
The five thieves are real, but they're symptoms. The disease is invisibility.
What Actually Breaks
When work is invisible, three things break: trust, morale, and coordination.
Trust breaks when people fill invisible gaps with assumptions. Production supervisors assumed maintenance wasn't responsive. Maintenance assumed they were understaffed and nobody cared. Both were wrong, but neither had the information to see it differently.
Morale breaks when people work hard and can't see impact. The maintenance team packing up tools, moving to a new job, getting interrupted again, returning to half-finished work, never completing anything. Working hard but going nowhere is demoralising in a way that's difficult to overstate.
Coordination breaks when people work at cross purposes. Scheduling two jobs on the same machine. Running out of materials on a mountainside at altitude. Teams discovering dependencies mid-project that should have been surfaced in planning.
These aren't three separate problems—they're symptoms of the same cause. Make the work visible and the problems don't automatically solve themselves, but they become solvable. You can have conversations about priority instead of arguments about whose fire is bigger. You can measure impact instead of guessing whether effort matters. You can coordinate work instead of discovering conflicts when it's too late to adjust.
A Caveat on Tools
Jira worked brilliantly for the maintenance team and has consistently worked well in development teams I've led. But I've had mixed results with analyst teams. Visibility tools aren't universal. What works for one context doesn't automatically translate to another.
The tool matters less than the principle: can people see what's happening? Can they see what's blocked, what's in progress, what's next? Can they see their work mattering?
Sometimes that's a Jira helpdesk. Sometimes it's a colour-coded map on a wall. Sometimes it's pallet spaces behind a machine or cards on a production board. The form changes. The need doesn't.
Simple Systems, Beautiful Work
Back to the snow fence map. Fifteen miles at 8,954 feet, no mechanical assistance, genuinely beautiful work. The system was embarrassingly simple because it had to be. Arrows, colours, numbers. Everyone knew exactly where they were and what came next.
That's the standard. Not perfect information. Not comprehensive documentation. Just enough visibility that people can do their work without filling the gaps with assumptions.
When work is invisible, people assume the worst about themselves, about each other, about whether any of it matters. Make it visible and you give them something better than assumptions. You give them information they can act on, decisions they can make, work they can see mattering.
That's what making work visible actually does. It doesn't fix the problems. It makes them fixable.
[^1]: Dominica DeGrandis, Making Work Visible: Exposing Time Theft to Optimize Work & Flow (IT Revolution Press)