Over the last several months, we took Claude Code from one person, me, to every function in the company. Engineering, ops, marketing, HR, pre-sales. Today the whole organization runs on it.
This is the honest version of how that happened, what worked, where we held back, and what I would tell another technology leader thinking about the same move.
It Started With Me
I am a hands-on, technical co-founder, so I did not delegate the first experiment.
I picked up Claude Code myself and used it for real work: writing code, doing code reviews, running tests, and reviewing other people's work. I wanted to understand the tool before I asked anyone else to change how they worked. That turned out to be the most important decision in the whole rollout.
You cannot lead an adoption you have not lived.
Developers First, Because They Were the Easy Win
Once I was convinced, we started with developers. That was the natural entry point, and it moved fast.
About 40 to 45 engineers reached full adoption in roughly a month to a month and a half. There was no mandate and no long change-management program. Once one developer saw another cut review time or debugging time, the behavior spread on its own.
That was the first useful lesson: when the value is obvious, you do not need to force adoption.
Ops and SRE: Where We Drew a Hard Security Line
Our managed services and SRE team runs many services across Kubernetes clusters for multiple customers. This is where I made a decision I have not reversed: we never install Claude on our servers. Not once.
In my view, it is not secure enough yet to sit on production infrastructure, so it lives only on laptops, desktops, and workstations. That is the boundary.
So how does an ops team use it if it is not on the server?
We treat Claude as a co-pilot, not an operator. The SRE engineer pulls a log snippet or describes the observation, and Claude walks them through troubleshooting step by step. When an error shows up that nobody has seen before, they paste it in and Claude does the research and comes back with the likely causes. That alone kills a lot of Googling and SOP hunting.
The part that surprised me was the value of source-code access. Because Claude is on the engineer's workstation, it can look at the actual source while troubleshooting and trace where a symptom is coming from. That makes the research far sharper than a generic web search.
The lesson here is simple: the security constraint, laptops only, did not weaken the tool. It just changed the shape of how we use it.
The Thing Nobody Talks About: Context Management
If I had to name the single biggest investment we made, it was not licenses. It was context management.
We put real effort into training everyone on how to feed Claude the right context without flooding it. I wrote a few internal articles on this and made them required reading.
This is the unglamorous skill that decides whether the whole rollout works. Good context in means useful output. Sloppy context in means noise. Every team that struggled early was struggling with context, not with the model.
By this point we were a team of roughly 60 to 65 people on Claude, on the team plan, with about 80 percent on Pro and the rest on Max.
Marketing, and the Dedicated Agent Laptop
I expected marketing to be the hard function. It was the opposite.
They moved about 90 percent of their work onto Claude Code, everything except video generation. Posting to LinkedIn and Instagram, reviewing content, checking Google Analytics, and working across their different marketing tools all runs through Claude with the Chrome extension driving the browser.
The operational wrinkle worth sharing is this: we had to dedicate a separate laptop for it, one that nobody uses directly and that is only accessed remotely to run as an agent. Think of it as an agent workstation.
If you are going to let a tool drive a browser and post on your behalf, give it its own machine.
HR, and the First Subscription We Cancelled
HR was where the ROI started showing up as line items we could delete.
Our AI team built agents to handle day-to-day HR work: leave approvals, vacation approvals, and the tracking around them. Once those agents were live, we were able to drop some of the SaaS subscriptions we had been paying for. Most of the routine HR workflow migrated over.
That was the first point where the story stopped being about productivity alone and started being about direct software-spend replacement.
Pre-Sales, the Hardest and Most Rewarding Function
Pre-sales was the toughest conversion and the one I am proudest of.
We started in June 2026 and expect to be fully switched over by the end of July 2026.
The first move was to cancel HubSpot and build our own CRM so it matches our actual workflow instead of forcing our workflow into someone else's product. It has been live for about a month and it is far more efficient. It also has AI built in: I can paste a Zoom meeting summary and it updates the CRM on its own. It researches, extracts the details, and proposes updates to deals, tasks, and contacts.
There is still a human in the loop. Pre-sales reviews the proposed changes once, clicks a button, and everything updates.
On top of that, we now generate daily activity reports and pre-meeting briefs automatically. Before a meeting, Claude prepares the research and helps us think through how to approach the account.
The real challenge was not the technology. It was getting a non-technical pre-sales team comfortable in Claude Code. We pushed through that because Claude Code was the best way we found to keep context clean across many accounts at once.
Here is the structure that made it work:
- Every account and every deal gets its own folder holding all prior history for that relationship. That folder is the context.
- Marketing owns one common folder with all shared assets: brochures, service descriptions, comparisons, and sample contracts.
With that setup, the team uses Claude Code to build proposals, run requirement analysis, draft PRDs for engineering, write meeting minutes, update the CRM, and prepare briefs.
The folder-per-deal discipline is what keeps context from bleeding between accounts. It is a simple idea, but it carried a lot of weight.
Where We Still Have Room to Push
We are not done.
Pre-sales still has more to automate, and video generation in marketing is still a manual island. There are places where Claude could go deeper: tighter feedback loops on the ops side, more of the proposal-to-engineering handoff running end to end, and more of the daily reporting becoming fully hands-off.
The honest read is that adoption is at 100 percent, but depth of use still has headroom in every function.
What I Would Tell Another Technology Leader
A few lessons stand out after doing this across the whole company.
Start with yourself. If you are technical, do not hand the experiment to a team and wait for a report. Live it first.
Draw your security lines early and stick to them. Ours is simple: never on servers, laptops and workstations only. The constraint shaped a better usage pattern instead of blocking us.
Invest in context management before you scale seats. It is the real skill, and it is what separates teams that get value from teams that get noise.
Let adoption pull rather than push. Developers spread it to each other. The wins were visible enough that people wanted in.
Be willing to rebuild instead of renew. The subscriptions we cancelled, a CRM, some HR tooling, and others, were not just cost savings. Replacing them with systems that match our exact workflow made us faster in ways the old tools never could.
The end state is worth stating plainly: one tool, adopted across every function, with a clear security boundary and a real discipline around context. That combination is what made it stick.
