I think this is the single most important factor to my happiness at any given company. The question is how to deduce this before being hired (ideally even before interviewing!)?
For early stage startups, it is invariably "none at all": You build it you run it. But that's doing two jobs, so you better be good at running it, and ideally you use dead simple technologies (none of this "k8s cluster-per-environment for a team of 2" business).
For very large companies, this may be public information. Do we know for sure Netflix has "Option A" (good team)? We expect Google to have Option A, but maybe with red tape galore (see yesterday's video).
But how about mid size companies? I have worked places with "Option B" infra teams. It was miserable, and I didn't last. Putting aside the question of how anyone puts up with that for long, how do we figure out who these companies are? What are the warning signs? Is it a situation worth fixing (maybe for a staff engineer, probably not for a mid level; as product engineers/outsiders, not infra engineers)?
Even as a staff engineer it's not worth trying to fix. Run, run as fast as you can. It's one of my questions I always ask, even for front end based gigs. How does DevOps/Infra work at your place. Unless they have a gleam in their eye or they say that developers can so most of it or a DevOps resource is embedded on each team I run.
As a Staff Engineer it's a no win situation, if you recommend changes the current team hates you. If you don't and try to change things slowly or just tweak things to build trust, most managers are upset that you aren't "moving the needle". The only way I've made that work was to be in complete control and to go scorched earth. Loudly and often state the issues and to have solutions in the back pocket. Basically be unafraid to make the existing team hate you. To be clear I've only been here once and I TRIED to work with them. I didn't last long after righting the ship because I grew to hate the company and working there.
For early stage startups, it is invariably "none at all": You build it you run it. But that's doing two jobs, so you better be good at running it, and ideally you use dead simple technologies (none of this "k8s cluster-per-environment for a team of 2" business).
For very large companies, this may be public information. Do we know for sure Netflix has "Option A" (good team)? We expect Google to have Option A, but maybe with red tape galore (see yesterday's video).
But how about mid size companies? I have worked places with "Option B" infra teams. It was miserable, and I didn't last. Putting aside the question of how anyone puts up with that for long, how do we figure out who these companies are? What are the warning signs? Is it a situation worth fixing (maybe for a staff engineer, probably not for a mid level; as product engineers/outsiders, not infra engineers)?