The Invisible Capacity Problem

A story about hidden capacity, autonomy, performance, and what organizations learn from work they cannot see. (15 minute read)

Consider a fairly ordinary situation in software development.

A developer joins an established team. Expectations are high. There is plenty to do and relatively little time for onboarding. The product is complex, the existing team members are busy with their own work, and much of the knowledge needed to become productive exists somewhere between documentation, code, experience and things everybody else simply knows.

Modern tooling should help. AI coding assistants can explain unfamiliar code, generate tests, summarize documentation and accelerate implementation. The new colleague is experienced. Nobody expects months of hand-holding.

After a few weeks, the developer works on the weekend. Nobody asked them to. There is no mail saying please finish this by Monday. No manager has formally ordered overtime. The employee does not record the additional hours.

Asked why, the answer might be:

I needed the time. Otherwise I wouldn’t have got through what I was supposed to get through.

The scenario here is deliberately composite. None of its elements is particularly unusual, and the point is not whether one individual case happened exactly this way. The interesting question is what happens organizationally when expected work is completed only because somebody supplies capacity the organization neither planned nor sees.

Was the weekend work voluntary? Yes. And that does not end the inquiry. The question is not who is to blame, but what information an organization loses when additional effort remains invisible.

I. Nobody ordered it

The simplest interpretation is perfectly plausible. The employee decided to work. They may be ambitious or absorbed in an interesting problem. They may be a perfectionist. They may work inefficiently or have misunderstood what was expected.

Adults retain agency. Autonomy becomes meaningless if every undesirable decision is retrospectively redefined as something the organization forced them to do. But choices take place inside systems.

For a new team member in particular, the alternatives may not feel symmetrical. One option is to say: I am not getting through this as quickly as expected. The other is to quietly spend another evening on it and appear on Monday with the expected result.

The first provides useful information to the organization. It may also feel personally risky.

A new colleague has little accumulated credibility. They do not yet know what is genuinely difficult in this environment and what they are expected already to know. They cannot easily tell whether taking two days where somebody else takes one is normal onboarding friction or evidence that they are underperforming. Asking for more time can feel like announcing a weakness before anybody has had the chance to see their strengths.

Quietly absorbing the difference can therefore be individually rational. Nobody needs to threaten them, suggest working on Saturday, or even deliberately set unrealistic expectations. The safer strategy may simply appear to be: meet the expectation first and deal with the cost privately.

Mazmanian, Orlikowski and Yates described a related mechanism in their 2013 study of knowledge professionals and mobile communication technology as the autonomy paradox: tools that increased individual flexibility and control also contributed to escalating norms of availability and engagement. Individual acts experienced as expressions of autonomy collectively changed expectations about how work should be performed.

That does not mean autonomy produces overload. It means autonomy does not remove the system surrounding the choice. The organization says: You own the result. The individual decides where the capacity necessary to produce that result comes from.

So far, everybody may believe the system is working.

II. Where the missing capacity goes

Now look at the work itself.

An experienced developer who has spent five years with a product may solve something in a day. A new developer may need three. The difference is not necessarily competence.

They may need to discover why an apparently strange architectural decision exists. They need to know which documentation is current, which automated tests are reliable, which dependency cannot safely be changed and which stakeholder needs to be involved before an apparently technical decision is made.

Much of that knowledge cannot simply be downloaded. Someone has to explain it, answer questions and review work more closely. Pairing temporarily makes two people appear to produce the output of one.

That genuinely reduces short-term throughput. The argument is not that onboarding, teaching or pairing are free. It is that their cost exists whether the organization recognizes it or not.

If the organization does not provide capacity for learning during working time, learning does not disappear. The cost moves. It may move into slower delivery, reduced quality, technical debt, less documentation or less support for colleagues. And sometimes it moves into evenings and weekends.

The organization has not avoided the cost of onboarding. It has merely changed where that cost appears.

III. When extraordinary effort becomes normal performance

Suppose the additional effort works. The expected item is completed, the deadline is met, the working-time record shows normal hours, the manager sees no escalation, and the team sees the work moving.

From the perspective of the organization, the expectation was therefore reasonable. This is the important mechanism: The hidden work validates the expectation that caused the hidden work.

What actually happened was:

expected work → insufficient visible capacity → private additional effort → expected result

What the organization sees is:

expected work → expected result

The missing information changes the conclusion, and that can change the next expectation.

Imagine two developers. Developer A delivers eight items during normal working time. Developer B delivers ten, but privately spends another six hours on the work.

Who performed better? The correct answer is not A or B. We don’t know.

The number of completed items tells us nothing about maintainability, defects, complexity, mentoring, documentation, architectural contribution or whether both developers were even working on comparable problems. Nor are hours themselves a useful proxy for value. But if the additional input required to produce the output is invisible, we know even less.

The danger is not simply that management might reward B. The more interesting problem is that ten can gradually become evidence for what is achievable.

Perhaps a planning discussion starts with the amount delivered last time. Someone remarks that the previous target was met without difficulty. A forecast quietly becomes the starting point for the next forecast. The extraordinary quietly becomes evidence for what is ordinary.

Nobody needs to announce a competition. This is one way a performance culture can generate pressure without anybody explicitly promoting an overwork culture.

High performance itself is not the problem. The question is what the system learns from the performance it observes.

IV. Uncertainty makes this harder, not easier

There is an important alternative explanation.

The workload may have been reasonable. The developer may lack a skill they were expected to have, spend too long polishing something or fail to ask a simple question. The estimate may simply have been wrong. Scope may have changed. A dependency may have appeared that nobody could reasonably have predicted.

Software development contains uncertainty. There does not need to be a villain.

This matters because weekend work is not proof that an organization has overloaded somebody. In fact, that is almost the opposite of the argument. Once additional effort disappears from view, the organization loses precisely the information it would need to determine what actually happened.

Was the expectation unrealistic? Was onboarding insufficient? Was the work unexpectedly complex? Does somebody need support? Was the original estimate wrong? Did the employee misunderstand the priority? Is there a genuine performance problem?

Those are questions about the individual case. They require evidence. The broader systemic question is whether the organization is receiving enough information to answer them at all.

A system that wants high performance should therefore be interested in phrases such as This does not fit. This is taking longer than expected. I need help. We underestimated this.

Those are not necessarily failures of commitment. They are information about reality.

If people learn that providing this information threatens their standing while silently compensating protects it, the organization trains its own sensors to stop reporting.

V. And then we add AI

AI makes this more interesting because it introduces another productivity expectation whose actual size is difficult to know.

There is good evidence that generative AI can increase productivity. Brynjolfsson, Li and Raymond (2023) studied 5,179 customer-support agents and found an average productivity increase of about 14%, with substantially larger gains among novice and lower-skilled workers.

Cui and colleagues, in field experiments across Microsoft, Accenture and an anonymous Fortune 100 company involving 4,867 developers, found about 26% more completed tasks among developers given access to an AI coding assistant, again with stronger effects among less experienced developers. The work has since been published in Management Science.

There is also evidence pointing in a very different direction. In a randomized study by METR, Becker and colleagues (2025) found that experienced open-source developers working in repositories they knew well took 19% longer when allowed to use early-2025 AI tools. Before the study the developers expected AI to make them faster; afterwards they still believed it had done so.

These figures should not be compared as though they measure the same thing. They involve different work, populations, tools and measures of productivity. That is precisely why they matter here.

“AI increases productivity” can be true without there being a universal productivity multiplier that can safely be applied to a team.

AI may help a newcomer understand an unfamiliar API remarkably quickly while being poor at explaining why a peculiar decision was made three years ago. It may generate an implementation faster while increasing review effort. It may accelerate coding while having little effect on stakeholder coordination, architecture, testing or discovering what should be built in the first place.

The effect is contextual. AI can therefore be an excellent onboarding and productivity tool. But AI exists is not a capacity plan.

If an assumed productivity gain is converted into higher expectations before its actual effect in the specific environment is known, any benefit may be consumed before the organization even knows whether it exists. The employee still has autonomy. The target simply moved.

VI. What autonomy depends on

Douglas McGregor gave us useful language for looking at this problem more than sixty years ago.

Theory X and Theory Y describe contrasting assumptions about people at work. Theory X assumes that people generally resist work and responsibility and therefore require direction, external incentives and control. Theory Y starts from very different assumptions: people can seek responsibility, exercise self-direction and commit themselves to meaningful objectives when the surrounding conditions allow it. McGregor developed the distinction in The Human Side of Enterprise in 1960.

Most contemporary technology organizations speak overwhelmingly in the language of Theory Y: ownership, autonomy, empowerment, trust, self-organization, accountability. There is good reason for that.

The problem begins when we mistake removing direct control for creating the conditions in which autonomy can actually function.

Nobody controls when our developer opens the laptop, and nobody orders the weekend work. The person is trusted to manage the work themselves. But imagine that saying “this doesn’t fit” carries more perceived risk than quietly making it fit.

The formal mechanism is autonomy. The functional mechanism starts looking rather different: Theory X with a Theory Y user interface.

This does not mean autonomy is disguised control. It describes a specific contradiction: an organization can adopt Theory Y language while maintaining performance criteria and structures that still depend on compliance, individual pressure and expectations people do not feel safe challenging.

McGregor’s deeper contribution was not simply telling managers to trust people more. He was interested in the assumptions embedded in organizational structures, policies, performance criteria and rewards. He warned that these systems can teach behaviours different from the ones management says it wants.

If we tell people to take ownership but reacting early to a capacity problem damages their reputation, we should not be surprised when they take ownership by hiding the capacity problem. People learn the real rules of a system from consequences, not slogans.

VII. A team, or several people working near each other?

McGregor also made an observation that feels remarkably contemporary: many things called teams are really collections of individual relationships rather than teams in any meaningful sense.

Software organizations can reproduce this surprisingly easily. We share a Jira board, attend a Daily and work on the same product. Therefore we are a team.

But the more interesting question is where responsibility goes when something does not fit.

If one developer cannot complete an item within the expected time, is that primarily their task, their estimate, their problem, or is it information requiring a response from the team?

A new member lacking context can be treated as an individual deficit. Or the same situation can be treated as a temporary capability gap in the team. The second interpretation produces different behaviour: someone pairs, knowledge is transferred, work is redistributed, expectations change.

The team temporarily accepts lower throughput because increasing its future capability is itself part of the work. Again, this is not free. It is simply visible.

Unavoidable specialization does not change the principle. People will know different things. Some will be faster at particular tasks. Senior developers will carry knowledge newer colleagues do not possess. A team does not eliminate those differences. It prevents every capacity mismatch from automatically becoming a private problem.

Group pressure can work in the opposite direction. If everybody else appears to cope, struggling becomes evidence about the individual. If everyone else answers messages late, late availability becomes normal without ever becoming policy. If experienced colleagues silently complete difficult work outside ordinary hours, newcomers learn the standard from what they observe.

Nobody has to tell anybody to work more. Culture is partly what people infer from watching what succeeds.

VIII. There is also a legal boundary

So far this is an organizational argument. In Austria, there is also a legal one.

Working time and rest are not matters that become irrelevant simply because work is described as voluntary. Employees are generally entitled to an uninterrupted weekly rest period of at least 36 hours that includes the whole Sunday, subject to the exceptions provided by law and other applicable instruments. Actual working time must be recorded, and responsibility for those records remains with the employer even where employees themselves enter their hours.

Nor does the absence of an explicit overtime order necessarily settle every question. Austrian Supreme Court case law recognizes circumstances in which an employer that knowingly accepts necessary overtime cannot refuse compensation merely because it was not formally ordered. Where the necessity is not obvious, the employee’s obligation to inform the employer can also matter. The assessment depends on the circumstances of the individual case.

There is also a broader occupational-health perspective. Austrian employers must evaluate psychological working conditions, and the Labour Inspectorate explicitly identifies strong time pressure and work overload among common work-related psychosocial risk factors.

None of this means that every person voluntarily reading code on Sunday creates the same legal situation. It means something much narrower and more relevant to this discussion: “Nobody ordered it” is not a sufficient organizational control.

An organization still needs to understand how work is actually being performed.

IX. The wrong investigation

Suppose leadership becomes aware that people may be compensating privately.

The most obvious next question is also potentially the most damaging one: Who is working on weekends?

For the problem described here, that may be the wrong investigation.

If somebody already fears that needing extra time will be interpreted as poor performance, identifying them and asking them to explain themselves confirms exactly that fear: Why did you need longer? Why didn’t you ask for help? Why didn’t you record the time? Why didn’t you follow the working-time rules? Why couldn’t you complete what everybody else completes?

A structural signal has now become an individual case. Everyone else learns from the response.

Section IV asked what might explain one particular case. The questions here are different. They ask whether the system makes such cases more likely and whether it allows us to see them when they occur.

What do we expect from somebody three weeks into the team? How much capacity do we actually reserve for onboarding, and who supplies that capacity? When an experienced developer pairs with a newcomer, do we treat that as productive work or lost output?

How do we know whether assigned work fits into ordinary working time? What happens when somebody says that it does not? How do estimates react to uncertainty? Are AI productivity gains measured in our environment or assumed?

Are individual outputs compared without understanding the inputs behind them? When somebody is behind, does the team change the plan or does the individual own the gap? What signals might currently disappear before leadership ever sees them?

And perhaps the most important question is this: What would happen to someone who said early and repeatedly, “I cannot get all of this done within my available working time”?

The answer tells us considerably more about performance culture than any value statement does.

X. What would the functioning version look like?

None of this requires abandoning high expectations.

Imagine the same developer joining the same demanding team. The organization expects them to become productive, but reduced initial output is explicitly expected rather than quietly tolerated.

Pairing and knowledge transfer are treated as part of the team’s work. When an experienced developer spends half a day explaining the system, the organization does not pretend that half-day was free.

The first estimates involving the new colleague are treated as uncertain. When a task takes longer than expected, the first response is to understand why. The task may change. Somebody may help. The expectation may turn out to have been wrong. The developer may need to learn something.

And after examining the evidence, there may genuinely be an individual performance issue. Nothing in a systemic approach prevents that conclusion. It simply prevents us from jumping there before examining the system that produced the result.

AI is available and encouraged where useful, but its productivity effect is observed rather than presumed. Most importantly, “this does not fit” changes the plan before it changes the employee’s private life.

That is not a low-performance culture. Arguably, it is a more demanding one. It demands accurate information, refuses to improve delivery numbers by hiding inputs, expects teams to deal with problems rather than allowing individuals to absorb them indefinitely, and distinguishes commitment from donated capacity.

It also requires leadership to make decisions based on the system that actually exists rather than the one suggested by apparently green indicators.

Nobody needed to tell our developer to work on Sunday. There are many possible reasons why they did: a freely chosen exception, an inaccurate estimate, insufficient onboarding, unexpected complexity, inefficient work or excessive expectations.

The individual case may never provide a clean answer. But if expected output repeatedly depends on effort that remains invisible, the organization has a problem even before it knows which explanation is correct. It has lost information about the real cost of its own performance.

And once hidden effort makes unrealistic expectations look realistic, the system can begin reinforcing itself.

That is why the useful question is not Who worked on Sunday?

It is: What do people have to hide in order for our system to appear to work?

---

Sources and references

Organizational behaviour and autonomy

Mazmanian, M., Orlikowski, W. J., & Yates, J. (2013).
The Autonomy Paradox: The Implications of Mobile Email Devices for Knowledge Professionals.
Organization Science, 24(5), 1337–1357.
https://doi.org/10.1287/orsc.1120.0806

McGregor, D. (1960).
The Human Side of Enterprise. McGraw-Hill.
Background overview: https://mitsloan.mit.edu/institute-work-and-employment-research/douglas-m-mcgregor

AI and productivity

Brynjolfsson, E., Li, D., & Raymond, L. R. (2023).
Generative AI at Work. NBER Working Paper 31161.
https://doi.org/10.3386/w31161

Cui, K. Z., Demirer, M., Jaffe, S., Musolff, L., Peng, S., & Salz, T. (2026).
The Effects of Generative AI on High-Skilled Work: Evidence from Three Field Experiments with Software Developers.
Management Science.
https://doi.org/10.1287/mnsc.2025.00535

Becker, J., Rush, N., Barnes, E., & Rein, D. (2025).
Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity. METR.
https://metr.org/blog/2025-07-10-early-2025-ai-experienced-os-dev-study/

Austrian working-time and occupational-safety context

Arbeitsinspektion Österreich.
Grundsätzliches zur Arbeitsruhe.
https://www.arbeitsinspektion.gv.at/Arbeitszeit-_Arbeitsruhe/Arbeitsruhe/Grundsaetzliches_zur_Arbeitsruhe.html

Arbeitsinspektion Österreich.
Aushang und Aufzeichnung der Arbeitszeit.
https://www.arbeitsinspektion.gv.at/Arbeitszeit-_Arbeitsruhe/Arbeitszeit_/Aushang_und_Aufzeichnung_der_Arbeitszeit.html

Oberster Gerichtshof, 27 June 2023, 8 ObA 29/23g.
RIS decision record.
https://www.ris.bka.gv.at/JustizEntscheidung.wxe?Abfrage=Justiz&Dokumentnummer=JJT_20230627_OGH0002_008OBA00029_23G0000_000&IncludeSelf=True&ShowPrintPreview=True

Arbeitsinspektion Österreich.
Arbeitsplatzevaluierung psychischer Belastungen.
https://www.arbeitsinspektion.gv.at/Gesundheit_im_Betrieb/psychische_Belastungen/Arbeitsplatzevaluierung_psychischer_Belastungen.html