Hacker News Reader

Comment by _ktx2 | Hacker News Reader

> Maintain 4:1 product engineer to infrastructure engineer ratio. This has been our ratio for the past several years, and it’s worked fairly well, so we intend to maintain it.

Really weird, as someone who works as a Software Engineer in systems. The number of infra programmers you have is not a ratio to be kept with product developers. It's dependent on the versatility, modularity, reliability, and performance of the platform you have internally. More plainly put, if you want only VM orchestration with very minimal features, that's a different head count that support virtual machines, FAAS, and container orchestration.

View on HN

I'll note, for the purpose of discussion, that this is put forth as part of an example engineering strategy document. The author does not recommend _the reader_ do this, at least not here.

With that said, yeah, I think "a static ratio" vs "a flat count based on desired features" vs something else is an interesting discussion! My experience is that more product means more usage of the breadth of infrastructure, and requires both more infra development and more support, but I haven't worked in large orgs, so I don't know how this nets out as size grows.

I was commenting from the perspective of a large org, thinking of one big enough that would need a strategy. You don't differentiate product and infra spaces, because infra is part of the product. It's at least well known in SRE spaces that SREs don't scale linearly with product. You generally build teams around specific needs and productize things that enable that non-linearness.

The only reason I can see you tying product engineers to infra engineers in that way is if the infra engineers are supporting them with DevOps activities. For example building CI/CD pipelines, assisting with deployments etc.

Otherwise it really doesn't make much sense at all.

A fixed ratio makes sense in the context of how a particular company operates at a particular time. Given the example strategy you're quoting is about one company (real or hypothetical), and it doesn't say that the infrastructure teams are going to gain or lose a bunch of responsibilities from what they currently have, it seems pretty clear. When you add in "Particularly we will avoid hiring that grows our current headcount." the result is that they're aiming to keep about the same number of total engineers, and therefore about the same number of infrastructure engineers.

You could read that ratio as a limit on infrastructure overhead that one should have. Unless you’re in the IaaS business, I guess.

I found this guidance odd as well. This implies that, in an organization with 500 engineers, 100 (!) of them would be working on infra.

What would those 100 engineers even do? For the longest time, we had ~10 sysadmin and devops staff supporting 300 engineers. Nowadays, everything is run by AWS anyway--there's hardly any real infra to manage.

Whoever setup how you deploy to AWS, monitor, collect logs, etc is doing your infrastructure engineering. Many places don’t realize that the infrastructure engineering is just being left to random software engineers in a “whoever touched it last owns in” type setup.

You’re likely wasting resources or doing other dumb things (bad AWS role management) if you don’t have someone who owns that stuff.

Infra at large companies becomes platform engineering. Things like dev tools, internal tooling and deployments is the domain of infra. Using AWS is also not a get out of jail free card, you still need people who understand how to operate the services.

This makes perfect sense in my organisation, where everything is a bit more manual and custom than elsewhere.

If we didn’t increase the number of infra engineers with product engineers, we’d very soon be unable to deploy anything.

That’s less than desirable of course, but as long as it’s like that it may be good to have a fixed ratio.

According to the ratio we will need 12.25 infra engineers.

Reply on news.ycombinator.com