Most organizations don't have a visibility problem. They have a work-management problem. We collect data, report it, reconcile it, analyze it, build dashboards around it, then ask the people doing the work to stop and tell us what the data already knows. Reporting becomes a second job.
The fix isn't less governance. It's understanding what the work needs before you design the system around it.
Enterprise governance sets the boundaries: legal, regulatory, financial, cybersecurity, privacy, safety. PMO governance sits closer to execution: accountability, decision rights, intake, escalation. It should establish the guardrails. It shouldn't become the workflow.
I learned this managing creative operations and traffic. A project came in through a creative brief. Leads assigned a writer and a graphic designer, who worked in parallel through review, iteration, proofing, production, launch, and measurement. What mattered wasn't the number of steps. It was that everyone knew the handoffs: how long each stage should take, where the work went next, how much padding we'd built in to absorb normal variation. I didn't have to ask where we were. I could look at the workflow and know. That's the difference between visibility and reporting: the state of the work is visible as a byproduct of the work, not a narrative someone builds about it.
We kept the automation light-touch by design. Finish a concept, upload it, name it, tag the version, send it to review. The system routed and notified. The lead signed off. The next trigger moved it forward. The value was never the technology. It was that the technology removed work.
I learned the opposite lesson later, at an organization running Teams, SharePoint, and a handful of tools that didn't talk to each other. The new systems didn't eliminate work. They added a place to add work: more procedures, more reports, more stops. Technology had been added; the work hadn't been redesigned. That's the trap: digitize the existing process, and employees still do the work, but now they also maintain the platform, reconcile it against something else, and report out of it. One question before you buy anything: does this remove a step, or add one?
Capacity is the other half of the system. Realistic cycle times require knowing how much work the team can absorb: productivity analysis, once built on timesheets and spreadsheets. [Today that's AI, Excel, Tableau, or Power BI; name whichever you actually used.] Tools change. The principle doesn't: know the system's capacity before you decide how much work to put through it.
That gave us a right of refusal. At capacity, we could send work to a vendor instead, based on timing and lead time. A 24-hour rush a vendor could turn in 24 hours didn't need to blow up the internal workflow. We could scale up or down with seasonality. The team still owned delivery; they just had the authority to manage the capacity behind it. Capacity is a design constraint, not a character flaw. An overloaded system doesn't get fixed by telling people to work harder. It gets fixed by reallocating, reprioritizing, outsourcing, automating, or saying no, before the whole team is underwater.
That's also what reporting should be for. If a three-day stage takes five, I don't need a weekly narrative explaining it. I need the deviation itself to surface, so I can investigate: an alert, an escalation, a bottleneck review, a root cause. That's what buys you bandwidth: managing exceptions instead of running the machinery.
Governance follows the same logic, calibrated to what can actually go wrong. Manufacturing needs guardrails around safety and delivery risk. Technology needs them around cybersecurity and data. Different bumpers for different gutters. But governance can also overshoot: reading team chats for sentiment, inferring mood, demanding documentation to prove work happened. That's surveillance, not governance. The goal isn't knowing everything about the people doing the work. It's making the work visible enough that they stop having to explain it.
Which is the rule I keep landing on: figure out what the work needs before you design anything. Not the framework first, not the software, not the dashboard. Start with the work: what enters the system, who touches it, where the handoffs are, what capacity exists, what the team can decide without escalating, what actually requires governance. Then build the smallest system that answers those questions.
I've watched people produce more than expected when the system around them was built to let them succeed. I've also watched good people get buried in stopgaps and redundant reporting. That's not a people problem. It's a system problem, and it's solvable.