Technology is now an operating system problem

Technology failures rarely start with villains. They start with reasonable requests.

A founder wants the company to move faster. Sales wants better account research. Support wants fewer repetitive tickets. Product wants customer feedback summarized. Engineering wants less boilerplate. Finance wants cleaner reporting without more headcount.

Each request makes sense. A team finds a tool, runs a pilot, builds an integration, or assigns someone to try it. The first result looks useful. A report appears faster. A draft saves time. A few people feel relief.

Then the cost shows up somewhere else. The report uses a different revenue definition than finance. Sales research pulls stale data. A support summary misses the detail the customer cared about. Product insight never reaches roadmap decisions. Generated code works locally but fights the architecture.

Nobody meant to create complexity. Complexity appeared because the company treated technology as a set of point solutions instead of part of the business operating system.

The old problem was collaboration

In the 2021 version, the central problem was that business and technology teams often behaved like neighboring companies. Business described urgent needs. Technology translated them into systems, roadmaps, estimates, and tradeoffs. Purpose got diluted in the translation. Teams debated features before they agreed on the problem.

The result was familiar: projects delivered, but business value did not.

The thesis then was simple: technology value requires business and technical teams to operate together. Shared purpose. Shared problem definition. Shared tradeoff conversations. Shared ownership of outcomes. A cadence for learning what is working.

That was true in 2021. It is more true now.

AI exposes weak collaboration faster

AI does not remove the need for collaboration. It pressures it.

In the old model, a poorly defined software project might take months to expose the confusion. With AI, the loop is shorter. A prototype appears in a day. A manager subscribes to a tool without IT. Someone connects an agent to the CRM through a connector nobody reviewed. A department introduces an agent before the workflow has an owner. Impressive output makes the business case feel obvious.

AI lowers the cost of producing output. It does not lower the cost of being wrong about the outcome.

If the operating system is clear, AI can reduce repetitive work, improve decision support, and make knowledge more accessible. If the operating system is weak, AI amplifies the weakness: unclear ownership becomes agent sprawl, fragmented data becomes inconsistent answers, vague decision rights become automation risk, and missing review standards become quality problems.

That is why I do not start with “Which tool should we use?” I start with the work.

What outcome are we improving? What workflow creates it today? Where does it break? What data does it depend on? Who owns the decisions? Where does human judgment matter? What should never be delegated?

These are not bureaucracy. They are the minimum discipline required to make technology useful.

Technology is no longer a department problem

Technology now runs through how the company sells, supports, markets, builds, delivers, reports, hires, learns, and manages risk. AI makes that obvious because agents often cross boundaries.

A customer-success agent may need product usage, support tickets, contract terms, and call transcripts. A sales-research agent may touch CRM records, marketing signals, fit criteria, and prior interaction history. A coding agent may need the repository, tickets, documentation, logs, architectural rules, and permission to run tests and open pull requests.

The value is cross-functional. So are the risks.

Connectors have made this easier. A standard like the Model Context Protocol (MCP) lets one agent reach many systems through the same kind of interface. That removes integration work. It does not answer which systems the agent should reach, with whose permissions, or who reviews what it does there.

No single function can manage this well alone. If the business owns the outcome but not the workflow, the agent lacks direction. If technology owns the tool but not the decision, the work optimizes implementation over value. If operations owns process but not data definitions, the answers drift. If legal and security arrive after deployment, governance becomes cleanup.

Technology has become an operating-system problem because the company needs an operating layer for technology-enabled work: ownership, decision rights, workflow standards, data definitions, review rhythms, and escalation paths. Not a committee for every decision. Fewer unmanaged handoffs, not more meetings.

The operating-system principle

Technology creates value when it is connected to outcomes, embedded in owned workflows, supplied by trusted data, governed by clear decision rights, and reviewed on cadence.

Miss one layer and value leaks out. Outcome without workflow becomes aspiration. Workflow without owner becomes coordination debt. Agent without trusted data becomes a confident guesser. Decision support without decision rights becomes confusion. Automation without review becomes risk. Governance without cadence becomes a document nobody uses.

The technology leader does not need to control every layer. The job is to help the leadership team see the system, assign ownership, and create enough operating discipline that teams can move quickly without losing accountability.

The one-page technology operating map

Before approving expansion on an important technology or AI initiative, complete one page:

1. Outcome: What business or customer outcome should improve, and how will we observe it?
2. Workflow: What workflow produces that outcome today, and who owns it end to end?
3. Data: What sources are required, who owns them, and what quality or access issues exist?
4. Agent or tool role: What will the technology assist, recommend, monitor, draft, decide, or execute?
5. Human accountability: Who reviews output, handles exceptions, and owns decisions?
6. Governance: What boundaries, tool permissions, logs and traces, evals, escalation paths, and lifecycle rules apply?
7. Cadence: When will performance, risk, adoption, and scale/change/pause/retire decisions be reviewed?

This artifact is intentionally plain. It prevents a common mistake: letting a technology decision move faster than the operating clarity around it.

A short example

A B2B SaaS company wants AI to improve renewal-risk detection. A tool-first approach connects systems, generates account summaries, and asks CSMs to use them.

An operating-system approach asks what outcome should improve: earlier detection of renewal risk and better manager intervention. It maps product usage review, support escalations, CSM notes, account planning, one-on-ones, forecasting, and executive escalation. It discovers inconsistent support tags, delayed usage data, incomplete transcripts, and uneven notes.

The agent’s first role is not to decide risk. It creates a structured weekly account-risk brief with source links and confidence indicators. The CSM reviews it. The manager uses it in one-on-ones. Incorrect signals are logged and added to the eval set, so the next version is checked against them. CS Ops owns the workflow map and data-quality list. Leadership reviews whether earlier detection changed renewal action, not whether the agent produced many summaries.

Not glamorous. Useful.

Chapter 2 operating check

Ask with your leadership team:

1. Which initiatives are being discussed as tools when they should be workflow changes?
2. What are the three most important outcomes technology should improve in the next ninety days?
3. For each outcome, who owns the workflow today?
4. Where do business and technology still translate through requests instead of shared purpose?
5. Which AI pilots depend on data with unclear ownership or quality issues?
6. Which decisions are AI tools and agents already influencing?
7. Where is human accountability explicit, and where is it assumed?
8. Which initiative should not scale until the operating map is complete?

If the questions expose gaps, good. The gaps were already there. AI made them harder to ignore.