"Technical" is a capability, not a role

At some point I spent time in San Francisco exploring the idea of finding a non-technical co-founder. I had a clear picture of who I was looking for: someone with deep knowledge of one domain, fully committed, with a unique insight, who would own the business side, the go-to-market, the financing, the sales. So I could focus on the product.

Through YC's co-founder matching I met someone who looked like exactly that. We met in person a couple of times, it made sense on paper, and we decided to give it a try.

It fell apart on a definition.

In his model, he owned the vision. Not just the problem, the solution too. The technical co-founder was the person who received that vision and built it. So when I started asking questions about the strategy and getting into the roadmap, he told me plainly that it was a red flag for him. At one point he suggested that maybe I was just too smart to follow another person's vision. No hard feelings toward the guy, honestly. The matching process did its job. A fundamental disagreement about what we were to each other surfaced in a few weeks instead of a few years, and that is the cheapest price anyone will ever pay for that lesson. But it made me think about that sentence a lot, because underneath it sits an assumption I think is simply wrong: that a technical person is a person who only does technical things. That knowing how to build something somehow subtracts from your ability to think about what should be built and why. It is the opposite. Strategy is not a department. It is a conversation between people who each see a different part of the terrain, and the person who knows what things cost to build sees a part of it nobody else can.

I know this from the other side of the table. On a previous business I was the CEO and my co-founder was the CTO. We never worked by handoff. Vision and roadmap were settled in conversation: he brought the insight from the technical side, I brought the customers, the go-to-market, the design. The weight shifted depending on the topic, but nobody was outside the decision. I would never have emailed him a spec and called that a partnership.

And I am not the only one drawing the line here. YC's Dalton Caldwell and Michael Seibel made a whole video about the mirror image of this question, whether you need a business co-founder at all. Their argument: the non-coding work of a startup, the sales, the fundraising, the hiring, the talking to customers, is smart generalist work that a technical founder is fully qualified to do. What separates teams is not credentials but the appetite to do that work well. Some of the most valuable companies ever built, Google, Nvidia, Microsoft, started with technical founders only.

With a co-founder, the line is easy to draw. If one person hands down the vision and the other person executes it, you do not have a co-founder. But this is not only about co-founders. It is the same mistake wherever technical people work: the engineer who gets handed a spec instead of a problem, the product person who receives requirements instead of shaping them. It was always a waste, but AI turns it into an absurdity, because the part of the job being automated is the typing. What remains of a technical person is precisely the judgment: what to build, what to skip, what a choice will cost you later. Treat them as an executor and you are paying for the one part of the job machines already do, while throwing away the part they cannot. Yes, I will probably spend most of my hours building. That tells you where my time goes. It tells you nothing about where my judgment stops.

So that is what the word actually means. Put it in front of co-founder, or product person, or engineer, and it names a capability added on top of everything the role already is: the ability to turn decisions into working product. It says nothing about which decisions the person can be part of. And this is not an argument about finding the right partner. Hiring someone to support you is a perfectly good call. The mistake is drawing the boundary once they are in, because the boundary does not protect anything. It just caps the value they can create for you. You paid for the whole capability, judgment included, and you are using only the slice the market is busy making cheap.