The Right People for an Early Team

Most founders I work with overhire too early on credentials and underhire on judgment. They reach for the resume that looks impressive on paper and end up with someone who is technically right but contextually wrong. The person can do the work, but they cannot do the work that the company actually needs right now.

I have been thinking about this a lot lately because of a pattern I keep seeing on early-stage projects. A specialist gets pulled into a startup and immediately starts solving for the company they imagine it will be in three years instead of the company it actually is this week. Security architecture meant for a regulated enterprise. Data pipelines built for ten million users when the product has ten. Test coverage strategies that would make sense at Series B but stall a pre-seed team trying to get to a first paying customer.

The skill set is real. The instinct to deploy it is wrong.

Domain knowledge is the floor, not the ceiling

You do need domain knowledge on an early team. I am not arguing against expertise. If you are building in healthtech, you cannot survive without someone who understands HIPAA, payer dynamics, and the reality of how a dental or medical office actually operates day to day. If you are building fintech, you need someone who knows what a chargeback flow really looks like in production. Domain knowledge keeps you from spending six months building something that the regulator, the customer, or physics will not let you ship.

But domain knowledge alone is dangerous in the wrong head. The trap is hiring a deep specialist who treats every problem as an excuse to apply their full toolkit. A security engineer who has only ever worked at companies with dedicated security teams will design for that environment by default. A staff engineer from a hyperscaler will design for that scale by default. They are not wrong about what good looks like at that company. They are wrong about what good looks like at yours.

What you actually need is someone with enough domain knowledge to keep you out of trouble, plus the judgment to know when to stop adding. The second part is the hard part.

Focus is a feature, not a flaw

Here is the lesson I keep relearning. A person who is great at exactly one thing is enormously valuable, but only if they know what that one thing is and only if they stay in their lane until you ask them to leave it.

The failure mode is the specialist who insists on driving strategy from inside their specialty. The security person who tells you what the product should be because of a threat model. The frontend engineer who tells you what the business model should be because of a UX preference. The data engineer who tells you what the company should care about because of what the metrics show. They are all sometimes right and they are usually wrong, because they are optimizing for one slice of a much larger problem.

You want focused people. You also want them to know they are focused. Self-awareness about scope is a real skill and it is rarer than depth.

You need at least one person who can do both

The other person you need on an early team is the opposite of the specialist. Someone who can hold the whole picture and still execute on a piece of it. A person who can sit in a strategy conversation in the morning, write a spec at lunch, and ship something to production by Friday.

These people are unicorns and you will not always find one. But you should at least look. The reason is that early companies do not get to separate strategy from execution. The CEO cannot hand the strategy down and trust that a team of specialists will translate it. There is no team yet. The strategy gets executed by the same three or four people who came up with it, and if any of them refuse to cross between thinking and doing, the whole thing stalls.

This is also why I am skeptical of early hires who frame their value as "I am the person who thinks about X." Thinking about X is not a job at a five-person company. Thinking about X and then actually doing X is the job.

AI fluency is now part of the hiring bar

This is the part I would have written differently a year ago. Today I think anyone joining an early team needs to be at least competent with AI as a working tool, and the people who will multiply your team are the ones who are genuinely fluent.

I do not mean they need to be ML engineers. I mean they need to be able to use Claude or Cursor or whatever the current best tool is to compress their own work. A focused specialist who can use AI well will do the work of two or three of the same specialist from three years ago. A generalist who can use AI well becomes something close to a full product team in one person.

The opposite is also true and worth saying out loud. Someone who refuses to use AI tools, or who uses them poorly and produces sloppy output without checking it, is a drag on a small team. Not because AI is mandatory but because the cost of not using it is now too high. The work takes too long. The iteration loop is too slow. The competition is moving faster than you.

When I screen people now, I look for three signals. Do they reach for AI when it would actually help, instead of either avoiding it or using it for everything. Can they tell me what AI is bad at, not just what it is good at. And can they show me work where they used AI as a tool inside their own judgment, not as a replacement for it.

What I actually look for

If I am helping a founder build their first real team, this is the shortlist I push them toward.

One person with deep domain knowledge who has the discipline to apply only the parts that matter at this stage. Someone who can tell you why the obvious advanced solution is wrong for a company of your size, not just what the advanced solution is.

One person who is focused on a single craft and is honest about the boundaries of that craft. They will not try to run the company from inside their specialty.

One person, ideally a founder, who can hold strategy and execution at the same time. They will not need a handoff to translate a goal into a shipped thing.

Everyone on the team should be AI-fluent. Not as a buzzword, as a basic productivity assumption.

And everyone on the team should be able to say the words "that is not the right thing to build right now" without feeling like they are giving up on quality. Because the actual definition of quality at an early company is shipping the thing that moves you to the next stage, not the thing that would be technically beautiful at a stage you have not earned yet.

The real test

Here is the question I would ask any candidate for an early-stage role. Tell me about a time you decided not to do the more sophisticated version of something. Tell me about a time you shipped the duct-tape version on purpose and you were right.

If they cannot answer, they are probably not ready for an early team. Not because they are not good at what they do, but because they have not yet learned the most important skill an early-stage operator has. Knowing when to stop.