The Cost of Output Is the Judgment It Consumes
Suppose you add an engineer to a team, and that person starts producing a lot of work. More tickets get completed, more code gets written, and there is more activity to report. But now someone else has to spend a substantial part of their week figuring out whether the work makes sense. They are reconstructing assumptions, correcting decisions, and explaining how the pieces should fit together. How much productivity did you actually gain?
You may still have gained useful capacity. But the answer cannot be the volume of output alone, because some of that output has created work for someone else. The engineer’s compensation is one cost. The attention required from the rest of the team is another. And when that attention belongs to someone who can resolve difficult, ambiguous problems, its opportunity cost can be substantial.
A clearly defined task contains decisions someone has already made. Someone understood the problem, chose an approach, set boundaries, and determined how to evaluate the result. The person implementing it can move quickly because that reasoning is available to them. If that reasoning hasn’t happened, it remains someone’s responsibility, whether anyone has explicitly assigned it or not.
Consider a hypothetical application where users keep seeing inconsistent information. An engineer decides the application needs a cache and builds one. The implementation can be perfectly competent: requests are faster, tests pass, and the component behaves as designed. But suppose the inconsistency comes from the way updates move between systems. The cache has not addressed that problem and may have introduced another way for old information to persist. Now the team owns a cache. Someone has to understand its behavior, maintain its configuration, and decide what should happen when the underlying data changes. Other work may begin relying on it. Before correcting the original decision, a senior engineer has to determine why it was made and how far its consequences have spread. A mistake in categorization has become an implementation, and the implementation has become an obligation.
That is the cost of wrong judgment. The cost includes the work performed, the work created around it, and the work required to change direction. The longer an incorrect assumption remains unexamined, the more decisions can accumulate on top of it. Producing those decisions quickly does not make them inexpensive to reverse.
Output therefore needs to be evaluated against the objective. Completed tickets tell you that tasks were completed. They do not tell you whether the tasks should have existed. A feature can satisfy its specification while doing little for the business. A component can function correctly while adding complexity the system never needed. Sometimes the most valuable engineering contribution is establishing that a proposed build can be much smaller, or that the existing system already provides what is required.
One particularly challenging aspect is that avoided work is less visible than produced work. You can point to a new component, but it is harder to point to the weeks of development that were avoided because someone understood the problem properly. Yet a decision that simplifies the solution and avoids unnecessary work will usually create more value than a large implementation by preserving the team’s ability to spend time on something else.
Senior attention is what makes this possible. When an experienced engineer has to spend an afternoon retroactively reconstructing another person’s approach, they cannot spend that afternoon resolving a different architectural question or investigating another difficult problem. Repeatedly consuming that senior attention by requiring them to clean up after junior team members will leave the team with more people but no more operational capacity.
This does not mean juniors are inherently a burden. A thoughtful junior can make excellent use of guidance. They can identify what they do not understand, make their assumptions visible, and bring a specific question to the team before committing to an implementation. The senior person supplies a missing piece of judgment, and then the junior carries the work forward. As their understanding develops, they need less help with similar problems and grow into a senior team member over time.
The opposite pattern is more expensive and slows the learning process. If someone proceeds through uncertainty without recognizing it, they may produce a substantial amount of work. If they then hand the result to a reviewer who inherits the problem definition, model choice, and decomposition, along with the code, a request for review becomes a request to redo the reasoning. And years of experience are not the driving factor: an experienced engineer can create exactly the same burden if they apply familiar approaches carelessly.
AI-assisted development makes this relationship more pronounced, especially when it speeds implementation. A person can produce more before their understanding has been tested. The tool may help them explore the problem, but AI’s tendency to be sycophantic and reinforce the user’s assumptions means it can often help them elaborate an incorrect approach. Production capacity and judgment do not necessarily improve together.
Much of this can be addressed by moving judgment earlier. An engineer can explain the problem, the proposed model, and the decomposition before building the whole thing. Reviewing that reasoning gives the team a chance to correct a mistaken assumption while the consequences are still small. It also creates a better learning opportunity: the person understands why the direction changed, rather than simply receiving edits to a finished implementation.
Review and teaching are worthwhile investments when they produce useful work and greater independence. The question is what happens over time. Does the engineer begin recognizing the relevant problems and making better decisions? Does the senior person’s involvement become more focused? Or does every new assignment return the same unresolved responsibility to someone else?
When buying engineering capacity, we need to account for both the useful contribution and the judgment it requires from the organization. A person who frees experienced colleagues to work on harder problems creates leverage. A person who produces work those colleagues must repeatedly reinterpret may consume it. Faster output makes that distinction more consequential, because the bill for judgment still has to be paid.
