Hire for the next transition

The first engineering team is not a smaller version of the team the company will eventually need. I think a lot of hiring mistakes start with getting that wrong.

An early-stage company runs under different constraints than a mature one. It’s less certain about its product, it has fewer people to spread the work across, and there’s a much shorter distance between any given technical decision and the company’s survival. The work itself is broader, too. An engineer hired to build a feature might spend the same week configuring infrastructure, sitting in on a customer call, debugging a deployment, writing an interview question, and helping decide what the company should build next.

It’s tempting to picture the engineering org as a building under construction. The first employees form a frame, and then you fill in the missing roles like so many window panes and sheets of drywall. Eventually you’ve got a complete organization that has the same basic shape as what you started with.

I don’t think that’s quite right.

The early team isn’t just incomplete. It’s a different kind of organization, built for a stretch of time when the company is still working out what it needs to become. Embracing the need to build distinct systems as you face different requirements — rather than trying to build a single one that seamlessly grows to handle all requirements — is a big theme in how I’ve come to think about most things in startups, including both the organization itself and the code the organization works on. So the first engineering leader isn’t there to design the final team. They’re there to build a team that can deliver now, hold onto what the company learns, and carry the whole thing through its next transition.

The early team has to own the learning

Very early companies are usually under real pressure to ship something.

You might need a working product to close your first customers, or to show investors some progress, or to raise again before the money runs out. Under that kind of pressure, hiring a contractor shop used to be the go-to way to turn cash into software without first building out an engineering org.

Contractors can be genuinely useful. They add capacity around an internal team, bring in expertise for a bounded problem, or help you get through a temporary spike in work. The trouble starts when you outsource the center of the product-development loop.

An early product iteration should produce more than code. It should teach you what customers actually need, which of your assumptions survived contact with reality, which shortcuts turned out to be worth it, and where the product keeps getting hard to change. Those lessons shape the next iteration, but they also shape the architecture and future growth of the org itself. You learn which capabilities you need to own, where you need real depth, and which parts of the system are quietly becoming strategic.

A contractor can hand you an artifact and document how it was built. It’s much harder to outsource the slow accumulation of judgment that comes from building, watching, and changing the same product over and over.

I’ve seen early companies that leaned hard on cheap contractor teams whose main advantage was inexpensive implementation labor. The code usually wasn’t very good, but it could be produced fast enough to get to the next demo or the next fundraising milestone. Sometimes that trade is worth making. It gets dangerous when nobody inside the company is close enough to the work to understand what was learned, or to shape the next version around it.

A full-time technical core should sit at the center of that process. That core person or set of people doesn’t have to write every line of code, but they need enough ownership to understand why decisions were made, which shortcuts were deliberate, what kept breaking, and what they would do differently for the next deliverable crunch.

Coding agents have changed the economics here, and I see a lot more founders setting out a token budget rather than outsourcing to a contractor shop. A big part of the historical value of low-cost contractors was access to implementation labor that was cheaper and easier to manage than a local full-time team. Coding agents now hand some of that leverage directly to founders, and the results can be pretty remarkable. A driven person with a laptop and a business bank account they can charge their Anthropic or OpenAI bill to can make real progress on an MVP and initial product-market fit.

That doesn’t change the need to accumulate understanding, though, or the need for someone to oversee the evolution of that fledgling codebase into something that can solve customer needs in production. And as much as AI helps in all aspects of our work, it doesn’t add more hours to our day. Even the most technically-minded and product-obsessed founders are still human, still only have 24 hours in their day, and still need someone to keep all the technical context in their brain as they juggle customer outreach, go-to-market planning, fundraising, and the myriad of other responsibilities that seem to hit you out of nowhere when you’re suddenly caught up in the day-to-day of building a company.

A lot of the challenges we had to focus on overcoming just to get something out the door are waning away. The scarce part is increasingly the judgment: deciding what to build, understanding what actually happened, and carrying that into the next iteration. That belongs inside the company and it’s something you should think about hiring for early.

Generalists still need a mandate

There’s another common response to all this uncertainty: hire an exceptional generalist and trust them to figure everything out.

The common case here is the founder who knows the product isn’t good enough but only has a fuzzy read on the customer, the problem, the architecture, or even the definition of success. Without being able to resolve any of those things, the hiring plan quietly becomes a search for someone talented enough to absorb all of that ambiguity and produce a great product with almost no direction.

Strong early engineers do need unusual range. They have to make progress with incomplete information, chase problems across technical boundaries, and notice which parts of the work need more structure. But “hire a rockstar” is not a substitute for deciding what you need them to accomplish.

Every early employee should have a clear place where they can deliver value right away. I like to give each hire an initial mandate: a concrete problem they can own, and a meaningful thing they should be able to point to after their first hundred days. There’s nothing magic about a hundred days. It’s just long enough to actually learn something and short enough that “still ramping” can’t quietly become the entire plan. The mandate has to matter to the business. You’re hiring because something important needs to change, not because it’d be nice to have another smart person in the building.

It matters just as much for the employee. Early-stage companies are confusing places to land. Responsibilities are broad, context is spread around unevenly, and there are always more useful things to do than anyone can clearly rank. A new hire can spend months being busy without any idea whether they’re succeeding, or whether the rest of the team thinks their work matters. A clear mandate gives them somewhere to stand. It lets them build context around a real problem, show how they work, and earn some credibility — and that credibility is exactly what they’ll need later, when they want to challenge an assumption, propose a bigger change, or take over something still poorly defined.

The mandate has to describe an outcome, not a category of work. “Improve the frontend” isn’t a mandate. “Deliver the first complete workflow for this user problem” might be. “Help with infrastructure” is just as vague; “make customer deployments repeatable enough that they no longer live in one engineer’s head” describes a result both sides can actually recognize.

None of this is meant to pin down someone’s whole long-term role. A generalist’s range should let them follow the problem as it grows — it shouldn’t let the company off the hook for defining the first problem at all.

Don’t hire the org chart before you have the organization

Past the very earliest stages of a company’s life, the early hiring mistake I’ve seen most often is trying to reproduce the shape of a mature engineering org before there are enough people or enough stable work to support it.

The plan usually looks reassuringly concrete:

• Two backend engineers.
• Two frontend engineers.
• One integration engineer.
• One DevOps engineer.

It looks like an engineering organization. It gives recruiters clean boxes to fill and gives non-technical founders the comforting sense that the hiring problem has been decomposed into manageable parts. The trouble is that early-stage work doesn’t show up in those proportions, and it doesn’t respect those boundaries.

The frontend engineer waits on an API from the backend engineer. The integration engineer swings between being underwater and having nothing ready to integrate. The infrastructure engineer becomes the only person who understands the deployment environment — and customer issues don’t check whether that person is around before they happen.

Before a company has a formal on-call, it still has an informal one. A customer hits an urgent problem, a deployment breaks, or the CEO calls someone at an odd hour because something important is on fire and there’s going to be a critical customer demo in four hours. A sustainable rotation usually needs more engineers than an early company has. I usually say eight or so people is a good rough planning number for a team that needs to support an on-call. Much less than that and your planned rotation schedule falls apart to sick days and vacations pretty quickly, which makes the schedule feel like a bit of a joke and can even breed some resentment. Much more than that is actually a problem, also: people end up going too long between on-call rotations and don’t develop/retain the core skills they need. Until you’re there, the team needs enough overlapping knowledge that the same person doesn’t catch every fire.

Over-specialized teams create utilization problems, too. Work rarely arrives at each specialty at a steady rate, and an early company can’t easily eat idle capacity in one area while another is the bottleneck.

The point isn’t that specialists are useless. Some early problems genuinely need depth a team of broad product engineers just won’t have — real expertise in infrastructure, security, data systems, or some particular domain. But early companies usually want generalists with technical leanings more than mature-company specialists with hard edges. A frontend-leaning engineer should still be able to work through an API or data-model problem when that’s what’s blocking the user experience. An infra-leaning engineer should be able to dig into application behavior and show up for customer deployments. A backend-leaning engineer should be willing to touch the frontend when that’s the shortest path to finishing the workflow.

This does make hiring less legible, but there’s no real way around that. The job descriptions will be broader. Recruiters won’t always be able to search for a clean title and a tidy keyword list. Candidates will need to understand that the role includes both the areas where they’re already strong and the areas where you’ll ask them to stretch.

That messiness is just an honest reflection of the work.

Generalists also happen to be well suited to the company’s next transition. As the team grows, they can deepen into their strongest areas, help define a real specialty, or hand pieces of their broad ownership to new hires. The first infrastructure specialist is far easier to bring in when someone already understands how infra connects to the product and the customer environment. The first dedicated frontend engineer is more effective when the existing team has enough frontend judgment to define the problems worth handing over.

The early team doesn’t need to avoid specialization forever. It needs to introduce specialization once the work is stable and substantial enough to sustain it.

Hire for the current phase and the next transition

The planning horizon I find most useful is the company’s current phase, plus the next transition you can see with reasonable confidence.

For each early hire, I’d ask four questions:

1. What’s their initial mandate?
2. Where can their ownership expand during the current phase?
3. What transition is the company likely to hit next?
4. What role could this person play in getting through it?

You should have a clear answer to the first, plausible answers to the next two, and enough understanding of the candidate to talk honestly about the fourth. Anything past that is mostly speculation wearing a planning costume.

An engineer might start by delivering an important workflow, then grow into ownership of the surrounding product area. The next transition might be splitting that broad area into clearer frontend, backend, and product responsibilities — and that same engineer might deepen into one of them, help draw the boundaries, or take on technical leadership across the group. Someone else might own customer deployments because that’s the most immediate problem, then build the first repeatable deployment system, then help hire the person with deeper infrastructure experience. The role keeps changing because success keeps changing the problem.

You don’t need to predict exactly where each person lands three years out. You need a credible account of how their work can evolve through the next stage, and enough flexibility to revise it as you learn.

That trajectory also has to line up with what the person actually wants. A broad product engineer might be perfectly capable of establishing an area and later handing pieces to specialists, and still resent losing the breadth they loved. An infra-minded engineer might cover product work for a while but really want to go deep on platform. An engineer might be happy to mentor without any interest in becoming a manager. Capability and motivation are separate constraints; someone can be able to make a transition without finding it rewarding. So the hiring conversation has to cover more than whether they can do the immediate work. It should get at what kind of responsibility they want more of, which parts of their current role they’ve outgrown, and what kind of engineer or leader they’re trying to become.

The first technical leader doesn’t need to design the final team. They need to build a team that can make the next team legible.

Small teams are path-dependent

A hiring plan can look neat before any candidates show up. The real team rarely does.

At three or four engineers, each new person changes the organization a lot. They don’t arrive as an interchangeable instance of “backend engineer” or “senior generalist.” They come with an irregular pile of domain knowledge, technical interests, product instincts, customer experience, communication ability, and habits picked up in previous jobs — and all of that should shape what you do next.

An engineer hired mostly for product work may turn out to have unusually sharp infrastructure judgment. Another might be great with customers, converting half-formed requests into tractable engineering problems. Someone else might have the patience to mentor less experienced engineers years earlier than you expected. You shouldn’t invent a role wholesale around whichever candidate you happen to like — the initial mandate still has to reflect a real business need — but once the person’s in the door, update your model of the org around the capabilities that now actually exist.

A hire with unexpected deployment chops might lower the urgency of the next infra hire. Someone with strong frontend instincts might free you to go looking for deeper backend experience next. An engineer who can mentor well might make it practical to hire for potential earlier than planned. At very small sizes, each hire changes both what the team can do and which hire makes sense after it.

This path dependency is another reason not to pre-build the org chart. Have a direction and a clear read on the next problems you need to solve, but accept that the exact route depends on the people who actually join. A good early engineering leader builds around those unpredictable strengths instead of treating them as noise around a staffing plan.

Hire for potential, not resemblance to yourself

The first engineering leader is often the most experienced technical person in the room during hiring. That can quietly distort the standard.

I started programming in middle school, kept with it in high school, did data analysis in my job after graduating before going to college for computer science, and have spent more than a decade doing this professionally since then. When I interview someone, it’s easy to notice all the things I know that they don’t. That’s not a very interesting observation. The relevant question isn’t whether a candidate knows everything I know — it’s whether they can deliver against what the company needs now, whether they can grow into the next scope, and whether their strengths make the whole team better.

I’ve watched experienced engineers set brutally high bars from the very first hire, sometimes measuring candidates against an idealized version of themselves. It feels rigorous. It usually ignores what the organization actually needs. An early company rarely needs five engineers who could each independently design the entire system. It might need one person with deep architectural experience, two strong engineers ready for broader ownership, and one more with domain knowledge or customer instincts the rest of the team is missing. A company that can spot and develop potential has access to far more talent than one that can only consume engineers somebody else already trained.

One way I apply this is by sometimes hiring at N-1. I’m borrowing the “N-1” language from Will Larson’s engineering seniority-mix model, where “backfill at N-1” means replacing a departing employee with someone one rung earlier on the ladder. I’m using it a little differently: hiring someone ready to grow into the scope the company needs, rather than someone who’s already done it. If I’ve got work that calls for senior-level scope, I’ll often prefer a strong mid-level engineer who has already shown parts of that level and is hungry to grow into the rest. The company gets someone motivated by the scope instead of someone for whom the role is a rerun of their last job; the engineer gets an opportunity they might’ve waited years for at a bigger company. It’s one of the better trades in the whole startup bargain — smaller companies usually can’t match the cash, the stability, or the support functions, but they can offer consequential work, broad ownership, and faster growth.

That doesn’t make N-1 right for every role. Some problems require experience you can’t safely develop through trial and error, and the team needs enough expertise and management capacity to actually support the stretch. And hiring for potential can’t mean handing someone senior expectations while withholding the title, compensation, support, or recognition that should come with them. That’s not development. That’s just under-leveling with better branding. The stretch has to be real, supported, and understood by both sides — real chances to operate at the next level, plus direct feedback about what’s working and where the person still needs to grow.

Developing talent isn’t an optional act of generosity you tack on after the real work of building the company. It’s part of building an effective organization. Engineering leadership includes creating credible opportunities for other people to develop judgment, take on responsibility, and build careers — a broader obligation than I can do justice to here, but one that should still shape how you weigh potential.

The first team should be able to build the next one

A foundational engineering team leaves an important legacy, and it usually isn’t the original architecture, process, or ownership model. Most of that should eventually be replaced.

The more durable contribution is holding onto what the company learns and turning it into the next version of the product and the org. That takes a full-time technical core with enough ownership to accumulate judgment, broad engineers who can follow unstable problems across boundaries, and clear mandates that give each new hire a real place to begin. It also takes a team that can change without treating change as a verdict on its earlier work.

The generalist who owned a whole workflow may eventually need to make room for specialists. The engineer who handled infrastructure out of necessity may need to write it down and hand it off. The whiteboard covered in post-it notes that tracks everyone’s work-in-progress will eventually need to be replaced by something more organized that can give broad groups of stakeholders shared visibility on execution timelines.

Strong cultural foundations are what make those transitions survivable: people who can disagree without making it personal, take direct feedback, and replace the very processes they built when conditions change. The operating model can stay provisional precisely because the team’s ability to reason and change together isn’t.

So build the team for the problems you have now. Give each person a clear initial mandate. Hire enough range to keep the team functional while the work is still unstable, and enough complementary depth to catch the problems generalists tend to miss. Then look one transition ahead — think about how ownership will expand, where specialization is likely to emerge, and what the people already on the team want to grow into. Update the plan around the real strengths of whoever joins, rather than forcing the team to conform to a diagram you drew before you’d met any of them.

Don’t try to design the final engineering organization before the company has earned the information to do it.

The first engineering team is not a smaller version of the eventual team. It’s the team that has to build the next one.