16 ms·

> 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

• threeseed 4y ago
  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.
• andrewem 4y ago
  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.
• layer8 4y ago
  You could read that ratio as a limit on infrastructure overhead that one should have. Unless you’re in the IaaS business, I guess.
• lopkeny12ko 4y ago
  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.
  • kortilla 4y ago
    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.
  • ZephyrBlu 4y ago
    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.
• chrisdirkis 4y ago
  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.
  • kodah 4y ago
    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.
• Aeolun 4y ago
  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.
• donutshop 4y ago
  According to the ratio we will need 12.25 infra engineers.