Sourcing, Headcount & Offers

The loop decides who passes; this part decides who enters it, how many roles you actually run, and how you close the people who clear. It is the business layer around the interview.

Sourcing works when the ideal-candidate profile is written down and weighted. For a platform role the weighting that predicts success is: the arc into the domain through software engineering, startup experience with metric-driven impact, and genuine cloud-native depth — with a bias toward people who build automation that operates systems rather than merely using tools.

An AI-assisted review can score each sourced candidate against the pillars, but the rule is non-negotiable: a human QAs and edits every call before it enters the tracking system. The output is a tri-state — strong yes, yes, no — with a ranked "first to move on" shortlist so the recruiter knows the order to work. Treat the machine as a fast first reader whose homework you always check, exactly as you'd treat AI anywhere else in this system.

Run the ICP against a real batch and read the distribution. A healthy review of, say, two dozen sourced profiles might land a small handful of strong-yes, a larger band of yes, and a chunk of no. If everyone is a yes, your filter is too loose; if no one is, it's too tight or the sourcing is off-target. The batch is also where the profile sharpens — you discover which signals actually correlate and fold them back into the next search.

The most common headcount mistake is opening a req without agreeing its target level. Decide it first, because it flows into the job description, the sourcing bar, the loop's expectations, and the eventual band. Tie each open role to a priority tier and a target level — for example, higher-priority roles anchored a notch below your median and expected to reach at least upper-mid level. When a team is top-heavy, deliberately pull in more junior people: it creates mentorship surface and the capacity to eat backlog that senior engineers won't.

Leadership may approve six roles; recruiting bandwidth may realistically fill three a quarter. Force the distinction. State the absolute priority count for this quarter versus what defers to next, and tie each req to a rationale — which team, which pillar gap, which pressure it relieves.

When exits and growth compete for the same limited slots, order them: direct backfills for departed people first (the team is already below capacity there), then strategic adds for the most bottlenecked area. Decide the role mix — for instance core-platform depth versus embedded generalists — before opening anything, so sourcing targets the right profile instead of whoever appears.

After the debrief sets a level, the recruiter moves to offer at that level's band. For a strong candidate, be willing to go to the top of the band for a real shot to close, and plan around practicalities like long notice periods rather than being surprised by them. Confirm title and level explicitly at offer time; if your org has title sprawl — platform engineer, cloud engineer, DevOps engineer, SRE all meaning roughly the same thing — normalize to one title at the offer so the new hire's level is unambiguous from day one.

Some roles carry hard constraints that belong in the ICP from the start, not discovered at offer: customer contracts that require data to be handled only by personnel in certain countries, on-site cadence expectations, or time-zone overlap needs. Surface these as gates in the recruiter screen. It is far cheaper to filter for an eligibility constraint on the first call than to run a full loop and discover it at the finish line.