4 ms·

You are making an explicit dichotomy / choice very clearly and eloquently and I agree with most of what you said. Where not everybody may agree is which side

You are making an explicit dichotomy / choice very clearly and eloquently and I agree with most of what you said. Where not everybody may agree is which side they prefer. This is an opinion, not a fact : "If you need 2 devs to code, one to qa/test. That's it. You don't get anyone else. Not for redundancy, not for anything else. You don't involve legal or marketing, change management,etc... because that means rules and procedures and politics and meetings and planning." I.e. For some companies / stakeholders / shareholders / client, risk aversion and predictability absolutely positively is preferred at cost of some agility. It's a willing overhead not necessarily perceived as waste. people driving without insurance may laugh at the suckers who are paying for something they'll probably never use, but risk appetite differs. We don't have to all agree, it's a wonderful diverse world out there, but I will always respect an argument better if it is self-aware of its assumptions and biases.

_8j50 4y ago
You are right about what I said being an opinion. My point was to shift the burden of bureaucracy to management instead of allowing them to use bureaucracy as a tool. If you think you need a person for liability/insurance reasons, well as a low or mid-level manager, you don't get that authority anymore in my proposal. You have to jump through pro-agility bureaucracy and ultimately justify every small decision like this to upper management and shareholders. So, if like you said the loss of agility is intentional, you make sure every single decision like that goes through almost unbearable scrutiny because it does add up. Your perspective as low/mid tier manager almost never looks at the overall loss of agility or risk appettite of the company. But C-suite gets paid to have that perspective. Naturally, incentives have it so that this is inverted. Low and Mid tier management have too much discretion with their limited perspective where they implement bureaucracy that burdens their workers instead of themsleves. Often, the risk aversion is for individuals and teams and when that becomes a culture then every team and manager implements needless inefficiency that brings the whole system to a halt when you scale up. That's why upper management at big companies, including google, just buys and integrates new companies to the most part. That's easier for them than working through the inefficiency of their own org.
lanstin 4y ago
The real trick isn’t the staffing, it is the boundary of the systems you need to change. To improve a process in a large system, you almost have to assume none of the other systems you touch have to change anything. Compensate for the large org and large number of critical systems with technical excellence and trickery. Your image upgrade project can’t get any QA resources to sign off on any code changes in the legacy C++ stack? Fix the bug with LD_PRELOAD overrides in your image upgrade program. Take the time to reason very thoroughly about the bug, but go for it. Obviously, use whatever automated validation you have and have a cautious roll out, but whatever you do, don’t be suckered into waiting for a team you don’t absolutely control to do something.

_8j50 4y ago

You are right about what I said being an opinion. My point was to shift the burden of bureaucracy to management instead of allowing them to use bureaucracy as a tool. If you think you need a person for liability/insurance reasons, well as a low or mid-level manager, you don't get that authority anymore in my proposal. You have to jump through pro-agility bureaucracy and ultimately justify every small decision like this to upper management and shareholders. So, if like you said the loss of agility is intentional, you make sure every single decision like that goes through almost unbearable scrutiny because it does add up. Your perspective as low/mid tier manager almost never looks at the overall loss of agility or risk appettite of the company. But C-suite gets paid to have that perspective. Naturally, incentives have it so that this is inverted. Low and Mid tier management have too much discretion with their limited perspective where they implement bureaucracy that burdens their workers instead of themsleves. Often, the risk aversion is for individuals and teams and when that becomes a culture then every team and manager implements needless inefficiency that brings the whole system to a halt when you scale up. That's why upper management at big companies, including google, just buys and integrates new companies to the most part. That's easier for them than working through the inefficiency of their own org.

lanstin 4y ago

The real trick isn’t the staffing, it is the boundary of the systems you need to change. To improve a process in a large system, you almost have to assume none of the other systems you touch have to change anything. Compensate for the large org and large number of critical systems with technical excellence and trickery. Your image upgrade project can’t get any QA resources to sign off on any code changes in the legacy C++ stack? Fix the bug with LD_PRELOAD overrides in your image upgrade program. Take the time to reason very thoroughly about the bug, but go for it. Obviously, use whatever automated validation you have and have a cautious roll out, but whatever you do, don’t be suckered into waiting for a team you don’t absolutely control to do something.