You’re Already a Tech Company: The One Shift the Rest of the Book Depends On

ImportantIn Brief

One claim does the work in this chapter: you’re already a tech company. Four shifts follow once that lands. AI is a worker, not a tool. Your people’s work rises as the routine moves to agents. The headcount math can bend. Your job is to design the work, not do it. The chapter closes with a gut check on what you now believe.

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 just need to run on systems at all, and 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.

That’s good news, and mid-market is where it lands hardest. You carry less legacy bloat than a large enterprise and run on more real systems 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.

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.

What that gap is, and how you close it, is the next chapter: the Co-Operating Model.

The first question to ask 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.

Adopt the AI operator mindset.

Once you see the company as already tech, four shifts follow. Manage AI like a worker. Elevate the work for your people. Decide the headcount math can bend. Design the work instead of doing it.

Manage AI like a worker, not a tool.

If your systems are the foundation everything runs on, the next question is what operates inside them. Most operators reach for software vocabulary: deploy, integrate, license, operate, use. That language described a tool you installed and used, one that 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.

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.

Elevate the work for your people.

The chapter opened with Argenti’s banker letting go of the 10%. The same shift reaches every role AI touches. When routine work moves to agents, the people who used to do it don’t end up with smaller jobs; they move up to the work the banker kept: judgment, relationships, the calls that need context no system can see.

The elevated job asks for skills the old one didn’t. The people who work best alongside agents learn to frame a problem clearly enough for an agent to run with, to plan how they’ll check its work, and to decide what matters most when suddenly everything is possible. The contributions a machine can’t hold carry more weight than they used to: institutional knowledge, taste, ethical judgment, reading a room.

This is the demanding part for you. Your people won’t pick up those skills on the side, and you can’t hire them in faster than you can grow them; someone from outside doesn’t know how your work actually runs. Reskilling is part of the design, not an HR afterthought. Name the new skills, build the time to learn into the work, and make plain why it matters and where it leads. In a company with a thin bench, that’s urgent: there’s no spare capacity to absorb the gap.

At Meridian, when the agent took over quote drafting, Elena’s junior estimator didn’t lose her seat. She became the one who frames the hard quotes for the agent and reviews its exceptions, higher-judgment work she’d never have had room for while she was buried in data entry.

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.

Design the work, don’t do it.

Designing the work just means answering one question: what’s the most efficient way this outcome happens? The steps, their order, and who or what does each one. You’re answering it for the whole team, not just your own desk: you’re deciding how a piece of work moves across everyone who touches it, people and agents alike. Your own role shifts first, and you can see it in where your hours go. 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. Your team’s routine execution moves the same way.

Done right, the work people used to grind through leaves their desks, and a lighter layer of oversight takes its place. It doesn’t pile agent management on top of everyone’s 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.

What you now believe

You don’t have to act on any of this yet. The redesign work comes later, in focused cycles we’ll call sprints (the Signal chapter runs your first one). For now the mindset shift is the whole point. This chapter made one claim and drew four shifts from it. Mark where you honestly land on each:

Claim Yes No We’ll see
We’re already a tech company.
AI is a worker to manage, not a tool to deploy.
My people’s work rises as the routine moves to agents.
The headcount math can bend.
My job is to design the work, not do it.

Anywhere you marked no or we’ll see is what the rest of the book is built to earn. You don’t have to believe it yet. You just have to be willing to test it.

Reflect on your operation.

  1. Of the four shifts in this chapter, which is hardest for you to accept, and what’s underneath that resistance?
  2. 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?
  3. 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.