Founder-Engineer Fit

Founder-engineer fit is the match between how a founder works, thinks and communicates and how an engineer does. Once an engineer clears the technical bar, it is the thing I tell early-stage founders to optimize for in their first three to five engineering hires, before team fit or culture fit can even exist. Brian Chesky looked for Airbnb’s first engineer for “four or five months” and interviewed hundreds of people before hiring Nick Grandy.[1] Sam Altman told the Stanford class in 2014 that “a single mediocre hire within the first five will often in fact kill a startup.”[2] Both were describing the same problem from different angles. The first engineers are not joining a company. They are joining you.

This essay is my attempt to name that problem, show where the fit actually gets tested, and lay out how I recommend founders hire for it. It comes from 16 years in and around early-stage engineering: I started as an engineer in 2010, spent the mid-2010s working directly with founders as one of the top freelancers on the big platforms (over $500,000 earned individually), ran a freelance agency and then a development agency, was an internal hiring manager for hundreds of roles at NBC, and since 2023 have been building TeamEx. Across those seats I have interviewed more than 2,000 engineers and worked with hundreds of founders on their first hires. What follows is what I saw building my own companies and what I observed in other founders, alongside the founders who said it before me.

Culture fit assumes a culture. At hire one, there isn’t one.

Most hiring advice is written for a company that already exists. “Culture fit”, “team fit” and “will they thrive here” all assume a here: a team with norms, a codebase with conventions, a process that tells a new person what good looks like. Google’s Project Aristotle, the study everyone quotes on team effectiveness, looked at 180 intact Google teams[3] with a median of nine members and found that psychological safety mattered most. True, and useless to a founder hiring engineer number one. There is no team of nine. There are the founders, often two or three of them, a half-built product, and a person who will spend most of their waking hours talking to those founders.

Altman put the mechanism in one line in the same lecture: “Whatever the founders do becomes the culture.”[2] Peter Thiel said it from the other side in Zero to One: “No company has a culture; every company is a culture.”[4] At the start, the culture is the founder’s habits plus whoever the founder hires. So the fit that matters first is the fit with the founder. Team fit shows up once there are enough engineers to have a team dynamic, and culture fit once the company has habits that outlive any one person. The layers accrete in that order, and I think founders waste their first hires by interviewing for the third layer before the first one exists.

Figure 1. Team fit and culture fit are real, but they are not testable until there is a team and a culture. For the first handful of engineers, founder fit is the only fit you can judge.

What founder-engineer fit is

Founder-engineer fit has three parts: how the person thinks, how they communicate, and how they work. Thinking covers judgment under uncertainty, appetite for risk, and how they argue when they disagree with you. Communication covers whether they write clearly, whether they tell you when something is wrong, and whether a ten-minute conversation with them leaves you with more clarity or less. Work covers pace, attention to detail, and what they do when there is no process telling them what to do next.

Notice that none of these is “are they a nice person” and none of them is “are they a great engineer.” Both of those are necessary. Neither is the fit. The fit is whether their version of thinking, communicating and working meshes with yours closely enough that you can build something together without a manager, a process or a culture in between. It is not identical to co-founder matching, but the checklist overlaps more than people expect: tempo, how you handle being wrong, what you each do when the plan stops working.

An engineer who clicks with the founder does their best work, and one who doesn’t slowly goes quiet, however good they are. The research points the same way. The largest review of fit at work found that how well people fit their direct boss is strongly tied to how satisfied they are at work,[5] and Gallup puts the manager behind at least 70% of the difference in how engaged a team is.[6] At a startup of three people, there is no layer in between to absorb a bad match. For hire one, the founder is the manager, the team, and the company.

Fit is tested at the edges of a task, not in the middle

The clearest framing of where fit shows up came from JD Pruett, an AI researcher who ran seven hiring experiments and wrote them up on X on October 6, 2026[7]. He calls it a 20/10 philosophy: what he cares about in a teammate is what it is like to work with them in the first 20% and the last 10% of a project. The first 20% is framing, architecture and taste. The last 10% is “getting the damn thing in front of real people” and solving the small, inglorious problems of the last mile. The middle 70% is execution, which models increasingly do, and which classic technical interviews were built to measure.

I read that and recognized every early hire I have made. The first 20% of any task is where the founder and the engineer actually work together: you describe the problem, they push back, you debate the approach, you decide. Then they disappear into the middle 70% and build. You barely talk; their expertise and judgment carry that part, not your relationship. Then they come back for the last 10%: they show you what they built, you combine it with what you did, you argue about what is good enough, you ship. Fit is tested at the two ends. Skill is tested in the middle. And since the middle is the part that AI tooling is shrinking, the ends are becoming a larger share of the job.

The chart below is my version of his, with the founder’s side drawn in.

Figure 2. The founder and the engineer interact at the start and the end of a task. That is where how you think, communicate and work either meshes or grinds.

What the founders who got it right did for their first ten

None of the founders below used the phrase “founder-engineer fit.” All of them hired for it. John Collison put the stakes plainly: “no batch of ten people will have as big of an influence on the company as those first ten people.”[8] Here is how each of them tested for it.

Who	The rule, in their words	What it actually tests
Brian Chesky	The rule, in their wordsAsked everyone he interviewed: “If you had ten years left to live, would you take this job?”[1]	What it actually testsWhether they want to work with you specifically, not with a job
Patrick and John Collison	The rule, in their wordsWorked a week with most of the first ten before hiring them[8]	What it actually testsFit at the edges of real tasks, observed rather than interviewed
Mark Zuckerberg	The rule, in their words“I will only hire someone to work directly for me if I would work for that person.”[9]	What it actually testsMutual respect for judgment, both directions
Jeff Bezos	The rule, in their words“Will you admire this person? Will this person raise the average level of effectiveness of the group they’re entering? Along what dimension might this person be a superstar?”[10]	What it actually testsStrength in one dimension over absence of weakness
Ben Horowitz	The rule, in their words“Hire for strength rather than lack of weakness.”[11]	What it actually testsWhether you are optimizing for pleasantness by accident
Paul Graham	The rule, in their words“Relentlessly resourceful.”[12]	What it actually testsHigh agency when the process does not exist yet

The first engineers are a specific type of person

Most hiring content skips this part. The engineer who thrives at a 200-person company and the engineer who thrives as hire number two are different people, and the second kind is rarer. At 200 people, the documentation exists, the coding conventions exist, the PR template exists, QA exists, the on-call rotation exists. A very good engineer shows up, reads the docs, and does excellent work inside the system. At two people there is no system — there are founders with a half-finished idea. The job is to make that system while shipping, and to be fine with that.

George Mack’s excellent essay on high agency[13] describes it as three skills rarely found together: clear thinking, bias to action, and disagreeability. That is the profile. PostHog’s engineers call them “cracked”[14], which their 2024 newsletter glosses as “insanely good at something.” Whatever the label, the behavior is the same: when the spec is missing they write it, when the test suite is missing they test it themselves, when the founder is wrong they say so, and when the thing is 90% done they are the ones who get it in front of a user instead of polishing the 90%.

It is also not a 9-6 temperament, and I say that without judgment. Plenty of excellent engineers want a well-run system to be excellent inside, and the world needs them. They are hire number fifteen. Hire number two has to enjoy the absence of the system. In my experience, it is not skill or resume that separates the engineers founders fight over from the ones they pass on. It is whether they light up or tense up when you describe a job with no process.

Mistakes are cheap early and get expensive later.

A startup is a race to find what works before the competition does, and the fastest way to find out is to try things that fail. In the first year, the cost of a mistake is tiny: you have few users, a small database, and a product with a handful of moving parts. The learning from a mistake is enormous, because every failed attempt removes a branch from the search. Later, that flips. With real customers, years of records and a system where one broken component takes down three others, a mistake is expensive and teaches you less, because you already know most of what works. The engineers you hire first have to be calibrated to that early stage, where a quick, cheap mistake is how the company learns.

Figure 3. Early, a mistake costs almost nothing and teaches a lot. Later, it costs a lot and teaches little.

At this stage, engineers are not just people who write code. They are builders, and they make dozens of small product decisions every week: how a feature should behave, which approach to try first, what good enough looks like. None of those are strategic calls. The early engineer has to be comfortable using their own judgment inside their area, and comfortable finding out if they were wrong.

That is what a mistake means. It is rarely a broken line of code. It is a way of executing an idea in the area they own. The best early engineers I have worked with treat their own area like a startup. When they are working on a big feature, they build the smallest version fast, see what happens, and iterate. The ones who struggle start with ten diagrams, a full architecture review and two days of analysis before anything exists. In a large company that caution is worth paying for. In the first year of a startup, however, it is a tax on every decision. Early on, trying it is the analysis.

None of this is permission to be sloppy. Trying, finding out and iterating should be rewarded more than over-analyzing.

My own fit profile, as a worked example

Founder-engineer fit is personal by definition, so the honest way to explain it is to describe mine. Four things decide whether I enjoy building with an engineer.

Pace. If something takes less than five minutes, I want it done now, not added to a list. My style is to handle the small things immediately and keep the big thing in focus. I have worked with excellent engineers who plan their day, prioritize carefully and work through the queue one item at a time. That is a legitimate way to work. It is not mine, and when we paired, both of us were slightly miserable. I felt blocked, and they felt interrupted. Neither of us was wrong. We did not fit.

Try and see. My default is to make the smallest version of a thing and watch what happens, for the reasons in the chart above. I need engineers whose default is the same, or who at least can switch into it when the cost of being wrong is low.

Call me out. I do not enjoy working with over-agreeable engineers. If my idea has a flaw and the engineer builds it exactly as I said, the flaw ships. Worse, I now know they will not catch the next one either. The people I have done my best work with disagreed with me early, with reasons, and then committed. Not every engineer does that, and it is a trait, not a skill, which you can see in the first conversation.

Details. Early, there is no QA team, no dedicated tester and no comprehensive automated suite. The engineer’s own testing is the testing. I need people who go beyond the normal happy-path check, who click through the thing as a user would, and who treat a sloppy detail as their problem. This is the other half of “try and see.” Experiments are welcomed. Sloppiness is not, even early, because it costs you the trust of the few users you have.

At TeamEx, some of the most capable people I have worked with in the early days did not match me. It showed in the pace of shipping and learning. Not one of them was a bad engineer. It was more of “great engineer” vs “my engineer”.

Three founders, three different fits

If fit is personal, then different founders should want measurably different first engineers, and they do. Three founders who hired through TeamEx make the point. The founder at Clipboard Health wanted high-agency, curious engineers who explore on their own and build before being asked. The founders at Maple wanted engineers who are great communicators, especially in writing, because writing is a large part of how they work. The founders at TopHelpers wanted generalists who could take care of several things at once, with one area of deeper expertise.

Those are three different searches, and the same engineer could be the right answer for one and the wrong answer for the other two. A head-down, brilliant builder who writes two-line commit messages would have been perfect for Clipboard Health and a poor fit at Maple. A deep specialist would have frustrated TopHelpers and delighted someone else. The best engineer in the abstract does not exist. What exists is the engineer who fits the person they will spend the next two years building with — and only that person can judge it.

The vibe match, and the other common mistakes

The first mistake is the one my own argument invites, so I will name it first. I like calling it a vibe match when a founder clicks with an engineer and hires them without a technical bar. It usually ends badly, and it is the reason I say fit is a tiebreaker above a bar, never a substitute for one. The data on unstructured interviews is unkind. “We had a great chat” is the sign of an unstructured interview that invites bad hires.

The second mistake is the opposite, which is interviewing only for the middle 70% of the task, the long flat stretch in Figure 2. A LeetCode round measures that execution, the part AI is absorbing fastest, and tells you nothing about the first 20% and the last 10%.

The third mistake is hiring the resume. A prestigious employer on a CV tells you the person passed that company’s bar for that company’s system. It says little about how they behave without one.

The fourth mistake is outsourcing the judgment. Peter Thiel’s line that recruiting “should never be outsourced”[4] is right for exactly this reason. An agency can verify skills, but it cannot know whether the engineer’s tempo matches yours.

How I would run the search today

Since fit is personal, the right search is personal too. Here is how I would set up a TeamEx search for my own first engineer, as of this month. Everything below is a real filter in the engineer search: the specialty and expertise filters, labels for how they work, think, and communicate, and custom criteria written as plain-English sentences about the engineer you want.

Example

Plain-English query

“AI engineer who has built LLM products from scratch at a pre-seed startup, ships fast, tests their own work, and pushes back when I’m wrong.”

Specialty and expertise

AI engineerLLM applicationsAgentsEvals

Skills

PythonTypeScriptLangGraphVector databases

Products built

Recruitment platformTwo-sided marketplace

Professional strengths

High AgencyBias to ActionThrives in AmbiguityClear CommunicatorTakes Ownership

Company stage worked at

Pre-seedSeed

Custom AI criteria

None of it replaces the interview. It only gets me to a shortlist of people we would enjoy working with.

When Founder-Engineer Fit stops being the only test

Founder fit keeps mattering, but somewhere around the fifth engineer it stops being the only test. At that point a team dynamic exists and team fit becomes testable. Can this person work with the four who are already here, not only with me? Somewhere past fifteen, habits outlive individuals and culture fit becomes real. Founder-led hiring as a practice runs through roughly the first 50 to 100 hires, with the founder keeping the final interview even after a recruiting team takes over sourcing. But the specific, intense, personal fit that this essay is about is a first-five phenomenon.