About

Operator background

I spent five years as Chief of Staff at startups from seed through Series C. The job title sounds tidy. The actual work was anything but. On a given week I might be rebuilding the financial model for a board meeting, writing the spec for a product feature, sitting in on sales calls to understand why deals were stalling, and figuring out why the handoff between marketing and sales kept dropping leads. No single team owned those problems. They lived in the gaps.

Most of what I did was building systems that didn't exist yet. Compensation frameworks, planning processes, reporting infrastructure, cross-functional workflows. The common thread was connecting strategy to execution: taking something the leadership team agreed mattered and turning it into a process that people actually followed. That meant understanding how product, GTM, finance, and ops all fit together, because every system I built touched at least two of them.

The problems I gravitated toward were the ones that fell between chairs. Too strategic for any single function to own, too operational for the CEO to run directly. I got good at seeing where the seams were and stitching them together.

An engineering mindset for operational problems

Working across an entire company at that altitude changes how you see things. After a while, I stopped thinking about individual departments and started thinking about the company as a system: inputs, processes, outputs, bottlenecks, error modes. Where does information get stuck? Where do decisions queue up waiting for context that exists somewhere else in the org? What breaks when volume doubles?

That mental model turns out to be the same one that makes modern AI tools useful for non-engineers. You don't need to write code to think in terms of workflows, data flow, orchestration, and handoffs. If you can describe how information moves through a process and where it gets stuck, you can design an AI workflow that addresses the bottleneck. The thinking is the hard part, not the implementation.

And because my background is operational rather than engineering, the use cases I notice are different. They're the problems that are too small for an engineering backlog but too costly to keep doing manually. The report that takes someone four hours every Monday. The client onboarding checklist that lives in someone's head. The data reconciliation task that three people touch but nobody owns. Engineers rarely see these because nobody files a ticket for them.

What AI transformation actually takes

The tooling is the easy part. You can set up Claude or GPT in an afternoon. What's hard is everything around it: context capture (getting the knowledge out of people's heads and into a format agents can use), scaffolding (building the structures that let people work alongside AI instead of just poking at it), and adoption energy (overcoming the "I don't know where to start" wall that stops most teams before they begin). Pattern recognition matters too. Not every operations problem is AI-shaped, and knowing which ones are saves a lot of wasted effort.

Approach matters as much as expertise. People adopt tools when they feel met where they are, not when they feel talked down to. I take that seriously. The goal is to make someone feel capable, not dependent. If I do this right, teams stop needing me.

The internal champion problem is real. Most AI adoption stalls because there's no one inside the org who has enough context and enough conviction to push through the awkward middle phase where things are half-built and half-understood. A lot of my work is giving that person the vocabulary, the small wins, and the confidence to keep going after I leave.

A few examples from practice