How do you plan hiring 2 years ahead?

この issue には採用計画に関する長い議論が含まれていますが、ファイル、テスト、エントリーポイントは指定されていません。開始する前に、意図された成果物が記事、リンク、または別の形式のコンテンツのいずれであるかを明確にしてください。payload には完了条件が定義されていません。

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