See the Work

A team can make its work visible and still be asked to prepare the weekly presentation describing it. The files are available. The decisions are written down. Someone has tried the tool. On Thursday afternoon, a person stops working to turn all of that into slides for people who could have looked.

The new visibility has added a task. It will become useful when somebody changes what they do because of it.

Workarounds tell us what people need

People use spreadsheets, scripts and unofficial tools because the available systems do not quite serve the work. The report comes too late. A form cannot express an exception. Information exists somewhere, but finding it requires knowing whom to interrupt.

AI gives people more ways to respond. They can compare files, make a small dashboard, draft a useful explanation or build the first version of something they have been asking for. What they choose to attempt tells us where the need is.

A technology team that encounters one of these tools has an opportunity to learn. What was the person trying to do? Why was this easier than the available route? Which part would they be reluctant to lose?

The answer may reveal a tool worth sharing. It may reveal a problem with the official service. It may show that the person found a good solution to something nobody else understood was a problem. The useful first response is curiosity, followed by whatever contribution the situation calls for.

Go close enough to understand

A spreadsheet is particularly revealing. Its columns contain a working vocabulary. Its strange formulas preserve exceptions. The person maintaining it often knows precisely which apparently tidy improvement would break the job.

Watching them use it is more informative than asking for a list of requirements. Ask what happens when a number is late, what decision depends on it, who receives the result and which parts need checking. The work supplies its own questions.

This also applies to AI use. An output count tells us little about whether someone has become more capable. A person comparing two alternatives, explaining a correction or showing where a tool misunderstood them gives us much more to work with.

A system can record activity. Understanding still takes attention. We want the record to help people get close to the work, instead of giving them a reason to remain far away from it.

Leave enough of a trail to contribute

In software, observability makes it possible to understand what a running system is doing. The useful organizational equivalent is the ability to find the work, understand the consequential choices and help with what happens next.

It can begin with very little: the actual working file, a short explanation of its purpose, the person using it and a source for the information that matters. If a colleague can open it, understand the problem and make a useful contribution, much of the job is already being done.

More detail earns its place when someone needs it. A repeated error may need a trace. A shared service may need a way to see interrupted work. A decision disputed every fortnight may need a clear record of who decided and why. These are reasons to preserve particular information, not an argument for recording everything.

The trail should live with the work where possible. Copying the same account into a registry, a dashboard and a weekly deck creates three more places that can become wrong. A useful summary points to its sources and makes a particular decision easier.

People should also be able to correct the account. An AI summary can turn an uncertain observation into a confident sentence. A completed ticket can conceal rework. A person who prevented a mistake may have almost nothing to display. Visibility that cannot be questioned will eventually mislead the people relying on it.

Leaders have to use what becomes visible

The people doing the work have a responsibility to make it understandable. Leaders have a responsibility to make a reasonable effort to understand it. Neither side can discharge that responsibility merely by sending the other a link.

Sometimes a leader needs to try the tool with its user. Sometimes they need a short explanation of a choice whose significance is not obvious. Sometimes they need to read the history before asking the team to retell it. The useful form depends on what is missing.

Once the work is understood, leadership can contribute something the team cannot supply alone. It can choose between competing priorities, make time for a colleague to learn, connect two groups, stop a redundant initiative or accept responsibility for a decision.

Suppose a team shows that two promised deadlines cannot both be met. The leader chooses which commitment changes and takes responsibility for explaining that choice to the people affected. The team can then act on the priority. Asking them for a more reassuring forecast would leave them carrying both the contradiction and the blame.

If a leader asks for more information, they should be able to explain what it will help them decide.

AI can make a weekly summary cheap to produce. It cannot make an unanswered decision less unanswered.

Let the evidence change the arrangement

A useful local tool does not automatically need to become a central service. Sharing it might help another team, or reveal that the teams do their work differently for good reasons. Wider use might justify a connection to an existing system. Sometimes an existing product is the right answer, and sometimes the tool can stay as it is.

The people using and maintaining it should take part in that judgment. They know where it helps and what its apparent simplicity costs. A technology team can bring knowledge of the wider system and help them avoid repeatedly solving the same technical problem.

There will be situations that need immediate attention: information handled somewhere it should not be, a broken process giving customers wrong answers, or a tool people depend on without anyone knowing how it works. Address the particular problem. Its existence does not establish that every useful experiment needs the same approval process.

Good organizational judgment makes the sensible route easier to take. That might mean arranging ordinary access, improving a shared tool, sitting with someone while they learn, or removing a rule whose purpose has expired. It should be possible to help without founding a program.

Retire the reporting that no longer helps

A status meeting can have several jobs. It may help people interpret a difficult situation, make a commitment or notice that someone needs support. Those are worth preserving. Reading facts aloud because the meeting is already on the calendar is a weaker proposition.

When a shared record answers the information need, use the time differently. Ask what still needs discussion and bring the people who can contribute to it. If nothing does, there may be no need to meet.

The same test applies to a new dashboard or AI-generated report. Who uses it? What does it help them do? What have they stopped asking someone else to prepare? If the answers remain vague, the apparatus may be getting more capable at describing activity without helping it happen.

A small experiment is often enough to learn. For the next few meetings, use the existing work as the source and bring only the questions people need to resolve together. Notice what is missing. Some reporting may earn its return; some may turn out to have been waiting for someone to stop.

The point of seeing the work is that we can do something useful with what we see. That includes changing management’s own habits, and recognizing when the most helpful contribution is to get out of the way.