Design Technology Teams Around Decisions, Not Org Charts

I disagree with a familiar starting point for technology organization design: “Where should IT report?”

The question matters, but it arrives too early. Moving a CIO from the CFO to the CEO does not automatically improve product delivery. Embedding data scientists in business units does not guarantee useful models. Creating a central AI office does not establish who owns an automated decision. A new box on an organization chart can change authority and attention while leaving the actual work almost untouched.

The more revealing question is this: Which decisions must the organization make repeatedly, and can the right people make them with enough context, evidence, and authority?

That question shifts the discussion from hierarchy to an operating model. It exposes how demand enters the technology system, how priorities are set, which capabilities are shared, who accepts business and technical risk, and how teams learn from production. Reporting lines become one design choice among several rather than the design itself.

This distinction is especially important for AI. A model may be supplied by a vendor, connected through a central platform, configured by an engineering team, used inside an operations workflow, and governed by legal, security, and risk functions. No single reporting line can contain that whole system. The organization needs decision rights that cross its boxes without making accountability disappear between them.

An Org Chart Shows Authority, Not How Work Moves

An organization chart can answer who manages whom. It usually cannot answer:

• Who decides whether a proposed AI use case is worth funding?
• Who defines acceptable quality for its outputs?
• Who owns the source data and its meaning?
• Who can approve access to a consequential tool?
• Who stops the system when evidence changes?
• Who pays for retries, monitoring, support, and model usage?
• Who resolves a conflict between local speed and enterprise risk?

These are operating questions. If their answers are unclear, rearranging teams may only move the ambiguity.

The NIST AI Risk Management Framework makes the accountability requirement concrete. Its Govern function calls for documented roles, clear communication, empowered teams, and executive responsibility for AI risk decisions. NIST does not prescribe a universal org chart. It asks for outcomes an organization must be able to produce regardless of structure.

That is the useful standard. A design is not good because it resembles a fashionable model. It is good when important decisions have a named owner, relevant contributors, usable evidence, a time boundary, and an escalation route.

Start With a Decision Ledger

Before moving people, write down the recurring decisions that determine whether technology work succeeds. A lightweight decision ledger creates a more honest picture than a slide full of reporting lines.

The exact roles will vary. The discipline should not. “Technology owns it” is too broad. “The business owns it” is often a way of assigning responsibility to an abstraction. Name the role that can make the decision and live with the consequence.

The ledger also reveals when one executive has become a bottleneck. If a CIO must personally approve every model, vendor, exception, access request, and product release, the problem is not merely workload. The organization has failed to create bounded authority below that role. Conversely, if every team can choose providers, data practices, and security controls independently, local authority has outrun enterprise visibility.

Separate Four Kinds of Ownership

Technology discussions often use “owner” as if it meant one thing. In practice, at least four kinds of ownership must be distinguished.

Outcome ownership belongs with the person accountable for the changed business condition. If an AI system helps prioritize maintenance, the outcome owner is responsible for whether maintenance improves—not merely whether the model runs.

Product ownership covers user needs, workflow design, adoption, quality expectations, and the sequence of improvements. This role keeps the system connected to real work.

Technical service ownership covers reliability, security implementation, deployment, observability, dependencies, recovery, and lifecycle maintenance. It cannot end when a project launches.

Control ownership covers policy interpretation, risk thresholds, evidence requirements, exceptions, and oversight. Control owners should set meaningful boundaries without becoming substitute product managers.

One person may hold several of these roles in a small company. In a larger organization, they will usually be distributed. Distribution is not the problem. Hidden distribution is.

This is why the relationship between business and technology teams cannot be reduced to request and delivery. The note on fixing AI team communication without proxies explains why direct collaboration matters when requirements depend on process knowledge. The operating-model extension is to make that collaboration consequential: both sides need defined decisions, not just more meetings.

Organize Shared Services Around Leverage

Some capabilities belong in a shared team because consistency or reuse produces real leverage. Identity, network controls, secrets, audit logs, approved model access, deployment templates, cost allocation, and common observability are strong candidates. Other choices need to remain near the domain because they depend on local meaning: user outcomes, data interpretation, exception handling, evaluation cases, and acceptable harm.

The nearby article on centralizing the AI platform without centralizing every decision develops that boundary in detail. The additional organizational test is whether the shared service improves the flow of work.

A platform team that owns reusable infrastructure but requires six tickets and three committees for a low-risk deployment has not created leverage. A decentralized team that ships quickly but rebuilds identity, logging, and model access for each product has confused independence with progress.

Google Cloud’s 2025 DORA report on AI-assisted software development describes successful AI adoption as a systems problem and identifies platform quality, workflow clarity, and value-stream management as important conditions. That finding should change how leaders evaluate team design. The test is not whether a platform exists. It is whether local productivity can travel through the delivery system without becoming downstream delay, instability, or rework.

Shared teams therefore need product measures, not only technical inventories. Useful measures include time to first compliant deployment, percentage of common work completed through self-service, support response time, adoption by target teams, repeated work removed, and exceptions caused by missing capabilities. A central function earns its place by making other teams more capable.

Put Business Context Close to Delivery

Responsiveness does not require every engineer to report into a business unit. It requires short paths between the people who understand the work and the people who change the system.

Imagine a team building an AI assistant for procurement. Engineers need direct access to buyers who understand supplier exceptions, policy owners who know the control boundary, data stewards who know which fields are reliable, and finance partners who can explain where cycle time or leakage matters. If all of that context travels through a project coordinator who converts conversations into tickets, the formal structure may look efficient while the learning loop remains slow.

Proximity can be designed in several ways:

• stable cross-functional product teams around a business capability;
• temporary mission teams for a specific transformation;
• embedded domain specialists inside a shared engineering group;
• regular joint reviews using production evidence rather than status slides;
• named business owners with protected time and decision authority;
• rotation or liaison roles that transfer knowledge without creating permanent silos.

The choice depends on the work’s duration and uncertainty. A short migration may need a temporary mission team. A customer decision system that changes continuously needs stable product ownership. A scarce security specialty may remain shared but join high-impact work early.

Temporary teams are useful when their exit is designed. Without an explicit handoff, they often deliver a project and leave an unsupported service behind. Before forming one, decide who will operate the result, who will maintain its data and evaluations, and which knowledge must move into the long-term team.

Matrix Structures Fail When Conflict Has No Rule

Matrix management is often introduced to preserve technical quality and business responsiveness at once. It can work, but dual reporting does not itself resolve competing demands. It can simply give an employee two queues and no legitimate way to choose between them.

A matrix needs conflict rules. Which leader sets performance expectations? Who controls capacity? Which work interrupts planned commitments? Who decides when a technical standard can be waived? How quickly must a disagreement escalate, and to whom? If those answers live only in personal relationships, the structure is fragile.

The same warning applies to cross-functional AI governance. A product owner may want speed, security may want narrower permissions, legal may want additional review, and engineering may need time for evaluation. “Everyone is accountable” does not resolve the release decision. The operating model should identify who integrates the evidence and who has final authority for each risk tier.

Trust helps people work through imperfect rules, but rules also protect trust. Business and IT trust in AI projects grows when commitments, uncertainty, and responsibility are visible—not when teams rely on escalation politics to settle every hard choice.

AI Agents Turn Reporting Gaps Into Control Gaps

Generative AI makes old organizational ambiguity more consequential. A drafting assistant may produce a poor suggestion. An agent connected to tools may send a message, update a record, issue a refund, change code, or trigger another system. Its work crosses product, data, identity, security, and operations boundaries in seconds.

Microsoft’s 2026 Work Trend Index reports that organizational factors such as culture, manager support, and talent practices were more strongly associated with reported AI impact than individual factors. It also found that repeatable agent workflows, human handoffs, and quality standards remain far from universal. The useful point is not that every company should copy Microsoft’s preferred organization. It is that individual tool skill cannot compensate for an environment with unclear handoffs and weak learning systems.

For an agentic workflow, decision rights should cover at least:

• who defines the agent’s permitted purpose;
• who authorizes each data source and tool;
• who determines which actions require human approval;
• who owns evaluation cases and acceptance thresholds;
• who monitors behavior, cost, latency, and failures;
• who can disable access immediately;
• who reviews incidents and changes the workflow;
• who remains accountable for the business outcome.

These responsibilities may cross reporting lines. They still need to form one coherent control loop.

Use a Six-Part Stress Test Before Reorganizing

When leaders consider centralizing, decentralizing, embedding, or creating a new AI function, test the proposed model against six conditions.

1. Decision clarity: Can people name who decides funding, standards, access, release, risk acceptance, and retirement?
2. Context distance: How many handoffs separate builders from users, process owners, and source-data expertise?
3. Flow efficiency: How long does ordinary work wait for approval, specialist help, environments, or shared services?
4. Technical coherence: Can systems share identity, data, interfaces, telemetry, and controls without custom negotiation each time?
5. Operational accountability: Does every live service have an owner, support path, recovery plan, cost view, and change process?
6. Learning speed: Can incidents, user feedback, evaluation failures, and cost signals change priorities and standards?

Score each condition with evidence, not executive confidence. Review queue times, incidents, rework, platform adoption, unresolved ownership, deployment lead time, user outcomes, and exceptions. Interview the people at the handoffs. A proposed structure should explain which weak condition it improves and what new failure mode it might introduce.

This prevents reorganization from becoming a symbolic response to dissatisfaction. If the real problem is an unusable intake process, moving the team will not fix it. If the problem is weak product ownership, another governance layer may make it worse. If five teams repeatedly build the same foundation, a shared platform may help—but only if it is funded and run as a service.

Reporting Lines Still Matter, but They Should Follow the Work

None of this makes hierarchy irrelevant. The executive a technology leader reports to affects access, incentives, budget conversations, and how the company understands technology. A reporting line can signal whether technology is treated as administration, operations, product capability, or strategic change.

But the signal is not the result. A CIO who reports to the CEO can still run a ticket-taking function. A technology group under finance can still create strategic value if decision processes, investment logic, and business relationships support it. Structure influences behavior; it does not replace operating discipline.

The same applies to executive communication. CIOs need a shared language for technology decisions because no reporting relationship removes the need to connect technical conditions with outcomes, exposure, options, evidence, and ownership.

Choose reporting lines after clarifying the work that needs sponsorship, the conflicts that need resolution, and the capabilities that need executive attention. Then reinforce the structure with explicit decision rights, capacity rules, service measures, and review rhythms.

Design for Change Without Permanent Reorganization

No technology operating model remains correct indefinitely. Company scale changes. A scarce capability becomes common. A new regulation raises the control burden. An acquisition introduces duplicate platforms. AI tools move from experimentation into consequential workflows. A shared team that once accelerated adoption becomes a queue, or fragmented teams begin duplicating expensive foundations.

The answer cannot be a major reorganization every time conditions change. Build adjustable mechanisms into the model:

• review decision rights when risk or scale changes;
• use time-limited mission teams with explicit exit criteria;
• allow documented exceptions that reveal missing platform capabilities;
• move mature practices from a center of excellence into normal product teams;
• track service flow and outcomes so friction appears before politics dominates;
• retire committees, controls, and teams whose original purpose has ended.

The goal is not a perfect diagram. It is an organization that can place decisions where the necessary context and authority meet, while preserving the shared capabilities that keep the whole system safe and coherent.

Start with the decision ledger. Inspect how work actually travels. Measure the waiting, rework, risk, and outcomes. Change the reporting line when it removes a real constraint—but do not ask the org chart to solve a problem that lives in the operating system around it.