🔢 Headcount Planning
Let's talk about Headcount Planning.
🤔 Why you should care about it
"Men and months are interchangeable commodities only when a task can be partitioned among many workers with no communication among them. This is true of reaping wheat or picking cotton; it is not even approximately true of systems programming." - Frederick P. Brooks Jr., in The Mythical Man-Month: Essays on Software Engineering.
Planning headcount is a yearly endeavour for engineering leaders who are supposed to ensure they have the correct number of people with the right skills to achieve business objectives. The outcome of headcount planning is usually the number of new engineers to hire and their estimated arrival date.
😫 Problem(s)
It's almost impossible to budget workforce based on roadmap delivery —> the roadmap itself being high level, it's impossible to accurately estimate the cost of delivering it.
The engineer-month* model is flawed —> the average engineer does not exist; some engineers can deliver 5X value while others need more onboarding.
Committing to a workforce number can be counterproductive —> with managers spending time hiring and onboarding engineers they didn't need just because it's in the business plan.
😃 Solution(s)
Instead of the "roadmap minus" model above (based on the engineer/month), CTOs and engineering leaders can use the:
- "Value minus" model —> the workforce estimate is the $ value the roadmap will generate as a percentage of the projected value. Having a $ budget instead of several people to hire gives engineering leaders the liberty of spending more on certain individuals or getting freelancers for specific projects.
- "Onboarding constraint" model —> the workforce estimate is limited by how many people engineering leaders can properly onboard without impacting many current projects. If they onboard more people, independently of the roadmap, the productivity of existing team members will be affected.
💡 Key Concepts
Estimation —> the time (usually in months) to develop and test software.
Engineer-month* —> the output that an average worker can produce after working for approximately 20 working days.
Annual Planning —> the process of defining a profits & loss roadmap for the company, where the "losses" are the necessary investments to deliver the expected "profits".
😡 Detractors
"Using the value minus model prevents HR to properly plan for headcount" —> it's true, especially since it takes two to six months to hire an engineer. To help HR better plan for headcount, engineering leaders can make plans with a six-month outlook.
"Sales and Product Management will always push to deliver the roadmap" —> when considering the onboarding constraint model, engineering leaders need to work with business leaders that consider software quality above the number of features or customer promises.
"Everyone uses the engineer-month model" —> the roadmap minus model is the most straightforward model and is adapted to organisations where engineering's mission is to deliver the roadmap. But it doesn't make it accurate and promotes a culture where engineering is a cost centre.
📚 Top book
The Mythical Man-Month: Essays on Software Engineering - Frederick P. Brooks Jr.
🗂 See also
📝 Top content
Headcount Planning - Will Larson
Headcount planning and building engineering teams for hyper-growth - Brian Zotter (via TeamOhanaHQ)
Annual Planning is Killing Your Growth – Try This Plan Instead - Dave Brussin (via First Round Review)
* Note: I decided to use "engineer-month" as a gender-neutral alternative to the man-month concept.