These are all good point, that I think aren't really related to having devs do operations.
Having engineers understand what makes a service resilient and easy to manage, as well as giving them incentives to produce high quality code doesn't require them to do SRE. In particular, being close enough to the SRE team, getting inputs when building the feature, detailed feedback and requests on live services, and the blame when shit hits the fan, are a more scalable way of doing it IMHO.
[−]lowbloodsugar · 2026-11-15 Sun 00:33 UTC ·
link
>Having engineers understand what makes a service resilient and easy to manage,
I don't believe engineers can understand this without experiencing it. A counter argument might be "football coaches don't need to have played", but the counter to that is "players need to have played". Why would being on call make you a better player? Personally, I think being the person watching the dashboards, in realtime, scraping the logs, in real time, watching how the contagion happens, in real time, gives insights that a next-day post mortem just doesn't. There are things I've learned only from hearing something on the conference call and then asking someone about it in chat. Watching a presentation on "Why 99% of people fell of our new bike" isn't nearly as useful as riding the fucking bike.
I've been on teams (briefly) where the ops team having an absolutely shit 48 hours was simply not on the dev teams radar, because they had more important things to worry about. That of course meant that when devs needed, e.g. a new host to try something, ops just dragged their feet, sometimes for months. Perhaps I've only seen dysfunctional companies in this regard. Or perhaps teams are made of humans, and splitting dev and ops is guaranteed to fail for any organization of more than 20 people? Like, sure, a startup of ten highly motivated people - maybe that works. Never done that myself: we've always run our own shit at the startups I've run/worked. Once that startup is 50 people, I think you're destined to fail with separate dev and ops.
Been paid for this over 40 years now. Done startups and FAANGs. But yes, the rewards better be fucking worth it, and the shifts better be reasonable.
So like, I'm not certain you're wrong. I don't think you can be wrong here. It's about what you're willing to do. Personally, I've done both ways, and if I started a company, I'd only hire people willing to support their shit with a pager. I'm not sure that matters for all businesses, but I'm not interested in starting, e.g. a mom-and-pop web hosting site for local businesses. If the service matters, devs are on call. So maybe I'm self selecting by the expected $ return.
Having engineers understand what makes a service resilient and easy to manage, as well as giving them incentives to produce high quality code doesn't require them to do SRE. In particular, being close enough to the SRE team, getting inputs when building the feature, detailed feedback and requests on live services, and the blame when shit hits the fan, are a more scalable way of doing it IMHO.
I don't believe engineers can understand this without experiencing it. A counter argument might be "football coaches don't need to have played", but the counter to that is "players need to have played". Why would being on call make you a better player? Personally, I think being the person watching the dashboards, in realtime, scraping the logs, in real time, watching how the contagion happens, in real time, gives insights that a next-day post mortem just doesn't. There are things I've learned only from hearing something on the conference call and then asking someone about it in chat. Watching a presentation on "Why 99% of people fell of our new bike" isn't nearly as useful as riding the fucking bike.
I've been on teams (briefly) where the ops team having an absolutely shit 48 hours was simply not on the dev teams radar, because they had more important things to worry about. That of course meant that when devs needed, e.g. a new host to try something, ops just dragged their feet, sometimes for months. Perhaps I've only seen dysfunctional companies in this regard. Or perhaps teams are made of humans, and splitting dev and ops is guaranteed to fail for any organization of more than 20 people? Like, sure, a startup of ten highly motivated people - maybe that works. Never done that myself: we've always run our own shit at the startups I've run/worked. Once that startup is 50 people, I think you're destined to fail with separate dev and ops.
Been paid for this over 40 years now. Done startups and FAANGs. But yes, the rewards better be fucking worth it, and the shifts better be reasonable.
So like, I'm not certain you're wrong. I don't think you can be wrong here. It's about what you're willing to do. Personally, I've done both ways, and if I started a company, I'd only hire people willing to support their shit with a pager. I'm not sure that matters for all businesses, but I'm not interested in starting, e.g. a mom-and-pop web hosting site for local businesses. If the service matters, devs are on call. So maybe I'm self selecting by the expected $ return.