Functions attach to the technology role through neglect rather than decision. Data governance arrived after the first privacy audit. Business continuity arrived after the first outage. Cybersecurity governance arrived with the first board question about exposure, and sustainability reporting arrived with the first customer questionnaire that asked for emissions data. Each one was assigned, in the sense that the technology leader now answers for it. None was assigned in the sense that anyone decided its authority, funded it, or put an executive's name against it. The fix is a rule owned above the technology leader: no function attaches to the technology role without an explicit scope decision, appropriate funding, and a named accountable executive.

The Function That Arrived Without a Decision

A technology leader can inherit an entire function without the executive team ever holding a meeting about it.

The pattern is the same for each function. A privacy regulation lands and someone has to classify the company's data; the technology team knows where the data is, so the CIO answers the first question, and by the third question data governance has a home. A warehouse loses power for a day and the executive team wants a continuity plan; the plan involves systems, so it involves the technology leader, and business continuity has a home. A director asks whether the company is exposed on cyber; the answer involves controls, so it comes from the IT leader, and cybersecurity governance has a home. A large customer sends an ESG questionnaire that asks for emissions data; the data lives in systems, so the request lands with technology, and sustainability reporting has a home.

Four functions, four homes, and no minutes from any meeting where the executive team decided to place them. Each attached because the technology team was closest to the first question.

How a Function Attaches Through Neglect

A function attaches to the technology role when a question nobody owns gets answered by the executive whose team is nearest to it, and the answer becomes the assignment.

Two things are never decided in that sequence. The first is authority. The technology leader can run the tools that data governance needs and cannot set the policy for who may access which data across the business, because policy authority over other executives' functions was never granted. The second is capacity. The function arrived with its questions and none of its funding. No headcount moved, no budget line was created, and the technology organization absorbed the work into a team sized for the original job.

Funding is the tell. A function that was deliberately assigned has funding somebody decided. A function that attached through neglect appears in the technology budget as a growth in "other" that the IT leader has to explain and the executive team has never seen itemized. The executive team notices the function only when it fails, because until then it has a working answer and no cost anyone can see.

CIO.com's own look ahead to 2026 describes technology leaders being handed responsibility for corporate sustainability and platform consolidation on top of the transformation and cloud work they already carry. The list of what arrives varies by company. The way it arrives does not vary much at all.

Nobody chose this. The executive team is not negligent by intent. The operating rhythm has no step where anyone asks whether a function that has come to rest with the technology leader was ever meant to.

What the Technology Leader Inherits

The week a function attaches, four things transfer to the CIO that no one wrote down.

The first is accountability to the board for the function's risk. When a director asks about continuity, the technology leader answers, because there is no one else the CEO would turn to.

The second is accountability to the auditors for its controls. The data classification, the retention schedule, the access reviews: the auditors need an owner, and the owner is whoever produced the evidence last year.

The third is a policy role with no policy authority. The IT leader writes the continuity plan and cannot compel the operations team to test it. The same leader drafts the data policy and cannot enforce it on the sales organization that owns the customer records.

The fourth is a capacity burden nobody funded. A headcount does not transfer. Work transfers into unchanged capacity, so every attached function is staffed by subtraction from work the technology team was already funded to do.

Taken together, a senior technology leader with three attached functions is running three unwritten side jobs, each the size of a department, each with a failure mode the board will ask about by name. That is accountability without authority in its most common form, built one unowned question at a time.

Why "Spread Thin" Is a Label for an Org-Design Decision

The technology leader carrying four attached functions gets described as spread thin, as touching everything and finishing nothing, or as not focused, and each of those labels describes an org-design decision the executive team did not make.

The role was expanded four times without a scope decision. The executive team then evaluates the person in the role against a scope it never defined, and reads the strain as a performance issue.

The cost lands on the functions themselves. The company's most board-visible risks are being run as fractions of one executive's attention. When one fails, the discovery is the same each time. A continuity plan that was never tested because the technology leader could not compel the test fails during the outage it was written for, and the executive team, asking who owned continuity, finds it never decided. A data retention gap surfaces in litigation, and the executive team, asking who owned the data policy, finds the same thing.

None of that is guaranteed in any single company. The pattern to watch for is a technology leader answering board questions about functions that appear nowhere in the technology leader's job description.

The Rule: No Function Without a Decision

The remedy is one operating-model rule, and it belongs to the CEO or COO.

No function attaches to the technology role without an explicit scope decision, appropriate funding, and a named accountable executive.

The scope decision is a written statement of what the function includes and what authority comes with it. If the technology leader owns data governance, the statement says whether that includes policy authority over data held in other functions, or only the systems that hold it. Much of the strain in an attached function comes from that one unanswered question.

Appropriate funding means the executive team explicitly decides what capacity, budget, and headcount the function requires. Sometimes that creates a separate line. Sometimes it changes an existing one. It cannot remain invisible.

A named accountable executive is one name, on record. That executive may be the CIO. The rule does not say where a function should sit, and this article does not argue that security, data governance, or continuity belong somewhere else. The rule says the placement has to be a decision. A function can end up with the technology leader under this rule; it cannot end up there by default.

The technology leader can propose this rule and cannot enforce it, because a rule about the technology leader's own scope has to be held by someone above that scope.

What Technology Leaders Bring to the Executive Table

Scope is an operating-model design decision, and the executive team owns it. The CIO is positioned to raise it because the technology leader is the one executive who can list every function that has attached and when.

The move is the scope inventory. One page, one row per function the technology role currently carries beyond its original charter: what it is, the year it attached, whether a scope decision exists for it, whether its funding was ever decided, and who the executive team would say owns it if asked cold. In practice the first column fills easily and the rest are mostly blank. The blanks make the case.

Then the ask: adopt the rule, and run the inventory through it one function at a time. Some functions stay with the technology leader, by decision, with a written scope and funding that was decided. Some move. Every one of them ends up with a name and a funding decision, and the executive team has, for the first time, decided what the technology role is.

The technology leader proposes. The executive team decides. The subject throughout is the decision, and never the destination.

Close: Decide Before the Next Function Arrives

The next function will arrive the same way, through a question nobody owns, answered by the team nearest to it. The moment it arrives is the wrong time to design the rule, because by then the answer has already been given and the function has already found its home.

The inventory can begin in an afternoon. The rule can be established in one executive conversation. Resolving every inherited function may take longer. The conversation ends with the executive team owning the scope of its own technology role, which is where that decision belonged from the start.

A technology leader carrying three functions nobody deliberately assigned is running an org-design decision the executive team never made. CIO Mastermind gives technology leaders a confidential peer forum for working through what has attached to the role, how to bring the scope inventory to the executive team, and how to get the decision made before the next function arrives. Explore the CIO Mastermind peer network.