Ask HN: How does your company determine headcount? | Hacker News Reader

Ask HN: How does your company determine headcount?

4 pointsthrowaway909902 comments

How does your company determine headcount for engineering and product teams? Is it centrally controlled (say by the CTO), or distributed (say to engineering managers), or something in between? How is PM, designer, and UX researcher headcount determined? How are teams — and what they focus on — determined? What are the pros/cons of your approach?

My situation:

I work for a well-funded, high-growth company with roughly 200 employees, 20 engineers, 5 product managers, and 1 designer. Headcount decisions are all centrally planned by the CTO and CPO, with a degree of input from engineering managers and PMs about roadmaps and swags for “how long things will take.” The CTO and CPO take these inputs and map them onto “bi/annual objectives” — such as “grow monthly active users by X%.” If they feel the swags fall way short of the objectives’ appetite, they will increase headcount — after a song-and-dance with Finance.

Pros: - There is a rational framework for engineering managers and PMs to influence headcount

Cons: - Engineering managers and product managers do not have the power to acquire new talent into their teams to complement or supplement the skillset and competencies of the team to deliver better quality products; only velocity seems to count - Teams that are focused on business as usual tend to be penalized with understaffing or overwork because the objective-driven rubric has mostly prioritized new strategies and products - Finance is always the “bad cop;” there’s no budget that anyone is aware of (is this a real con?)

That sounds like a pretty standard and rational process. I've seen headcount handled other, less rational ways.

In any environment with constrained budget (most environments), Eng managers will not have carte blanche to hire. Each person represents a long-term expense for the business and every team always wants more people.

As you roll up the reporting chain, the first person with both budget responsibility and output responsibility is usually at the VP or C-level. That person is responsible for weighing the requests of Engineering / Product / Sales / Support against each other and aligning these bets with the broader strategic priorities and available resources.

Once the CEO allocates budget, why not just hand it off to the teams? When budget is only determined 1x/yr then team sizes and charters are locked for very long periods of time. A truly agile company holds its budget at a higher level and shifts whenever business needs change, maybe many times per year. Maybe everyone thought that Team A needed to hire 3 more people, but then a major customer arrived which required shifting one of those open positions to Team B. Or maybe the opportunity shrunk, and the company is best served by hiring nobody and shifting that budget to a short-term outside vendor as pay-for-services.

If the company is public, then it's more complicated. Are these operational costs or capitalized costs? You probably don't care, but Wall Street definitely does. Weighing these tradeoffs is the job of the VP / CTO / CEO. Underinvestment in support + operations is either a marker of a short-sighted leader, or it's a leader explicitly making a "bad" decision to focus investment elsewhere with a higher ROI.

>200 employees, 20 engineers, 5 product managers, and 1 designer.

If you don't mind me asking, what does this company make? How is it high-growth ?

I'm asking because the ratios of engineering and design with respect to total number of employees is really low.

Talking about monthly active users suggests SaaS, in which case what is going on ? Especially with the remark that engineering struggles to hire.

I don't have much information, but this looks bad to me, and possibly an indirect consequence of being well funded and not resisting the urge to hire too many people. Again, no soecific information, just a knee-jerk reaction to ratios and shared information.

Reply on news.ycombinator.com