Insights/Client case notes

Staffing a data platform team from two engineers to nine

Twelve months, three seniority bands, and the two hires we got wrong first time.

[Author name], [Role] · [15 Jul 2026] · 4 min read
Engineers working together at their monitors in an open office
Fig. 01 — The squad as it stood at ninePhoto: X (@disruptxn) / Unsplash
TL;DR
01Two engineers to nine over twelve months, in three waves. The waves mattered more than the total — hiring the same nine people faster would have gone worse.
02Both hires we got wrong were sourced against a stack rather than against a first-quarter outcome. Both candidates matched the brief exactly.
03The lead hire should have come first. We filled it third, and the five months before it were spent on decisions nobody had authority to make.
04Onboarding capacity, not sourcing, was the real constraint. Beyond roughly two starters a month the existing team stopped shipping.

his is a case note rather than a success story, and the useful parts are the two hires we placed and should not have. Client details are withheld, and the figures in brackets are theirs to release.

The engagement: a [sector] company with a two-person data platform team supporting [number of analysts] analysts and a product org that had started depending on their pipelines for things that were not analytics any more. Over twelve months the team went to nine, all in the Philippines, all employed rather than contracted.

Where it started

Two engineers, both strong, both approaching the point where the thing they had built required more operational attention than two people could give it while also extending it.

The brief that arrived described five roles and listed technologies. We asked the first-quarter question — what will be true in ninety days that is not true now — and the answer came back as a list of systems to be built. That should have been the first warning, and we moved to sourcing anyway, which is how the next section happened.

Wave one, months one to three: three engineers. Two mid, one senior, all on pipeline and ingestion work. Those three were straightforward and all three are still there.

Wave two, months four to seven: two engineers. This is the wave that went wrong.

Wave three, months eight to twelve: a lead and three more engineers. The lead should have been wave one.

The two we got wrong

Both were technically excellent. Both matched the written brief precisely. Both left within [how many] months, and in neither case was the reason anything a technical screen would have found.

The first was hired against a stack. The brief named a specific orchestration tool and we sourced someone who had run it at scale for four years. What the role actually needed was someone who would spend their first six months arguing with product teams about data contracts, because the pipeline failures were not technical failures — they were upstream schema changes nobody had agreed to tell anyone about. We hired a deep specialist into a job that was mostly negotiation. They were bored by month three.

The second was a seniority mismatch in the direction people do not expect. We placed a strong senior engineer into a team with no lead, where the honest job description was "decide what this platform is". That is a lead's job. They did it anyway, informally, without the authority to make anything stick, and then left for a role where the title matched the work. We cost them a year and the client a restart.

The common cause is the same in both: we sourced against the document instead of against the outcome, and we did it because the intake answer was a list of systems and we did not push back hard enough to get a better one.

What the second attempt changed

Three things, and they are now standard on any multi-wave engagement we run.

The lead comes first. If a team is going to triple, somebody has to own what it is becoming, and that person should be in place before the people whose work they will shape. Filling the lead role in month eight meant five months of decisions made by people without the standing to make them, and several of those decisions were unpicked afterwards.

Brief against the first quarter, not the stack. The rewritten brief for the remaining roles led with "will have renegotiated data contracts with [number of product teams] product teams" rather than a technology list. The candidates that attracted were different people, and the two strongest had never used the orchestration tool the original brief required. Both learned it in a fortnight.

Rate the hiring to onboarding capacity. Past roughly two starters a month, the existing team stopped shipping and became a full-time onboarding function, which produced a visible dip in month [which month] that looked like a hiring success on the headcount chart. Wave three was deliberately slower than the client wanted and arrived earlier in useful terms.

Where it landed

Nine engineers: one lead, three senior, five mid, against an original plan of ten built almost entirely at senior level. The shape changed because the lead, once in place, argued for it — which is the most direct evidence we have that the sequencing was the real mistake.

If you are about to triple a team: hire the person who will own it first, write the brief as an outcome, and be honest with yourself about how many new people your current team can absorb in a month. The sourcing is rarely the hard part.

Related reading