You’re Already a Tech Company: The One Shift the Rest of the Book Depends On
One claim does the work in this chapter: you’re already a tech company. Three shifts follow once that lands. AI is a worker, not a tool. The headcount math can bend. Your job is to design the work, not do it. The chapter closes with one thing to do before Sprint 1: take stock of where your people are doing work your systems should be doing, and carry that list forward.
Marco Argenti, the CIO of Goldman Sachs, told a story in Harvard Business Review (June 2026). One of his senior bankers asked him a question: “With AI getting better so fast, what’s the 10% of my job AI will never be able to do, so I can hang on to it?”
The banker was asking the wrong question.
Argenti’s answer: let go of that 10%. The 10% isn’t the moat. The new 100% is review, judgment, debate with the team, calling the client before the client calls you. The job got reshaped. The banker was asking how to defend an old role. Argenti told him the role had already changed.
Mid-market operators are asking a quieter version of the same question. Where does AI fit on top of what I already do? It produces the same scattered pilots the Diagnosis chapter just named.
It starts with one claim, and the rest of the book leans on it.
Your systems are already running. Your people are still the glue.
You’re already a tech company. Today.
Look at what’s actually running inside your business right now. A CRM (HubSpot, Salesforce, Pipedrive). An accounting or ERP system, the platform that runs the financial and operational backbone of the company (NetSuite, QuickBooks, Sage). A project management tool (Asana, Monday, ClickUp). A communications stack (Slack, Teams, Gmail). A document store (Google Drive, SharePoint, Dropbox). A few function-specific tools layered on top: a billing platform, a scheduling tool, a customer support system.
If your “ERP” is really a stack of spreadsheets, or you’ve got three of those systems instead of six, the claim still holds. You don’t need every system, and you don’t need an expensive one. You need to run on systems at all. Almost every company past its first few employees already does.
Every one of those systems has structured data, defined interfaces, and rules you’ve already paid to encode. The investment is on the books. The systems are running. The tech-company part already happened. What hasn’t happened is the redesign of work around those systems. That’s the move, and it’s the whole rest of this book.
Elena, who runs the revenue function at Meridian (the mid-market manufacturer the Diagnosis chapter introduced), runs HubSpot, NetSuite, and Asana, the same stack most operators her size have. She thought of it as overhead.
Your stack is friction for humans and feedstock for agents.
The same systems that make a human’s day harder make an agent’s job possible.
For a human, the stack is context-switching overhead. Your team jumps across six tools to close one deal. They retype the same information from one system into another. They send the Slack message that says “did you see the ticket?” because the ticket and the conversation live in different tools. The exception handling, where the rule doesn’t fit and a person has to decide, eats hours nobody put on the calendar.
For an agent, that same stack is an asset. An agent is an AI system that holds a goal and runs a sequence of steps toward it on its own, adjusting as it goes. It’s not a chatbot you prompt one question at a time. Agents read structured data. They call defined interfaces. They execute rules. (More on how agents are built in the Source and Build chapters.) The work that’s friction for a human is exactly what an agent runs on.
You’ve got less legacy bloat than enterprise and more system maturity than a startup. The systems you spent the last decade installing, the ones your team still complains about, are what AI runs on. Mastery of your own data, as Argenti puts it in the same piece, is the precondition for any of this working. Mid-market companies are in the best position for it.
If your systems are running and your people are still the glue between them, you’ve got an operating-model gap, not a technology gap.
That one line changes which question you ask first. The question isn’t which AI tool should we buy? It’s given the systems we already run, where is human labor doing the work the systems should be doing? That’s where AI goes. Everything else in the book is the discipline of finding those places.
Three shifts follow from this one.
Manage AI like a worker, not a tool.
If your systems are the substrate, the next question is what operates inside them. Most operators reach for software vocabulary: deploy, integrate, license, train the model. That language was right for thirty years. It described a tool you installed and used. A tool didn’t have a workday or hand off to other parts of the org.
The new vocabulary is management. You assign work. You supervise. You evaluate the output and adjust the assignment. An agent holds a goal, has a defined scope and access to specific data, and produces deliverables on a cadence. A human reviews the output and adjusts the scope. The structure is identical to how you manage a competent junior employee. The interface is different; the work pattern is the same.
At Meridian, Elena stopped describing the quoting work as “a tool to integrate” and started describing it as “an agent that drafts the quote, hands it to me to review, and learns from my corrections.” If your team is still typing questions into a chatbot and reading the answers as authoritative, they’re stuck in the loop the Diagnosis chapter named. Treating AI as a worker is the move past it.
Decide the math can bend.
The Diagnosis chapter named the Headcount Paradox: every meaningful jump in revenue tends to pull a proportional jump in headcount along with it. This shift is the decision that the slope isn’t a law of nature. Redesign the work and the slope changes.
This is an operator decision. Revenue per employee stays fixed for your industry only as long as you don’t redesign the work. The companies whose numbers move are the ones that decided otherwise. Meridian’s quoting bottleneck was costing them roughly $558K a year. Elena didn’t believe the slope could bend until she ran the redesign math (that’s the Signal chapter’s work). The Sprints ahead are what bending the slope actually looks like.
Calculate your revenue per employee today: last year’s revenue divided by your headcount. Then ask the question that follows from this shift: what would it take to ship our next eight figures of revenue without adding the proportional headcount? If the question feels absurd, that’s the belief gap, and the gap is exactly what the framework is built to close.
Design the work, don’t do it.
If the math can bend, your own role changes too. The change shows up in where your hours go. You design and supervise the work instead of doing it. The execution work that used to anchor your week, the proposals you rewrote, the reports you reformatted, the routing you owned because no one else could be trusted with it, moves inside a system you designed.
This is the shift that’s easiest to misread. Read it wrong and it sounds like everyone’s now a manager of agents, on top of their existing job. Bedard and colleagues, writing in HBR (March 2026), found that operators who treat AI oversight as an add-on suffer measurably more fatigue and information overload, while AI that genuinely removes toil lowers burnout. The difference is the design decision: does your operating model add oversight on top of the job, or does it move the toil off the desk?
The job doesn’t grow. The composition changes. At Meridian, Elena’s hours didn’t expand when the agent landed. Fifteen hours of quote drafting moved off her desk; the four hours of pricing judgment that remained got sharper. That’s the shift in operating terms: different work, not more work. The rest of this book, the Co-Operating Model, the Sequence, and the two Design chapters, is the discipline of changing that composition on purpose instead of by accident.
Take stock before Sprint 1.
How to take stock of the operating-model gap
- Open your four core systems side by side — Forces the reader to look at the actual stack rather than describe it from memory, surfacing real friction points.
- For each system, name one place a person is doing work the system should be doing — Constrains the exercise to one item per system so the list stays actionable rather than becoming a complaint session.
- Record the list in the Sprint Planning Canvas table — Externalizes the gap so it can be handed to Sprint 1 as a concrete candidate-constraint input, not a vague feeling.
- Carry the list forward — do not solve yet — The chapter explicitly defers prioritization to the Signal chapter; the move here is observation, not intervention.
These shifts only matter if they change what you do this week. So before you start Sprint 1, do one thing.
Open your CRM, your accounting or ERP system, your project tool, and your communications stack on the same screen. For each one, write down a single place where a person is doing work the system should be doing. Don’t solve anything yet. Just take stock.
Meridian’s first pass at this listed the quoting bottleneck under CRM, the pricing exceptions trapped on Elena’s desktop under accounting, and the missing handoff to the shop floor under the project tool. That short list became Sprint 1’s candidate constraints.
| System | Where a person does work the system should be doing |
|---|---|
| CRM | |
| Accounting / ERP | |
| Project tool | |
| Communications | |
| Document store | |
| Other |
Meridian’s completed version, for reference:
| System | Where a person does work the system should be doing |
|---|---|
| CRM (HubSpot) | Elena manually drafts every custom quote; the bottleneck costs ~$558K/year in delayed closes |
| Accounting / ERP (NetSuite) | Pricing exceptions sit on Elena’s desktop — no one else can approve them |
| Project tool (Asana) | Shop-floor handoff still happens by phone call; no automatic task is created when a job is won |
| Communications | — |
| Document store | — |
| Other | — |
This list is Sprint 1’s first input. The Signal chapter prices your top item, and the entries you write here become the raw material for the Sprint Planning Canvas, the master worksheet you’ll build up across the book and carry into your first Design Brief. Keep the list. You’ll use it within a chapter or two.
Reflect on your operation.
- Look at the list you just built. Which constraint is costing you the most, measured in hours lost, dollars unearned, or decisions you’re personally absorbing? Which one have you been avoiding, and why?
- The last time your team talked about an AI use case, did anyone ask what scope is this worker accountable for, and who supervises the output? If not, what did they ask instead, and what did that framing miss?
- Of the work you personally did last week, how much required your judgment, and how much was execution someone (or something) else could do inside a design you set?
You’re already a tech company. The next question is how your people and your agents actually share the work. That’s the Co-Operating Model.