When to Hire Engineers, and Who to Hire First

Quick answer: Hire engineers when the bottleneck is capacity — well-defined work is queued and waiting for hands. Do not hire when the bottleneck is clarity, because every new person multiplies the communication cost of ambiguity and the onboarding is paid for out of your most productive engineers' time. Hire generalists who can own a slice end to end first; add specialists once there is something to specialise in. In a payments product, the first specialist is usually the person who owns money correctness.

At some point in the first year every founder asks the same question: should we hire two more engineers? It is usually asked in a month when the roadmap has slipped, and it is almost always the wrong question asked in good faith. The right one is narrower: what exactly is stuck, and would another pair of hands unstick it?

The running example, as in the rest of this series, is a cross-border money transfer product — GBP leaves London, EUR arrives in Lisbon. Payments are a useful case because the work divides badly and the mistakes are expensive, so staffing decisions show their consequences quickly.

Why does adding engineers to a late project make it later?

Fred Brooks made this observation in The Mythical Man-Month half a century ago, and it survives because the mechanism behind it is arithmetic, not culture. Three parts of it matter to you.

Communication paths grow faster than output. Four people have six possible pairs to keep in sync. Eight people have twenty-eight. Output, at its very best, grows in a straight line with headcount; the surface area of coordination grows roughly with the square of it. A good hire does not change that shape — only where the curve starts to bite.

Onboarding is paid for by the people who were already productive. The engineer who can explain why the payout retry logic looks the way it does is, by definition, the engineer who was writing it. For a month or two, a new hire converts your best person's time into someone else's context — and in a payments codebase of state machines, idempotency and reconciliation, that ramp is measured in months, not in a welcome week.

Some work does not divide. Designing the ledger, choosing the payment state model, deciding how a corridor is routed — these are one person thinking hard and then several people reviewing hard. Adding a fourth engineer to a problem with room for one produces meetings, not throughput.

None of this argues against hiring. It argues about timing: Brooks's law describes what happens when you add people to a project whose real problem was never headcount.

How do you tell a capacity bottleneck from a clarity bottleneck?

Do not look at the roadmap; the roadmap always looks like a capacity problem. Look at this week's board and ask what state the work is actually in.

Signs the bottleneck is capacity — hiring helps:

• A queue of tickets sits in "ready" with acceptance criteria written, growing faster than the team empties it.
• Engineers finish a task and pull the next one without asking you anything.
• The pending work is genuinely parallel: three corridors, four bank integrations, an admin tool that barely touch each other.
• Nobody is waiting on a decision. They are waiting on time.

Signs the bottleneck is clarity — hiring hurts:

• Half of "in progress" is blocked on a question only you can answer.
• Tickets begin with "investigate" or "figure out".
• Pull requests sit open not because nobody reviewed them, but because nobody is sure the behaviour is correct.
• You spend your day unblocking rather than deciding.

Here is the single test worth running. If a strong senior engineer joined on Monday, what would they be doing on Tuesday morning without asking you a question? If you can name a specific ticket, hire. If the honest answer is "reading the code and waiting for me", hiring converts your scarcest resource — founder attention — into a support obligation.

Clarity bottlenecks are fixed by narrowing scope, writing the thing down, deciding and deleting — not by supply. A clarity bottleneck disguised as a capacity one is the most common self-inflicted wound in an early engineering team: you hire, the queue still does not move, and now there is a payroll number that does not move either.

Who should you hire first?

Generalists who can own a slice end to end. Not "full-stack" as a CV keyword — a person who can take recipients can save a payout beneficiary from schema through API and UI to a release, and then watch it in production.

The reason is handoffs, which at small size are the dominant cost. One generalist ships that feature in days. Three specialists — backend, frontend, and someone who owns deploys — ship it in two sprints, most of which is waiting for each other. Each may be individually better; the system they form is worse.

What to look for: someone who has shipped and operated something in production, is comfortable outside their strongest layer, and can decide with incomplete information and write down why. That last point matters more than it sounds — in a small team, a decision nobody recorded gets re-litigated every six weeks.

Specialists make sense once there is something to specialise in — enough sustained work in one area to keep them busy, and enough consequence that depth is worth paying for. In a cross-border payments product the first specialist is usually the person who owns money correctness: the ledger, idempotency, the payment state machine, reconciliation against provider statements — the daily question of whether what you think you hold matches what the partner bank thinks you hold. That role earns its salary the first time it prevents a discrepancy nobody could otherwise reconstruct.

After that, order by pain rather than by org-chart template: infrastructure when deploys and incidents eat engineering days, mobile when the app becomes a real product surface, QA when regressions reach customers. One common early mistake — an "architect" who does not write code is not a first hire at five engineers. At that size the architecture is decided by whoever is in the code.

How does Conway's law shape your architecture?

Melvin Conway's 1967 observation: organisations design systems that mirror their own communication structures. Most people quote it as a warning. Treat it as a lever instead.

Left alone, Conway's law happens to you. Hire a "payments team" and an "FX team" in month three and you will get a network boundary between quoting and routing, whether or not one belongs there — and as we argued in why your first architecture should be a monolith, those two usually turn out to be one decision wearing two hats. The boundary appears not because someone designed it, but because two groups of people needed a contract to talk across.

Used deliberately, the sequence reverses: decide the architecture you want, then form teams to match it. Two consequences:

• One team means one deployable. Splitting services ahead of teams buys every cost of a distributed system and none of the autonomy that justifies it.
• A genuine second team is a genuine architectural signal. When two teams start blocking each other on the same release, you have a real boundary — the topic of when to split the monolith. Splitting to match a team you plan to hire is speculation; splitting to match a team that exists and is contending is engineering.

Your hiring plan is therefore an architecture document, whether or not anyone reads it that way. The org chart you build over the next two years is the system you will be maintaining in three.

What changes at 3, 8 and 15 engineers?

Rough thresholds, offered as guidance rather than law. The real trigger is always contention, not headcount — but the ranges are where contention tends to show up.

The step from three to four is bigger than it looks: it is where implicit knowledge stops working. The step from eight to nine is where you stop running an engineering team and start running two, and someone's actual job becomes the interface between them.

What does a wrong hire cost in a small team?

More than the salary, and more than the share of the team they represent. In a team of four, a wrong hire is not 25% of capacity lost — it is negative capacity. Their work needs reviewing, correcting and occasionally reverting; a senior becomes a part-time supervisor; the ambiguity spreads. In the money-correctness areas it is worse, because a plausible-looking wrong contribution to a ledger is the most expensive kind of code there is.

The defence is not a cleverer interview. It is a probation period that is actually real:

1. Written expectations on day one, specific and observable. Not "ramp up quickly" — "by week four you are shipping small changes to the payouts module without a walkthrough; by week eight you own a feature end to end."
2. Honest feedback weekly, in both directions, from week one. Most probation failures are visible by week three and get discussed in week eleven.
3. A genuine willingness to end it. A probation you were never going to act on is just a word in a contract.

The kind thing is early clarity, not delayed hope. Someone who is not working out usually knows before you say it, and every week you postpone costs them too.

One caveat: probation length, notice periods and termination rules vary substantially between countries and should not be inferred from a blog post or copied from another jurisdiction. Get local advice on the mechanics, then run the substance properly.

What are the alternatives when the constraint really is time?

Sometimes the diagnosis is clear — the work is defined, the queue is real — but hiring is too slow for the deadline. There are four honest options, each genuinely better than the others in some situation.

Two honest observations. First, none of these fixes a clarity bottleneck. If you do not know what to build, no supply of hands helps, and an external team will surface the ambiguity faster and more expensively than your own engineers would. Second, the most under-weighted variable is not rate or location — it is whether the people have worked together before. A team that has shipped together has already made its coordination mistakes; a newly assembled group of equally strong individuals has not.

For the fuller comparison, including where in-house genuinely wins, see dedicated development team vs in-house.

And the disclosure, rather than implying a neutrality we do not have: GPO-Tech is one of these options — row two, with row two's disadvantage as well as its advantage. If the honest answer for your situation is "hire in-house and wait the extra two months", that is a fine answer, and we will say so.

FAQ

How many engineers do I need to build a cross-border payments MVP?
There is no honest fixed number — it is set by scope, corridors and rails, and how much compliance tooling you build versus buy. The reliable part is the shape: a few strong generalists on one modular monolith, with money correctness explicitly owned by someone. Adding people before that shape exists slows you down.

Should my first hire be senior, or can I start with juniors?
Juniors multiply capacity only when someone has time to supervise them, and at one to three engineers that time comes out of the hours you have least of. Early hires need to operate without a guide. Juniors become a good investment in the four-to-eight range, when named owners can mentor inside a bounded module.

When do I need an engineering manager or a CTO?
When coordination itself becomes a full-time job — usually around eight-plus, or earlier if you spend most of your week unblocking rather than deciding. Before that, a manager mostly adds a communication path. Hire the role when the bottleneck is the thing that role removes.

Could a product manager fix my clarity problem instead of an engineer?
Sometimes, and it is worth considering seriously. If the ambiguity is about what to build and for whom, a product hire can genuinely remove it. If it is about how — boundaries, data model, sequencing — that is an engineering and founder decision, and no process will make it for you.

How long should a probation period be?
The legal mechanics vary by country and are worth checking locally rather than copying from elsewhere. The universal part: expectations written down on day one, honest feedback every week, and a real willingness to act. A probation used properly is fairer to the person than a vague one used never.

Does a bigger team mean we should move to microservices?
Only if the bigger team is actually contending — two teams blocked on the same release, or a component with its own reliability or compliance requirements. Headcount alone is not a reason. The reverse deserves more attention: because your architecture will come to mirror your org, deciding to form a second team is deciding to create an architectural boundary. Make that choice on purpose.

Thinking about your next engineering hire?

The decision is usually simpler than it feels. Open the board and sort what is stuck into "waiting for hands" and "waiting for a decision". If the first pile is bigger, hire. If the second is bigger, spend a week deciding and the queue will move without a single new contract.

GPO-Tech builds commercial software and connected products from Tallinn, Estonia — inside the EU, in European working hours. Our founder has run an engineering company since 2019 and spent two and a half years on Wise's core payment platform team. Our teams are established: the engineers on them have worked together for years rather than being assembled for your project.

Tell us what is stuck and we will help you work out whether it is capacity or clarity. Ask a question → or book a call with our engineers →.

GPO-Tech designs and builds connected products and commercial software end to end — from one team in Tallinn, Estonia.

Request a quote →