Operator and builder.

Most people I respect in tech are either operators or builders. Operators run the business, they understand the constraints, the politics, the daily texture of decisions made under pressure. Builders make the products, they understand the technology, the design, the craft of making something out of nothing.

These are usually different people. The operator is too busy operating to build. The builder is too busy building to operate. They occasionally meet at meetings where they fail to understand each other.

I've spent my career trying to live on both sides of that line. Some of that was design. Most of it was accident. But the longer I've done it, the more I think being both is the rare and useful thing, and the more I want to write down what I've learned about how to actually do it.

This is that note. Less a framework, more a working theory.

---

The two halves don't blend. They alternate.

The first thing I had to give up was the idea that being operator-and-builder was about integrating the two modes. It isn't. They're different cognitive states, and they require different conditions to do well. You can't run a P&L review and a product critique with the same brain at the same time. You can do them on the same day, but you have to switch, fully, ruthlessly, on purpose.

When I'm operating, I'm reading the room, managing the politics, sequencing the conversations, holding the relationships. The job is to keep the system running and the people aligned. Output is coherence.

When I'm building, I'm in a different mode entirely. The room is gone. The politics are gone. The output is the thing itself (a working prototype, a clean piece of code, a piece of writing that says what it actually means). The audience is internal.

Most operator-builders I've watched fail try to do both at once. They build in meetings, they operate in design reviews. The work gets contaminated. Better to fully switch, even if the switch is jarring, and then trust that the combination will happen at the synthesis level, not the moment-to-moment level.

I switch on a calendar. Day job is operator. Nights and weekends are builder. Within each, I try to be fully present. The combination only works because each side is taken seriously on its own terms.

The operator side makes the builder side less stupid.

I have built products that nobody wanted. I have written code for problems that didn't exist. I have shipped beautiful, considered, useless things.

The difference between my early building and my current building is the operator instinct that came from years of being on the other side. The instinct that asks, before any line of code is written:

• Who, specifically, has this problem?
• What are they doing today instead?
• What does the room look like when they have to use this?
• Who is going to say no, and why?
• What does the second-quarter version of this look like?

These are not engineering questions. They are operator questions. They are also the difference between a product and an artifact.

The vast majority of side projects I see from talented developers are artifacts (beautiful, clever, technically interesting, and disconnected from any actual customer reality). The builder's instinct optimizes for internal elegance. The operator's instinct optimizes for external fit. Both matter. The second one is usually missing.

If you're a builder thinking about starting something, the most valuable hire you can't make is an operator co-founder. The second most valuable is the operator instinct you cultivate yourself by deliberately spending time on the other side.

The builder side makes the operator side less trapped.

The reverse is also true, and it's the less-discussed half of the equation.

Operators who can't build are dependent. They depend on the engineering team to ship the thing they need. They depend on the data team to answer the question they have. They depend on the design team to mock the change they want. Their entire ability to act in the world is intermediated by other people's queues.

This creates a slow, quiet kind of learned helplessness. The operator who can't write a quick script, draft a basic prototype, or build a one-off tool starts to stop having the ideas that would require those things. Their imagination collapses to what's available through the existing process.

The builder skills don't have to be world-class. I'm not a great engineer. But I can stand up a Vercel project, write a Python script, build a working prototype in HTML, and reason about an API. Those modest skills make me a fundamentally different kind of operator. I can move when I need to. I can show, not just describe. I can prove a point with a working artifact instead of a deck.

This is the secret weapon nobody talks about. The operator who can build doesn't escalate as much. They iterate. And the people around them feel that, even if they can't name it.

The hardest part is the loneliness.

The operator-builder lives in a small middle ground. The pure operators don't quite trust you, you might disappear into a side project. The pure builders don't quite trust you, you might disappear into a meeting. You're not fully claimed by either tribe.

I used to think this was a problem to solve. Eventually I realized it was just the shape of the position. The middle is small because most people pick a side. The smallness isn't a defect. It's the geometry.

What you trade for the loneliness is optionality. The operator-builder has more career paths, more relationships outside their immediate industry, more ways to be useful, more domains where their pattern recognition transfers. The cost is real, but the cost is paid in exchange for something that compounds.

For me, the compound has been worth it. Every time I've considered picking a side (going full operator, going full builder) it's felt like a downgrade. The middle is harder, but the middle is also where the most interesting work happens.

And then there's the work itself.

This is the thing I have the least good language for, but I'll try.

When I'm operating well, I sleep fine. The work is hard but it's legible. There's a system, the system has problems, you address the problems. There's craft to it, but it's the craft of a competent professional doing professional things.

When I'm building well, I don't sleep fine. The work is also hard, but it's illegible. There's no system yet, you're trying to bring one into existence from nothing. The reward is different. Less about coherence, more about having made a thing.

I think the people who insist on being only one or the other are denying themselves access to one of these two states, and I don't think it's possible to be fully alive professionally without both.

The operator state is satisfying.

The builder state is necessary.

I keep doing both because I've never been able to give up either one.