Who Is Responsible for Reducing Complexity?
Making room for the authority to reconsider what an organization has added.
Responding to a vulnerability involves judgments that extend well beyond installing an update. Someone has to locate affected software, assess exposure, test compatibility, agree on a change window, and monitor what happens afterwards. The engineers and colleagues carrying this work deserve our respect and thanks. Their task is to make necessary changes while preserving services on which other people depend.
The PHP and Node.js security releases announced in October 2026 provide an occasion to consider that work. The causes of the individual vulnerabilities are separate from the difficulty an organization faces in assessing and changing its systems. These releases do not establish that organizational complexity caused the vulnerabilities.
They do, however, invite a longer-term question. Organizations have processes for approving new systems, features, and controls. Where have they placed the responsibility and authority to reconsider those additions and make the whole easier to maintain?
How reasonable decisions accumulate
Consider a hypothetical interface discovered during planning for a system update. It supplies data to another department for month-end reconciliation. It was introduced to let a new function operate without interrupting an existing business process. Additional checks and exceptions were introduced over time. The people who understood the original arrangement have moved on. Business users, whose screens reveal little of the underlying connection, may no longer recognize their reliance on it.
None of these decisions needs to have been careless. A fixed deadline, a limited budget, a partner's requirements, or the need to preserve continuity can make an additional interface a reasonable choice. Judging that choice fairly requires taking account of the information and authority available at the time.
The difficulty emerges across decisions. Each addition may be approved within a particular function or project. The next update has to contend with their combined dependencies. The boundary within which a decision made sense may be much smaller than the boundary within which the resulting system must be maintained.
Criticizing earlier decisions does little to resolve this mismatch. What helps is an opportunity to reconsider the arrangement in its present context, including the work that now depends on it.
The risks on both sides of a change
Keeping the interface means continuing compatibility checks, carrying exceptions forward, and investigating uncertain dependencies whenever something changes. Its apparent stability may depend on recurring work that is easy to overlook.
Removing it could interrupt reconciliation. A replacement has to satisfy the relevant business requirements, and someone has to check results during the transition. A cleaner architecture diagram would be an incomplete measure of success if it simply transferred the work to a manual process in another department.
Some complexity serves a necessary purpose. Distinct business requirements can require different paths through a system. An independent check may provide protection that another check cannot. Google's SRE discussion of simplicity distinguishes complexity inherent in a problem from complexity that engineering can reduce. When considering an organization, counting components or procedures alone cannot settle which complexity is necessary.
Continuation and change both carry costs and risks. Simplification therefore involves deciding which business requirements to preserve, which burdens to reduce, and what uncertainty to accept during a transition. Technical understanding is essential to that decision, but cannot supply all of it.
Benefits and burdens cross organizational boundaries
The benefits of a new function are usually available to explain when it is proposed. The maintenance work can appear later, in another team's budget or another person's working week. The department requesting an addition may not maintain it. The person approving it may not be present at the next update.
This creates a way for today's decisions to transfer work into the future without anyone intending to do so. In the hypothetical interface, the receiving department obtains the business benefit while IT may undertake the investigation required for an update. Neither perspective alone captures the reasons for keeping or changing the arrangement.
Controls deserve the same attention. Two review procedures may look similar yet address different risks. Both may be necessary. If they repeat the same examination without adding a distinct judgment, they may instead delay action and consume capacity. Understanding the difference requires knowing what each review examines and who can decide what to do with its findings.
An organization's ability to remain in control depends on being able to understand relevant risks, make decisions with appropriate authority, and carry out the required response. Additional controls can support that ability. Their continuing effectiveness also needs room for reconsideration.
Someone has to be able to decide
An engineering team may understand the burden of the interface without having authority to decide whether the reconciliation process is still needed or which business risks its removal would create. Business owners may understand the purpose without being able to identify all the technical dependencies.
These judgments have to meet. Business representatives explain the current need. IT makes dependencies and change options visible. Security and risk functions examine the conditions that need protection. Where departmental priorities or burdens conflict, management may have to decide resource allocation and accept the remaining risk. The precise division varies by organization.
Bringing the participants together does not, by itself, establish who can decide. That requires an explicit allocation of authority, supported by sufficient information and time. Asking operational teams to produce improvement proposals while giving them neither capacity to investigate nor authority to change business arrangements leaves simplification as another unfinished assignment.
There can also be good reasons to defer a change. If information is insufficient, retaining an arrangement may be appropriate. Identifying what would make reconsideration possible gives that decision a basis beyond simply carrying the current state forward.
Accountability for Complexity
One useful way to approach this is accountability for complexity: maintaining the ability to explain why an arrangement is needed and to make a decision about its future. This is a perspective on existing decisions, rather than a proposed standard or a new institutional framework.
Four questions can help keep the discussion concrete.
Purpose: What is it needed for? Which business requirement or risk does it address, and is that purpose still valid?
Dependencies: What depends on it, and what burden does it create? Which activities rely on the arrangement, and who carries the work of operating, maintaining, and changing it?
Ownership: Who reconsiders the need? Who is responsible for reassessment, and how are technical, business, and risk judgments connected?
Changeability: Under what conditions could it be changed, consolidated, or retired? What information and authority are needed, and what has to be in place before action is possible?
There is no need to turn these questions into an inventory exercise or an obligation to inspect every system. They can be discussed for one arrangement already under consideration in an existing change review or budget decision. If a record is added, its value depends on whether it helps someone make the decision. The effort of documenting simplification belongs among the burdens being considered.
Easier operation leaves other questions open
AI agents and automation may allow people to work across several systems without attending to each connection. They may also help prepare investigations and explanations. These possibilities can make operational work easier.
The reconciliation process still depends on something, and someone still has to judge a proposed change. A layer that carries out operations can leave the underlying dependencies and allocation of responsibility intact. Permissions, external connections, and recovery from exceptions may introduce additional things to maintain. Work saved and obligations introduced have to be considered together.
An organization does not need a complete picture of every dependency before making any progress. An update investigation can clarify one connection. A discussion can establish whether two controls examine different risks. The next review of a longstanding exception can acquire an identifiable owner and conditions for reconsideration. Each step expands the basis on which the next person can make a judgment.
When a step does remove a burden, it also matters what happens to the capacity released. Filling all of it with new administrative work makes continued simplification harder. The time left for understanding and reconsideration is part of what allows the effort to last.
When an arrangement in your organization needs to be reconsidered, where do the information and authority needed for that decision reside?
Complexity is difficult to resolve all at once. Even so, we can understand its parts, one by one, and make them simpler.