The startup canon says: "hire generalists, especially early." The advice is solid for the first 20 engineers — at that scale, versatility beats depth. But the same advice applied at 100, 200, 500 engineers produces a team that's broad and shallow. Nobody goes deep enough on the hard problems; everyone's trying to ship features in domains they only half-understand.
Engineering hiring strategy needs to evolve with team size. The generalist-only approach that worked at 20 fails at 200. The specialist-only approach (build a "platform team" of pure specialists) fails at 50. The art is composing the team deliberately at each scale.
Here's the framework.
What's a generalist? What's a specialist?
The definitions worth being precise about:
Generalist engineer: someone capable of contributing across the stack and across domains. Their value is breadth, adaptability, and end-to-end ownership.
Specialist engineer: someone with deep expertise in a specific domain — security, infrastructure, ML, database internals, front-end performance. Their value is depth, the ability to solve problems generalists can't.
The framing as a binary is too simple. Real engineers fall on a spectrum, and the most valuable ones combine breadth in some areas with depth in others. But for hiring decisions, thinking in terms of the spectrum helps.
Team size and composition
Engineering team size 1–20: heavily generalist
At this scale, the work changes constantly. Today's frontend bug is tomorrow's API design is the day after's deployment crisis. Specialists at this size become bottlenecks; generalists become multipliers.
Target composition: 90% generalists, 10% specialists (and the specialists are usually CTO-level senior architects, not focused domain experts).
The discipline at this size: resist the temptation to hire a specialist just because the team is hitting one problem. Generalists can usually learn the specialist domain in 2–3 months, which is faster than the hiring process for the specialist anyway.
Engineering team size 20–60: hybrid composition begins
This is the inflection point. Some problems can't be solved well by generalists — security architecture, database scaling, ML infrastructure. The first specialists join here, but the bulk of the team remains generalist.
Target composition: 70% generalists, 30% specialists.
The first specialist hires are usually:
- Senior infrastructure / platform engineer
- Security engineer (if you're handling sensitive data)
- Senior data engineer (if data is core to the product)
Each represents a domain where the cost of getting it wrong exceeds the cost of hiring a specialist.
Engineering team size 60–200: specialists become essential
At this scale, specialists are essential to handle problems that require accumulated expertise. The generalist team is still the majority but specialized teams form for specific functions.
Target composition: 50% generalists in product engineering teams, 50% specialists in platform, infrastructure, ML, security, front-end performance, etc.
The org pattern: product engineering teams stay generalist-heavy (they own features end-to-end). Platform teams become specialist-heavy (they solve hard problems that benefit all product teams).
Engineering team size 200+: deliberate composition by team
Each team's composition is determined by its mandate. Product teams are generalist-heavy. Platform teams are specialist-heavy. The org chart explicitly designs this.
Target composition: varies by team type. The aggregate org might be 45% generalist, 55% specialist, but no team is the average.
What to look for in each archetype
The interview design for each is different.
Hiring generalists
The signal you're looking for: rapid learning ability and strong fundamentals. Generalists succeed because they can pick up new domains quickly; the foundation they build on is fundamentals.
Interview design:
- System design with novel scenarios. Not "design a Twitter clone" — "design a system to handle [specific problem you're actually working on]."
- Coding problems that test algorithmic thinking, not syntax memorization.
- Past project deep-dives focused on: what was the hardest problem, what was your approach to debugging when stuck, what did you learn that you'd apply differently.
- Discussion of technologies they don't know. Ask them to reason about something they haven't worked with. The quality of reasoning matters more than the correctness of the answer.
What you're filtering for: people who can take on any problem and learn what they need to. The "smartest person in the room" who happens to specialize in your stack is less valuable than the adaptable engineer who'll grow with the company.
Hiring specialists
The signal: demonstrable depth in the specific domain.
Interview design:
- Domain-specific deep-dive. Hour-long conversation about their domain at the depth a peer expert would engage at.
- Concrete project review. Walk through a system they designed in this domain. Probe trade-offs, alternatives considered, what went wrong, what they'd do differently.
- Hypothetical problem in your context. Present a real problem you're facing in their domain. Watch them work through it.
- References from other domain experts. Specialists are better assessed by peers than by generalist hiring managers.
What you're filtering for: people who go deep enough to be recognized authorities in their field, with the practical judgment to apply that depth to real problems.
Common mistake: hiring specialists with academic depth but limited practical judgment. They'll produce excellent papers and diagrams; they'll struggle to ship.
When to overweight generalists vs specialists
Generalists are the better hire when:
- The problem space is shifting (early-stage company, new product, exploring market fit).
- Headcount is constrained (each hire has to be broadly useful).
- The work is end-to-end feature delivery.
- The codebase is young and consistent.
Specialists are the better hire when:
- A specific domain is becoming a bottleneck (security incidents, infrastructure scaling, ML model quality).
- The codebase has aged and specific domains have deep complexity.
- Compliance or regulatory needs require expertise.
- The product itself competes on a specific technical capability (latency, ML quality, security guarantees).
The mistake teams make: hiring whichever archetype is "trending" in their network, instead of hiring against the team's actual gaps.
The hidden cost of specialist hires
Specialists have a hidden cost generalists don't: they need problems to solve. A specialist hired to solve database scaling problems will be unhappy and underutilized once the database scaling problems are solved.
The pattern: specialists hired for an acute problem often need to either (a) move into managing a specialist team, (b) shift toward generalist work (and resent it), or (c) leave the company.
The mitigations:
- Hire specialists when you have a sustained problem in their domain, not a one-time acute issue.
- Build specialist career paths that don't require management (principal engineers, distinguished engineers, fellows).
- Be honest with specialist candidates about the long-term trajectory of their domain in your company.
The senior engineer who's both
The most valuable engineers in growth-stage companies often combine deep expertise in 1–2 domains with broad capability across others. They're not pure generalists or pure specialists — they're T-shaped or M-shaped engineers.
These are the hardest to hire (limited supply, high demand) and the most valuable. They bridge the generalist-specialist divide, mentor junior engineers in their depth areas, and contribute broadly when needed.
The signal in interviews: they can go deep when needed and broad when needed. Their past work shows both specialized projects and generalist contributions.
When you find these engineers, pay above market and retain aggressively. They're 3–5x as valuable as either pure archetype in growth-stage contexts.
The generalist-vs-specialist debate is mostly resolved by team size and problem set. Early-stage companies should hire mostly generalists; large companies need deliberate hybrid composition; the highest-value engineers combine breadth and depth. Engineering leaders who get this composition right ship more, mentor better, and retain talent longer. The ones who don't end up with teams that are broad and shallow (everyone's a generalist) or rigid and underutilized (too many specialists for the problems available).
For related team building, see Building a High-Performance Team: 5 Frameworks.
