How do you plan hiring 2 years ahead?

danfried [3:53 PM] 
anybody got any links for suggestions on how to write long term hiring plans?

danfried [3:53 PM]
or how to think about hiring beyond next quarter/hair on fire

skamille [3:53 PM] 
how long is long?

skamille [3:53 PM]
ah

skamille [3:53 PM]
1) Plan for attrition

skamille [3:54 PM]
2) Every new thing has to be supported. So if you want to build as many new things this year as you built last year, you probably need 20% more engineers to do it

skamille [3:55 PM]
20% might be overly generous but probably not

skamille [3:55 PM]
3) New hires slow down your existing staff while they onboard

skamille [3:55 PM]
4) Don't forget about management + ops + product/design + qa

skamille [3:55 PM]
figuring out your healthy ratios will help you think about scaling better

jamtur01 [3:56 PM] 
@danfried: I do a 1+1 model - this quarter plus roughly what I might need for next quarter on a rolling basis factoring in our % attribution rate. (edited)

jamtur01 [3:56 PM]
And like Camille - across Eng plus other folks (Ops, management, etc)

danfried [3:56 PM] 
this is harder than cloud capacity planning :<

jamtur01 [3:56 PM] 
lol

jamtur01 [3:56 PM]
yep

skamille [3:56 PM] 
yes quite

skamille [3:57 PM]
the 20% rule is pretty useful though tbh

danfried [3:57 PM] 
yeah that's actually a great way to phrase it

skamille [3:57 PM] 
if you need a rule of thumb

jamtur01 [3:57 PM] 
Be honest with leadership too though and admit that planning is +/- 25% of reality.

skamille [3:57 PM] 
that 20% isn't entirely product engineering but it is probably a good sense of growth

skamille [3:57 PM]
this is why those tech companies grow and grow and grow and grow forever it seems

danfried [3:57 PM] 
everyone always seems to talk about how larger engineering teams are less productive than small ones per person because lol startups

danfried [3:58 PM]
but I think it's a lot more logical to think of at least some of the drag as that maintenance cost

skamille [3:58 PM] 
if you can articulate the cost of maintenance it is useful because you can also use that to justify architectural/process/tooling uplift

skamille [3:58 PM]
but, I won't pretend to have done that well myself

danfried [3:59 PM] 
I'll start with shout "20% +/- 25%!" and waving my hands in the air

skamille [3:59 PM] 
yeah

danfried [3:59 PM] 
and take it from there

skamille [3:59 PM] 
good luck, let us know how it goes

danfried [3:59 PM] 
will do. So you don't try to predict staffing/budget 2 years out?

danfried [3:59 PM]
or even 1?

skamille [4:00 PM] 
we have done yearly staffing

skamille [4:00 PM]
but I won't pretend that it is ever accurate or held to

skamille [4:00 PM]
you plan in january and it changes in march

skamille [4:00 PM]
planning for attrition is really key though

jamtur01 [4:00 PM] 
It’s a fantasy in most teams

danfried [4:00 PM] 
right, that's what I've been doing, just revising it. I ask because I'm annoyed at how wrong I always am

skamille [4:00 PM] 
well, I'm also always wrong

danfried [4:01 PM] 
so I'm in good company. yay hard things

skamille [4:01 PM] 
I think people who are right are just modifying their work to the hiring plan and not vice-versa

danfried [4:01 PM] 
makes sense

jamtur01 [4:01 PM] 
The project plan is always right after the project ends etc etc

danfried [4:02 PM] 
yeah

The issue contains a long hiring-planning discussion but names no files, tests, or entry points. Before starting, clarify whether the intended outcome is an article, links, or another form of content; the payload does not define a completion criterion.