3 ms·

> I think this is the point where we're getting too serious about the discipline. In my opinion, we are not serious enough. The role of the cited sysadmin is d

> I think this is the point where we're getting too serious about the discipline. In my opinion, we are not serious enough. The role of the cited sysadmin is dying or dead in the modern company. As an SRE, you are expected to directly contribute to the product to improve SLOs as well as several other dimensions you quoted (like user happiness). I've personally performed code refactoring to reduce build job duration slowing down pipelines for _everybody_ in a component I was unfamiliar with. The code review was then performed by a code owner and the PR merged. > The contracts define what kind of guarantees you have to give and on what timeline. That's why you commit to ship product increments, not hard deadlines. See the failed launch of healthcare.gov, for example. > How is SRE supposed to quantify if the users are happy? The same way a dev would: review with stakeholders, "show-and-tell" where you collect feedback and improve your domain knowledge by focusing on the customer problem instead of your own vision of the solution. > Or tell the devs how to design their apps to fail less often? This is precisely why SREs would provide value by direct contribution. > you literally end up an executive director of product. We are all ambassadors of the product and can contribute past our designated "boundaries". That's what cross-functional is all about. No, you cannot make business decisions but if it is code, you have very high leverage. > If we really want to make products that users are happy with, we need to teach executives how to achieve it, not SREs. This has not happened yet and I suspect it never will. > SREs shouldn't be driving the bus from the back row [..] Let's teach executives how to set everyone up to succeed [..]. Agreed. Do you have a concrete proposal? Without fundamental organizational change, this is impossible. Conway's law still applies, so does its inverse. Meaning you can break down silos (including at executive level) by migrating from component to cross-functional feature teams.

throwaway892238 4y ago
My proposal would be to form an industry panel made up of experts in each of the discrete roles that make up a typical software product value chain. Ask that panel to produce the following: 1. Adapt industry best practices into a training program to teach executives what is necessary for a software product with happy customers. Very simple and to the point: here are the components of the value chain, here is their common problems, here is what each job needs to do to prevent them, here is how they have to work together. The purpose isn't to micro-manage each department, but to know how to identify when they aren't operating correctly and how to put people in place who know #2 below. 2. Take the above and break it down for each part of the value chain. Have the managers/directors of each part learn what their own department's best practice requires, its pitfalls, strategies. Teach them how inter-departmental overlap is required for happy customers, how departments should set each other up for success and collaborate, how "ownership" is tenuous and demands collaboration and compromise. They're all tributaries of a river. Charge money for people to go through that training and get a certificate. The money goes back into the whole thing. This becomes a baseline that shows you understand how to work on software products with best practice geared towards customer satisfaction.
- mihaigalos 4y ago
  I particularly liked this article [1]. Certification is IMHO people selling just about anything as a silver bullet/snake oil. There is no such magical solution, because one needs to adapt the Agile template to their organization's needs and that is where real skill is necessary. [1] https://www.simplethread.com/agile-at-20-the-failed-rebellion/ https://www.simplethread.com/agile-at-20-the-failed-rebellio...

throwaway892238 4y ago

My proposal would be to form an industry panel made up of experts in each of the discrete roles that make up a typical software product value chain. Ask that panel to produce the following: 1. Adapt industry best practices into a training program to teach executives what is necessary for a software product with happy customers. Very simple and to the point: here are the components of the value chain, here is their common problems, here is what each job needs to do to prevent them, here is how they have to work together. The purpose isn't to micro-manage each department, but to know how to identify when they aren't operating correctly and how to put people in place who know #2 below. 2. Take the above and break it down for each part of the value chain. Have the managers/directors of each part learn what their own department's best practice requires, its pitfalls, strategies. Teach them how inter-departmental overlap is required for happy customers, how departments should set each other up for success and collaborate, how "ownership" is tenuous and demands collaboration and compromise. They're all tributaries of a river. Charge money for people to go through that training and get a certificate. The money goes back into the whole thing. This becomes a baseline that shows you understand how to work on software products with best practice geared towards customer satisfaction.

mihaigalos 4y ago
I particularly liked this article [1]. Certification is IMHO people selling just about anything as a silver bullet/snake oil. There is no such magical solution, because one needs to adapt the Agile template to their organization's needs and that is where real skill is necessary. [1] https://www.simplethread.com/agile-at-20-the-failed-rebellion/ https://www.simplethread.com/agile-at-20-the-failed-rebellio...