Comment by mbubb
10 years ago
Great read and interesting discussion. Reminder of how good HN has been over the years.
The idea of "institutional learned helplessness" is a useful one. There is a French term which I will mangle instead of google: 'Deformation professionelle' - built in blind spots which come from having T shaped expertise...
I've been part of a hiring team for a sysops person and found this of interest:
http://www.heavybit.com/library/video/2015-02-24-charity-maj...
Overall the talk is ok - the point which stuck with me was the idea that you should look for a sense of institutional helplessness and filter for it when you hire Ops folks.
The speaker also said to look for folks with 'strong opinions which are lightly held' - a double edged sword.
In a devops role there is an internal debate. Should I press point "x" ahead on principle? Or should i hold off and wait on the business/product requirements. Thinking slow and waiting on a full discussion of requirements before charging forth into battle can be seen as good process or passivity...
At work we wre having a discussion on where and how to involve QA processes in the build/deploy process. Devops took the stance - "this is a business decision - we will implement it as product sees fit" and we got push back for being too passive.
But this is a trivial example. I guess the bigger issues which inspire a "What can i do about it?" response. Recent readings on surveillance state and corporate interests (ie Bruce Schneier, etc) make me vacillate between deep, helpless feelings we are FUBAR to learning about constructive things like gpg, tor, etc
On "Should I press point 'x'", do a divide and conquer on it. Try to reduce the number of degrees of freedom from that decision point to a minimum.
IMO, you have to live with the ambiguity, but try to craft strategies that cover both with minimal ... perturbation. Waiting helplessly is not an option :) If all else fails, strawman the least cost solution first.
I also think there's value in having some measure of dissent from within the team. Done right, you'll synthesize solutions you would not otherwise have come up with. But you want this to be without rancor and without sinking large amounts of time.
On "... where and how to involve QA processes in the build/deploy process" - make a complete list of steps, then balance which gets included as the risk profile emerges. Good risk analysis includes a comprehensive and complete plan for what happens when a step fails.
Finally, you simply have to manage perception. Quantify, quantify, quantify. As if you don't have enough to do....