Hiring Ratio

Fork this template on Google Docs

It’s impossible to avoid headcount planning when running a large team within an engineering organization. On the other hand, many folks find it’s impossible to be usefully involved in headcount planning when the folks running the process aren’t closely involved with your work: Infrastructure? Oh, that’s going great: no crashes or breaches lately, we don’t need to invest here!

Screenshot of hiring ratio template.

Hiring Ratios are a useful tool for folks leading support and enablement teams that often get little attention during the headcount process. Instead of relying on the folks running headcount planning, often the head of engineering, understanding your work and roadmap in detail, instead agree on a ratio of infrastructure engineer to product engineers.

Depending on the particularly individual responsible for engineering headcount planning, you may find that writing an Organizational Design is a better fit instead. Both are useful, which will resonate best depends on them!

Related Tools

How to Use

  1. Fork this template on Google Docs

  2. Start by filling in the Team section, in particular establishing the current ratio between your team and the internal organizations that they support. For example, Engineering is 100 folks and Infrastructure Engineering is 8 folks, so you have roughly a 1:12 ratio.

  3. Fill out the Rationale section by finding measures of your team’s recurring workload and normalizing that work against the size of engineering. Your goal is to find measures of how Infrastructure supports the wider organization and provide reasonable evidence that the effort to provide that support scales linearly with the size of the wider engineering team.

    Some options to consider are:

    • # of adhoc support tickets your team handles, per engineer, per month. You can also connect this to ticket latency, showing ticket latency increasing as there have been relatively fewer infrastructure engineers to the wider engineering organization
    • # of builds or deploys, per engineer, per month. You can connect this to both build/deploy success rate and build/deploy p50 or p95 time to successful completion
    • # of product incidents, per engineer, per month. You can connect this to number of engineering hours spent mitigating, remediating and cleaning up after incidents, which typically scales faster than number of incidents itself

  4. Continuing in the Rationale section, take some time to consider the big ticket projects your team has worked on or ought to be working on. If you’re having trouble finding more high-impact projects to work on (or if no one seems to want the nominally high-impact projects you are working on), then your current ratio might be a bit too high: propose tweaking the ratio up a bit. If you’ve been unable to take on any major projects over the past year, you’re probably understaffed: propose tweaking the ratio down a bit. If you’ve been able to effectively support the teams you’re working and also finish one to two major investments per year, then you’re probably at a reasonable ratio: propose maintaining your current ratio.

  5. Assume that folks reading this document have absolutely no clue where your other materials are that would help them understand your workload, and add links to your goals, dashboards, roadmaps, and work queues. (This may not be true, but links to context are at worst harmless and often very helpful for folks diving into a topic they don’t spend much time thinking about.)

  6. Update Peer Comparisons with the ratios used by simila teams within industry peers. These provide context for your proposed ratio, particularly for folks who are unfamiliar with the sort of work your team does

  7. Finish by writing a concise Summary section that quickly communicates the proposed ratio and the gist of the rationale

  8. Now you’re done!

Tips

  • Your goal is to reasonably represent your team’s headcount needs in a broader headcount planning process, not to represent it accurately. A single shared ratio is never going to be particularly precise
  • If you want to get a bit fancier, you can make the formula a bit more complex, pulling in features like # daily builds, # daily deploys, # peak users, # total users, but usually simplier works best. Very few headcount spreadsheets include those sorts of values, and they get hard for other folks to reason about their headcount once you introduce more features solely for yours. You can always, of course, have your own work sheet off to the side that explores these sorts of ratios