When the appearance of progress replaces progress itself.
A working day has a recognizable shape in many companies. Meetings happen. Tickets move. Documents get reviewed. People present updates, discuss priorities, and prepare the next plan. Some of this structure is necessary. People need to coordinate, make decisions, and understand what others are doing.
But I think there is a point where the recognizable shape of work starts to replace its purpose.
The calendar is full. The board is active. Everyone has something to report. And yet it can be surprisingly difficult to explain what has become better for the customer, what problem the business has resolved, or what important uncertainty the organization has reduced.
Activity becomes easy to see. Its connection to an outcome becomes difficult to follow.
The more I think about this, the more some organizations start to resemble a theater. People have roles, scripts, and familiar ways of demonstrating competence. The engineer discusses technical complexity. The manager discusses priorities. The architect discusses the target state. The team presents progress.
But understanding how to perform a role is different from understanding why that role exists.
Somebody can know exactly what belongs in a planning document while having little understanding of the decision it is supposed to improve. Somebody can know how to conduct a meeting without knowing what needs to be resolved in it. The procedure gives the activity a shape while allowing its purpose to remain undefined.
Performing the procedure can be a safe way to demonstrate participation. There is something to deliver, something to discuss, and something to point to afterward. Actual impact is often more uncomfortable. A customer might not need what we planned to build. The problem might be different from the one described in the ticket. An investigation might show that an impressive initiative is unnecessary.
There is uncertainty in doing useful work. There can be much less uncertainty in producing the expected evidence of work.
Imagine a company discovering that new customers struggle to complete their first useful action in its product. The interface might be confusing. An integration might be failing. The product might ask for information customers do not have. The promise made during the sale might not match what the application actually does.
The useful work begins with understanding which of those things is happening. Somebody needs to observe the experience, examine failures, and speak with the people involved. Then the company can decide what to change and find out whether it helps.
But the organization can also generate an enormous amount of activity without getting much closer to the problem. A group prepares a roadmap. Another reviews the technical direction. A working group defines a new process. Teams estimate their part of a solution before the cause is clear. The initiative acquires a name, a presentation, and a reporting schedule.
The customer can still be stuck at exactly the same point.
Planning and coordination can be useful. Sometimes they are the most valuable things somebody can do. Their value depends on what they help us understand, decide, prevent, or change.
Software provides plenty of opportunities to lose that connection. We can spend months discussing the internal structure of a system without establishing what it needs to accomplish. We can introduce layers, services, frameworks, and conventions because they are recognizable signs of professional engineering. They can be useful, but they can also give us an intellectually satisfying problem to work on while the business problem remains unresolved.
The architecture becomes something we can defend. The outcome remains something we have not tested.
Consider a company that refuses to accept a pull request with more than five hundred changed lines. The intention might be reasonable: keep changes focused and make reviews manageable. But line count is only one signal of review difficulty. A large mechanical update can be straightforward to inspect, while a few lines changing an important business rule can require considerable care.
When the threshold becomes an absolute requirement, a coherent change may have to be split into dependent pull requests. Explanations are repeated, and reviewers have to reconstruct behavior across changes that belong together. Splitting work into independently understandable and safe steps can be valuable. Splitting it solely to satisfy a counter can make the complete change harder to review.
Compliance is easy to demonstrate. Every pull request stays within the limit. But the original purpose was a better review, and the number alone cannot tell us whether we achieved one.
I also think it would be too easy to explain the theater as individual laziness. Organizations can teach conscientious people to behave this way. If recognition depends on visible activity, polished communication, and adherence to approved procedures, people learn to produce those things. If questioning an initiative creates more personal risk than delivering its next update, continuing the performance can become the safer choice.
The incentives matter. So does the authority people actually have. A person assigned a narrowly defined task may have no access to customers, no ability to change the priority, and no permission to question the proposed solution. Expecting that person to own the entire business outcome while keeping every meaningful decision elsewhere creates another performance: the appearance of accountability without the conditions required to exercise it.
Leadership has a responsibility here. People need enough context to understand the problem, enough authority to make relevant decisions, and enough feedback to learn whether their work helped.
There is also a difference between distributing work and distributing responsibility until it becomes impossible to locate. A decision can pass through several groups and receive several approvals. But agreement among participants does not establish that it serves the business. If the result disappoints, the same chain of approvals can make it difficult to find anyone responsible for learning from it.
Everyone did their part. The problem remains.
Large organizations do need controls. A review can prevent an expensive mistake. Documentation can preserve knowledge. Coordination can keep groups from creating incompatible solutions. Maintaining reliable infrastructure can protect value without producing a new feature every week.
I think that makes judgment more important. We should be able to explain the risk a review addresses, the decision a meeting enables, or the dependency a process manages. An activity that exists primarily because it has always been part of the script deserves examination.
Business impact also includes contributions that are not immediately visible. Reducing failures, making a product accessible, preserving customer trust, and learning that a planned investment would be wasteful can all matter. Immediate revenue is an incomplete measure of useful work.
Even when the result is difficult to measure, we can make the intended contribution explicit and examine what we learn. An unsuccessful experiment can change what the organization understands. A successful presentation can leave everything important unchanged.
Stopping work can be progress too. Discovering that an initiative is unnecessary, removing a meeting that no longer enables a decision, or simplifying a process can all make an organization more effective. But an organization that only recognizes additions will keep producing things to add.
In earlier posts, I wrote about architecture becoming disconnected from the constraints and trade-offs it should serve. I think the same pattern can exist in the organization around the software. Processes become foundations. Roles become identities. Templates become obligations. Maintaining the structure becomes a considerable part of the work.
People can work very hard to keep that structure running. The exhaustion is real. The effort is real. That can make it harder to notice how little opportunity people have to understand what their effort is supposed to achieve.
I think a healthier organization makes the connection easier to follow. People can explain the problem, why it matters, what they are trying to change, and how they will learn whether the change helped. Meetings resolve things. Documents preserve useful decisions. Roles help people take ownership of something beyond performing the role itself.
Work does not have to be spectacular to matter. Sometimes the useful result is a small correction, a prevented failure, or a clearer understanding of what to do next.
But there should be a connection between the effort and the purpose.
A company can become very good at performing work.
The harder achievement is making that work mean something outside the performance.
Top comments (0)