Software as Institutional Capacity

The question leaders can no longer delegate

For much of the information-technology era, organizations used a support-service model. Business units decided what the organization needed; technology departments supplied systems. Strategy belonged to the business. Execution belonged to IT. Success could be discussed through projects delivered, budgets consumed, systems available, and requests completed.

That division was never entirely true, but it was administratively convenient. It allowed senior leaders to treat software as a specialized input, comparable to facilities or telecommunications. They could delegate the means while retaining ownership of the ends.

Software-mediated organizations make that separation unstable. A policy is not fully operational when it has been announced; it becomes operational when rules, workflows, data, permissions, interfaces, controls, and exception paths embody it. A new product becomes real when customers can discover, buy, use, and receive support for it. A regulatory obligation must be expressed in repeatable behavior, evidence, and control. Increasingly, software is where these commitments acquire executable form.

Software production is therefore a form of organizational translation. It converts intentions into operating reality. Every translation involves choices: which rules are explicit, which exceptions are possible, which users are prioritized, which risks are tolerated, which data is retained, and which actions can be reversed. These are governing decisions expressed through technical means.

Delegation remains necessary. Boards should not review code, and chief executives should not manage deployment pipelines. Executive ownership does not mean micromanagement. It means that leaders remain accountable for the organization's ability to make dependable changes to the software-mediated parts of its mission. They must understand that ability well enough to govern dependence, consequence, investment, and risk.

The distinction is the same one leaders already make in other domains. A hospital board does not perform surgery, but it cannot dismiss clinical quality as a departmental matter. A bank board does not settle individual transactions, but it cannot treat liquidity as back-office support. A manufacturer's executives do not inspect every component, but they remain responsible for production capability and product quality. Specialized work is delegated; accountability for the whole is not.

Software has crossed that boundary wherever its failure, rigidity, or unsafe change can materially constrain the institution. The threshold is not reached because an organization employs many developers or uses fashionable technology. It is reached when software production conditions affect the organization's ability to operate today, adapt tomorrow, and demonstrate that it has met its obligations.

Why the distinction matters

Calling something “support” shapes how it is governed. Support functions are commonly optimized for responsiveness and cost. They receive requests, manage service levels, standardize tools, and control expenditure. Their work may be vital, but their role is assumed to be downstream of strategy.

Capacity is governed differently. Capacity determines which strategies are feasible, how quickly the institution can respond, what level of risk it can absorb, and whether it can perform under stress. Capacity must be maintained before demand arrives. It requires renewal, learning, reserves, and deliberate trade-offs. Its weaknesses can remain hidden during normal operation and become visible only when the institution needs to change quickly or recover from disruption.

The support label creates four recurring errors.

First, it separates strategic ambition from the means of delivery. Leaders approve a policy, acquisition, product, or transformation while treating the software changes required to realize it as subsequent implementation detail. The institution can then accumulate more commitments than its production capability can safely absorb. Delay appears late, but its causes were present when the commitment was made.

Second, it rewards visible outputs over durable capability. A project can meet a launch date by borrowing people, deferring maintenance, weakening testing, or accepting dependencies that make later change harder. The output is visible; the loss of future capacity is not. A portfolio of nominally successful projects can therefore leave the organization less able to act.

Third, it narrows risk to availability. Whether a system is online is important, but material dependence extends beyond uptime. A service can be available yet difficult to change, inconsistent across channels, opaque in its decisions, vulnerable in its supply chain, or impossible to retire. An organization may appear stable while its ability to adapt is deteriorating.

Fourth, it obscures shared causation. When outcomes disappoint, “the business” may blame technology for slow delivery, while technology teams blame unstable priorities, fragmented ownership, old contracts, or architecture. Both accounts may contain truth. The deeper issue is that software production depends on a joint system of decisions and capabilities that crosses formal departments. No single team controls the whole result.

Open figure

Visual C01-F02 — Why Traditional Projects Fail.

These errors compound. Consider a regulated service that must implement a policy change by a fixed date. If leaders regard the work as a technical request, they may ask only when it will be delivered. If they treat it as a capacity question, they ask which services and obligations depend on the change, what else competes for the same systems and people, how the policy's edge cases will be tested, what evidence will prove correct implementation, and whether the change can be reversed.

The second set of questions does not make delivery slower. Asked early, it reveals the real production problem while choices remain available.

This is why the issue belongs in executive conversation. Strategy is partly a choice about which capabilities to build, preserve, or acquire. When software mediates a material portion of the mission, the ability to change it safely is one of them. Ignoring that fact does not keep strategy “business-led.” It makes strategy dependent on a production system that leaders have chosen not to see.

The current reality: organizations expressed in software

Modern organizations are neither purely digital nor purely physical. They are layered systems in which law, policy, people, process, data, software, suppliers, and physical operations interact. Software does not replace the organization; it configures many of the paths through which it acts.

The visible interface is only the surface. Behind a citizen portal, banking application, logistics dashboard, or clinical system lies a web of identity services, data stores, decision rules, integration points, operational procedures, vendor products, support teams, and recovery arrangements. A change that looks small to a user may cross several of these boundaries. A failure in one layer can travel through the others.

This creates three forms of dependence.

Operating dependence arises when software participates in delivering today's service. Orders, payments, scheduling, eligibility, routing, records, authentication, and monitoring are common examples. If the software is unavailable or incorrect, operations slow, stop, or move to a degraded mode.

Adaptive dependence arises when software determines how readily the organization can respond to a new requirement or opportunity. The relevant question is not simply whether a system works now, but whether it can be changed with acceptable speed, confidence, and cost. A stable system that cannot accommodate a new rule may be operationally sound and strategically constraining at the same time.

Evidentiary dependence arises when software produces or preserves proof of behavior. Audit trails, approvals, access records, model documentation, test results, and transaction histories can demonstrate that obligations were met. If these records are incomplete or unreliable, the organization may be unable to establish what happened even when people believe the right action occurred.

These forms of dependence are often managed separately. Operations teams focus on continuity, delivery teams on change, compliance teams on evidence, security teams on control, and business leaders on outcomes. Yet users encounter one organization. A failed release, an inaccessible interface, an unexplained decision, and a delayed transaction are not separate organizational charts to them. They are experiences of its capability.

The same is true of strategic responsiveness. An organization does not possess an option merely because leaders can describe it. It possesses an option when it has the assets, knowledge, relationships, and production capacity to act. Software can expand that option set by making experimentation and recombination easier. It can also narrow the set through tangled dependencies, scarce expertise, inflexible contracts, poor data, or changes whose consequences cannot be predicted.

This is not an argument for universal digitization. In some settings, a manual process is more resilient, more humane, or more proportionate. A small service with low transaction volume and a viable offline fallback may have little operating exposure to software failure. In other settings, manual fallback exists on paper but cannot carry real demand. The relevant measure is not how digital an organization appears. It is how strongly performance depends on software-mediated work, and what safeguards surround that dependence.

The current reality is therefore uneven. Some institutions have deep software dependence and strong production capability. Others have deep dependence but weak visibility into the condition of that capability. Still others have deliberately limited dependence. The governance mistake is to apply one model to all three.

What the evidence does—and does not—establish

The claim that software production is institutional capacity should not rest on rhetoric. It needs evidence from several directions, because no single study captures the entire path from technical conditions to organizational outcomes.

The first direction is empirical research on information-technology capability and organizational performance. A 2022 meta-analysis by Werder and Richter screened 6,436 records and retained 72 quantitative empirical studies. It defined IT capability as an organization's ability to acquire, deploy, combine, and reconfigure IT resources. Across the included studies, both reactive capabilities—those oriented toward responding to existing needs—and proactive capabilities—those oriented toward anticipating and shaping future needs—showed positive pooled associations with organizational performance. The reported pooled correlations were 0.31 for reactive capability and 0.33 for proactive capability.A21

Those results are material, but they require restraint. The underlying studies were heterogeneous and largely observational. A pooled association is not proof that better software production directly causes better performance. The construct is broader than software production, and performance measures differ across organizations. The research supports an association between technology-related capability and organizational performance; it does not justify a mechanical promise that a specific engineering practice will produce a particular financial or public outcome.

A second study sharpens the point. Wang, Song, and Zhang examined survey data from 278 firms in the United States and 326 in China. They found that the relationship between IT capability and firm performance depended on operations capability. At low levels of operations capability, the association was negative; at medium levels, it was not significant; at high levels, it was positive.A22

This is not an inconvenience to the argument. It is one of its most important qualifications. Technical capability does not operate in a vacuum. It creates value through complementary decision rights, process knowledge, management practice, workforce skill, and capacity to absorb change. Buying better tools or hiring more engineers does not automatically improve the organization. Capability must be coherent across the system.

The second direction of evidence comes from standards. Standards do not prove performance effects, but they reveal the recognized scope of responsible practice. ISO/IEC/IEEE 12207:2026 treats software through a full lifecycle that includes acquisition, development, operation, maintenance, support, and retirement, across different organizational contexts.S01 That scope contradicts the habit of treating software as a one-time project output. Dependence continues after launch and often intensifies as systems accumulate users, data, integrations, and obligations.

ISO/IEC 38500:2024 places the current and future use of information technology within organizational governance and states that its guidance applies across organizations of different types and sizes.S18 The standard does not require boards to govern technical detail. It establishes that the use of technology is a subject of organizational governance rather than an autonomous specialist concern.

NIST's Cybersecurity Framework 2.0 provides a third qualification. It explicitly rejects a one-size-fits-all approach. The rigor and scope of an organization's cybersecurity activity should reflect its mission, stakeholders, risk appetite, risk tolerance, and circumstances.S12 Although the framework addresses cybersecurity rather than the whole software-production system, its principle transfers: governance should be proportional to dependence and consequence.

The third direction comes from public-sector research. The OECD's Digital Government Outlook 2026 examines the conditions required to sustain digital-government capability across OECD members and accession candidates. Its analysis emphasizes governance, skills, investment, and the ability to embed delivery across public institutions.R04 This is not causal proof. It is comparative evidence that digital outcomes cannot be separated from the capabilities and arrangements that produce them.

Evidence about public trust requires even more care. In the OECD's 2024 trust survey, conducted across 30 OECD countries in October and November 2023, satisfaction with administrative services and perceptions of legitimate data use and fairness were associated with trust in civil service and local government institutions.R15 The survey is observational; it does not show that a software incident directly causes trust to rise or fall. Trust has many determinants, including political, social, and economic conditions. The responsible conclusion is narrower: software-mediated service experience, fairness, responsiveness, and data use can enter the set of experiences through which people encounter institutions. They are relevant to trust, but they do not determine it alone.

Taken together, the evidence supports a bounded chain of reasoning:

1. Technology-related capabilities are associated with organizational performance, but the relationship is contingent and not automatically causal.
2. Software is a lifecycle responsibility spanning acquisition through retirement, not a finished object handed over at launch.
3. The use of technology belongs within organizational governance, with rigor proportionate to mission, stakeholders, and risk.
4. Sustainable digital capability depends on complementary governance, skills, investment, and operating arrangements.
5. Software-mediated experiences can be relevant to continuity, obligations, stakeholder experience, and trust, while those outcomes remain shaped by many other factors.

The evidence does not support several stronger claims. It does not show that every organization should structure software work in the same way. It does not establish a universal financial return from engineering investment. It does not prove that modern architecture is always safer than older architecture. It does not justify using every outage as evidence of organizational failure. And it does not provide a credible global denominator for how often software incidents cause major disruption.

Absence of such a denominator should change the tone, not erase the risk. Leaders should avoid theatrical claims about universal crisis. They should also avoid assuming that what has not been measured globally is immaterial locally. Governance begins with the organization's own dependence and consequences.

From technical output to organizational consequence

The decisive analytical move is to stop treating software as an output and examine the pathways by which production conditions affect the capacity to operate and adapt.

Production conditions include lifecycle ownership, the ability to make and verify changes, reliability and recovery practice, security and assurance, architecture and dependencies, workforce knowledge, and supplier capability. These conditions shape whether software-mediated services can operate, whether obligations can be implemented and evidenced, whether policy and process can adapt, and whether leaders possess credible strategic options.

The pathway is real, but never direct in the simplistic sense. A weakly tested change may create an error, but whether that error becomes a material failure depends on where it occurs, how quickly it is detected, whether it can be reversed, whether users have an alternative, and how severe the consequence is. The same defect can be trivial in one context and dangerous in another.

Several intervening factors determine the strength of the relationship.

Degree of mediation. How much of the act depends on software? A website that publishes opening hours has a different role from a system that determines eligibility, routes emergency care, or settles payments.

Fallback. Can people continue the service safely without the system, and for how long? A manual procedure is meaningful only if it can handle actual volume, preserve necessary controls, and be activated under pressure.

Consequence severity. What happens if the software is unavailable, wrong, slow, insecure, or difficult to change? Consequences may be financial, clinical, legal, operational, or social.

User vulnerability. The same delay or design barrier can have different effects on users with different resources, needs, or ability to seek alternatives.

Scale and reach. A common component can make service efficient while concentrating the impact of failure. Local variation can contain failure while making coordinated improvement harder.

Regulatory and public duty. Some institutions must meet obligations that cannot be traded away when delivery becomes difficult. Their software must embody not only desired behavior but enforceable duties.

Supplier concentration and control. Dependence on a supplier is not inherently problematic. The issue is whether the institution retains sufficient knowledge, leverage, access, and contingency to govern an essential capability.

Recovery capacity. Prevention will never be perfect. The ability to detect, contain, communicate, restore, reconcile, and learn determines whether a technical event remains bounded.

Figure F01.1 brings these relationships together. It is deliberately not a maturity scale. Institutions do not move through a universal sequence from “low” to “high.” The figure is a dependency-and-consequence map: production conditions influence institutional capability through pathways whose strength is shaped by context.

Open figure

Figure F01.1 — Institutional dependency and consequence map. Where core work is software-mediated, production conditions shape institutional operating capacity through identifiable but conditional pathways. Dependence, consequence, safeguards, and fallback determine the strength of those pathways.

Source: Author synthesis based on A21, A22, R04, R15, S01, S12, S18, CS02, and CS07.

The lower-dependence example in the figure is important. Imagine a small professional service in which a scheduling tool becomes unavailable. Staff can contact a manageable number of clients, reconstruct the day's work from controlled records, and continue safely. Software remains useful, but its failure does not remove the institution's capacity to perform. Governance should recognize that reality rather than importing controls designed for a national service or systemically important bank.

Now change the conditions. Increase transaction volume, eliminate the offline records, connect scheduling to identity and payment, make access time-critical, and serve people who cannot easily seek alternatives. The same category of tool becomes part of a consequential production system. The question is not whether scheduling software is intrinsically strategic. It is whether the institution has made consequential performance depend on it.

This analysis also clarifies why “technical debt” can become an executive concern without every technical compromise being escalated. A local code problem is not automatically strategic. It becomes relevant when it materially weakens a pathway that leaders depend on—for example, when the organization cannot implement a legal change, restore a critical service within an acceptable period, understand a supplier exit, or make a high-consequence change with credible assurance.

The bridge from engineering fact to executive relevance is consequence. Good governance makes that bridge visible.

From software use to Software Manufacturing

The need for a new discipline becomes clearer when software is placed in a longer production pattern. Craft comes first: skilled people make consequential things through judgment and experience. As demand, interdependence, and consequence grow, individual excellence remains essential but ceases to be sufficient. Attention expands from the artifact to the system around it—how work flows, how quality is built in, how knowledge is preserved, how variation is handled, and how evidence becomes learning.

Software does not repeat the Industrial Revolution. Its raw material is information; its design can become part of the machine that executes the design; and useful variation cannot be eliminated from knowledge work. A literal factory analogy would therefore mislead. The relevant historical lesson is narrower: when society comes to depend on the repeated production of something, performance can no longer rest on isolated craft alone. The production system itself becomes an object of design.

Open figure

Visual C01-F01 — Evolution Timeline.

Organizations cross that threshold gradually. At first, software is optional support for work performed mainly through people and physical records. Digitization then encodes existing processes and extends their speed or reach. Dependence follows when core promises can no longer be fulfilled at required scale without software. Some organizations respond by becoming deliberate software producers: they build enduring capability to develop, operate, change, and retire software across its lifecycle.S01

The final shift is conceptual. The organization stops managing software as a collection of assets and projects and begins governing the system that produces trusted capability from intent. People, processes, assets, architecture, controls, suppliers, and evidence become parts of one learning production system.

The decisive shift is from managing software as an asset to managing the system that produces dependable capability through software.

Open figure

Visual C01-F03 — Software Manufacturing Vision.

That shift is Software Manufacturing. It preserves craft but removes the assumption that heroics are a production strategy. It values flow without pretending all work is repeatable, quality without equating it with inspection, and standardization only where standardization improves safety, learning, or reuse. Figure F01.2 shows the evolution. It is not a maturity ladder and not every organization must move to its final state. The trigger is material dependence: when important promises rely on continuous software change, a production discipline becomes necessary.

Open figure

Figure F01.2 — From software use to Software Manufacturing. As software mediation increases, the management focus expands from acquiring tools to designing, operating, governing, and improving the production system that turns intent into trusted capability. The sequence is illustrative, not a universal maturity path.

Source: Author synthesis based on A21, A22, R04, S01, S12, and S18.

This is the chapter's central reframe. Software has become institutional capability. Institutions whose promises depend on it therefore need a disciplined system for producing it. The rest of the argument is not about making software resemble a physical product. It is about making the capacity to change software less accidental.

A framework for software dependence

Leaders need a way to reason about dependence without pretending to manage engineering work from the boardroom. The following five questions are diagnostic rather than prescriptive. They establish when software-production capacity belongs in a decision and what kind of attention it deserves.

1. What promise is mediated by software?

Begin with the promise, not the system. The promise may be to provide care, settle a transaction, administer a benefit, protect information, deliver a product, maintain a public record, or comply with a rule. Naming it prevents technical inventory from becoming detached from purpose.

Then identify how software participates. Does it inform a human decision, enforce a rule, execute a transaction, coordinate work, preserve evidence, or provide the only practical access channel? Different roles create different forms of dependence.

This question often exposes ownership ambiguity. A system may be “owned” by technology while the promise belongs to an operating executive, a statutory officer, or a cross-functional service. Shared ownership begins where those accountabilities meet.

2. What production capabilities keep that promise dependable?

Move from the running system to the capacity surrounding it. Who understands the service across policy, operations, data, software, and suppliers? Can the institution make a change, test it against real obligations, deploy it safely, observe its effects, reverse it, recover from failure, and preserve evidence? Is the software still supportable? Can it be retired without losing records or interrupting dependent services?

This lifecycle view is essential. A launch can create a capability, but only sustained production conditions keep it credible. Maintenance is not the absence of innovation. It is the work by which an institution preserves the option to operate and change.

The answer should include complementary capabilities. Engineering skill cannot compensate indefinitely for unclear policy, unstable decision rights, inaccessible users, weak operational ownership, or contracts that prevent learning. The relevant unit is the whole production system around the promise.

3. What is the consequence of weakness—and who bears it?

Assess more than outage. Consider incorrect behavior, delayed change, insecure behavior, inaccessible design, missing evidence, supplier failure, and inability to retire an obsolete service. Ask who experiences each consequence and whether burdens fall unevenly.

Consequences should be concrete. “Reputational risk” is often too vague to guide a decision. A more useful account might identify delayed payments, inability to meet a statutory date, unsafe manual work, customer lockout, unreconciled transactions, regulatory intervention, or loss of a strategic option. These outcomes can be examined and assigned ownership.

The purpose is not to translate every engineering issue into money. Some obligations are categorical; some harms are difficult to monetize; some strategic options matter precisely because their future value is uncertain. The purpose is to connect production condition to material consequence.

4. What safeguards, alternatives, and recovery paths change the exposure?

Dependence is not the same as fragility. A highly software-mediated organization can be resilient if it has strong prevention, isolation, fallback, recovery, and learning. Conversely, a modest digital service can create disproportionate harm if it becomes the only access route for a vulnerable group.

Examine both technical and organizational safeguards. Technical safeguards include segmentation, tested recovery, observability, access control, and safe deployment mechanisms. Organizational safeguards include practiced incident roles, clear decision authority, supplier contingencies, reliable contact routes, and people able to reconcile work performed during disruption.

Fallback claims deserve testing. “We can do it manually” is not evidence until the organization has established the volume, duration, information, staffing, and control conditions under which manual operation remains viable. A fallback that works for one hour may fail across three days. A process that preserves service may lose the evidence needed for later reconciliation.

5. What level of governance is proportionate?

The final question brings the previous four into a decision. Governance intensity should rise with degree of mediation, consequence severity, user vulnerability, scale, regulatory duty, concentration, and recovery difficulty. It should also reflect uncertainty: an organization may need more attention where it cannot yet establish the condition of a critical capability.

Proportionate governance does not mean adding a committee to every system. It may mean making an accountable executive visible, requiring evidence before a consequential change, funding renewal before failure, testing a fallback, clarifying a supplier obligation, or treating production capacity as a constraint in strategic planning. In a low-dependence setting, proportionate governance may mean accepting a simple solution and avoiding unnecessary control.

The five questions can be summarized as a chain:

Promise → Mediation → Production capability → Consequence → Proportionate governance

Open figure

Visual C01-F04 — Operating Model.

This chain shifts the conversation from “Is technology important?”—a question too broad to be useful—to “Which promises depend on which production capabilities, with what consequences and safeguards?” That question can be answered, challenged, and governed.