Quantum Skills: Why More People Are Not More Capacity Without the Right Skills
- Kenneth Linnebjerg
- 15 minutes ago
- 9 min read
The familiar response to a delayed program
A transformation starts falling behind. Several teams are waiting for decisions. Features are not ready when development begins. Architects are overloaded. Test environments arrive late. Operational questions remain unresolved.
The response is often predictable: Add more people.
More developers are brought in. Additional analysts are assigned. Another supplier is asked to contribute. New project managers are added to improve coordination.
The underlying assumption is simple: if the transformation is not producing enough output, it must need more capacity.
But after the additional people arrive, something unexpected happens.
Meetings increase. Coordination becomes harder. Existing specialists spend more time onboarding and answering questions. More work is started, but the same decisions, architectural issues, and dependencies continue to block progress.
The program becomes larger without becoming faster. The problem is not necessarily that the new people are unqualified. The problem is that transformation capacity is not a generic quantity. It depends on having the right skill, applied to the right type of work, at the right moment.
People are not interchangeable capacity
Most capacity plans are based on roles, hours, and headcount. A program may have 20 developers, six architects, eight analysts, four testers, and several project managers. This creates the impression that capacity can be calculated by adding the available people and their working hours. Yet transformation work does not consume generic hours.
A team may need someone who understands a specific legacy data model. Another work item may require authority to approve an enterprise architecture exception. A third may depend on operational knowledge from a particular country or business unit.
These capabilities cannot automatically substitute for one another.
Even people with the same title often represent different forms of capacity.
Six architects may include:
one who understands the legacy platform;
one who specializes in integrations;
one who owns security principles;
one who understands the target cloud platform;
one who has decision authority;
one who understands the business operating model.
The program does not simply have six units of architecture capacity.
It has six different combinations of expertise, organizational knowledge, access, experience, and authority.
The relevant question is therefore not:
How many architects do we have?
It is:
Do we have the specific architectural capability required to move this work forward?
Skills are quantized
Quantized skills describe the fact that capability exists in discrete and specialized forms. A skill is not merely a general competence on a resource profile. It is a usable capability that can perform or enable a specific type of transformation work. This matters because transformation work is itself quantized.
A work quantum may require a particular combination of domain knowledge, technical expertise, business authority, data understanding, and operational experience. Unless that combination is available, the work cannot mature reliably.
For example, a customer-data integration may require:
knowledge of the current customer-data model;
knowledge of the target platform;
understanding of privacy and security requirements;
authority to decide which system owns the data;
integration design experience;
operational input from the functions that will maintain it.
Adding a general developer does not necessarily fill any of these gaps. The missing capacity may not be a missing person. It may be a missing skill combination. That is why transformation capacity cannot be treated as a continuous pool that can be increased by adding more general resources.
It is discrete. Specialized. Context-dependent. And often concentrated in a small number of people.
Capacity changes as work matures
The skills required by transformation work change as the work moves through different states. During early shaping, the system may need business architecture, domain analysis, process design, commercial assessment, and technical exploration. During solution design, the critical skills may shift toward architecture, data, integration, security, and operational design. During construction, engineering and testing capacity become more important. During transition, the system needs deployment expertise, data migration, training, support readiness, and business adoption.
A program can therefore have plenty of people overall and still lack capacity at a particular phase transition. This is one reason staffing plans are often misleading. They show who has been assigned to the program, but not whether the required skills will be available when the work reaches a specific state.
A transformation may have five development teams ready to build, but only one architect able to resolve the design decisions required before construction begins. It may have several testers, but no stable environment. It may have change managers, but no agreed operating model to prepare the organization for. It may have analysts, but no business owner available to make the decisions that analysis reveals.
The apparent capacity exists.
The usable capacity does not.
The constraint determines throughput
A system does not move according to its average capacity. It moves according to its active constraint. This is a central principle in the Theory of Constraints. Improving a part of the system that is not currently constraining throughput may increase local activity without improving overall delivery. [1]
Imagine that architecture can prepare ten work quanta per month, while development can complete twenty. Adding another development team may increase development capacity to twenty-five. But architecture can still prepare only ten.
The additional development capacity cannot increase end-to-end throughput. Instead, teams wait, start immature work, or pull architectural questions into development.
The result is more work in progress.
Little’s Law shows the relationship between work in progress, throughput, and lead time. When throughput remains unchanged, increasing work in progress increases the time each item spends in the system. [2]
This means that starting more work in response to delay can make the transformation slower.
More work creates more questions. More questions create more interruptions. More interruptions consume the attention of scarce specialists. The constraint becomes more fragmented, and its effective capacity falls further. The system is now busier, but less able to complete work.
When more developers make the architecture problem worse
Architecture is a common example of quantized capacity. A transformation may be replacing a tightly coupled legacy platform with a more modular solution. Several product teams are ready to build, but important questions remain unresolved:
Which capabilities should be shared?
Which data source is authoritative?
Where should business rules reside?
Which integrations can be retired?
What must be standardized across teams?
Which operational requirements must be designed into the solution from the beginning?
When architectural capacity is insufficient, delivery teams rarely stop completely.
They make assumptions.
Each team chooses a solution that seems reasonable within its own scope. One creates a local data model. Another duplicates a service. A third introduces an integration pattern that conflicts with the enterprise direction. Activity increases, but structural coherence decreases.
Adding more developers at this point does not solve the architecture constraint. It increases the speed at which unresolved architectural decisions are turned into code.
The cost appears later as rework, inconsistent solutions, duplicate functionality, and difficult integration.
Frederick Brooks described a related problem in software delivery: adding people to late and interdependent work can make it later because onboarding and communication create additional load. [3]
The principle is broader than software development. Whenever work depends on specialized knowledge and tightly connected decisions, adding people can increase demand on the people who are already the constraint.
Utilization is not capacity
Another common mistake is to equate utilization with efficiency. A specialist who is fully booked appears productive. Empty space in a calendar appears wasteful. Managers therefore distribute scarce experts across as many initiatives as possible. An architect may be allocated 20 percent to five programs. A security specialist may support ten teams.
A business owner may participate in several governance structures while also running an operational function.
On paper, the capacity is fully utilized. In reality, work does not arrive in neat percentages.
Questions appear unpredictably. Decisions depend on previous discussions. Documents must be reread. Technical and business contexts must be reconstructed.
Every switch consumes attention.
Research into interrupted knowledge work shows that people often compensate for interruptions by working faster, but experience greater stress, frustration, effort, and time pressure. [4]
A specialist can therefore be 100 percent utilized while providing very little usable flow capacity to any individual work quantum. High utilization also removes the ability to respond to variation. When a critical design question appears, the architect has no available space. The work waits until the next scheduled review. By then, the team may have moved on, forgotten part of the context, or made a temporary assumption. Some slack is therefore not waste.
It is the response capacity that allows the system to deal with uncertainty, urgent decisions, and variation without creating long queues. The objective is not to keep every specialist continuously busy. It is to keep the transformation moving.
The hidden cost of shared specialists
Scarce experts are often treated as shared services. This may be necessary, but it creates a structural risk. If ten teams depend on one specialist, each team may believe it requires only a small amount of support. Collectively, however, the demand may be larger than the specialist can handle.
When no explicit queue exists, prioritization happens through interruption. The loudest team gets attention. The most senior stakeholder receives the fastest answer. The next urgent deadline replaces the previous urgent deadline. The specialist spends the day switching between topics rather than completing meaningful units of work. This is capacity dilution. The skill technically exists in the organization, but it is not available in a sufficiently concentrated form to complete the required transition.
A real capacity assessment must therefore ask more than whether the skill exists.
It must ask whether that skill is:
available when the work needs it;
protected from excessive competing demand;
concentrated long enough to complete meaningful work;
supported by the required information;
connected to the necessary decision authority.
Without these conditions, assigned capacity is not usable capacity.
Phase contracts make the capacity problem visible
Phase contracts define the minimum conditions required for a work quantum to move from one maturity state to another. They make it possible to connect skill requirements directly to work transitions. A feature should not become ready for construction merely because a refinement meeting has taken place.
It becomes ready when the necessary business, architectural, data, security, operational, and delivery conditions have been established to the level required by the work. This changes the capacity conversation.
Instead of asking whether the program has enough people in general, leaders can ask:
Which work transitions require architectural input?
Which specific type of architecture skill is needed?
How many work quanta are approaching that transition?
How quickly can the available capability process them?
Where will demand exceed capacity?
Which work should wait rather than entering an overloaded interface?
This makes the constraint observable before it becomes a crisis. It also reveals why many staffing responses fail. More developers do not help when work cannot pass an architecture contract. More analysts do not help when decisions are waiting for accountable business owners. More testers do not solve unavailable environments. More change capacity does not compensate for an operating model that has not been decided. The blocked transition reveals the missing capability.
Quantum Skills - Plan skill capacity around work, not headcount
Recognizing quantized skills changes how transformation capacity should be designed. Capacity should be planned against work types and maturity states, not only against departments and role categories. Scarce skills should have visible demand queues rather than being exposed to uncontrolled interruption.
Before adding headcount, leadership should identify the active constraint:
Is the system missing production capacity?
Decision capacity?
Domain knowledge?
Architecture?
Data expertise?
Operational readiness?
Authority?
Or sufficiently mature work?
The system should also reduce unnecessary dependence on scarce specialists.
Clear standards, reusable patterns, stronger documentation, delegated decision rights, and better-shaped work can allow specialists to focus on the work that genuinely requires their capability. This does not remove specialization. It protects it.
Research into high-performing technology organizations consistently points toward flow, feedback, architecture, and organizational learning as drivers of delivery performance—not simply higher workforce utilization. [5]
Capacity is the ability to move work
Headcount measures how many people have been assigned. Utilization measures how occupied those people appear. Neither measure tells us whether the transformation can move its work. True capacity is the system’s ability to apply the right combination of skill, knowledge, authority, and focused attention to the right work quantum at the moment it is needed. Once capacity is understood this way, adding people is no longer the automatic response to delay.
The first response becomes structural:
Where is the work waiting?
Which transition cannot be completed?
Which specific capability is missing or overloaded?
What additional demand are we creating at the constraint?
Transformations do not normally stall because everyone has stopped working. They stall because the structure of work and the structure of capability do not match. More people may create more activity. Only the right quantized skills, applied at the right point in the flow, create more capacity.
References
Eliyahu M. Goldratt and Jeff Cox — The Goal: A Process of Ongoing Improvement
Why it matters: Goldratt’s Theory of Constraints helps the reader understand why improving non-constrained parts of a transformation does not necessarily increase end-to-end throughput.
John D. C. Little — A Proof for the Queuing Formula: L = λW
Why it matters: Little’s Law explains why increasing work in progress without increasing throughput produces longer lead times and more waiting.
Frederick P. Brooks Jr. — The Mythical Man-Month: Essays on Software Engineering
Why it matters: Brooks explains why adding people to complex, late, and interdependent work can increase communication and onboarding costs rather than improve delivery.
Gloria Mark, Daniela Gudith, and Ulrich Klocke — The Cost of Interrupted Work: More Speed and Stress
Why it matters: This research helps explain how interruptions and context switching reduce the usable capacity of specialists even when they appear fully occupied.
Nicole Forsgren, Jez Humble, and Gene Kim — Accelerate: The Science of Lean Software and DevOps
Why it matters: Accelerate connects strong delivery performance with flow, feedback, architecture, and learning rather than simple resource utilization.
Comments