The Death of Process
bellmar.medium.com
The Death of Process
1–10 of 49 posts
Re: The Death of Process
#2> Every policy or process doc I write now has a section called “Reasons to Revisit.” It is essentially a reverse success criteria. Rather than a short list of things I would expect to see if the policy was successful
Wow, what a great piece of advice. It seems so obvious and simple in retrospect and yet I never thought about something like this.
Re: The Death of Process
#3What an excellent piece! I loved the specific example of how to arm the future policy killer:
We can argue all day about what “adapt to modern architectures and frameworks for IT resource utilization” means, but it’s harder to argue about a statement like “it takes longer than two months to patch a system”.
Re: The Death of Process
#4I like the systemic thinking done here. This is much too rare in all kinds of policy decisions and certainly good advice for programmers, who should probably also think more about how in a distant future their software could potentially become a menacing legacy zombie that haunts precisely those people who care — and how to make it easy for them to deal with this.
Re: The Death of Process
#5I suspect software enabled policy will be more explicit - i hope
so for example, we count the number of errors logged in our central logging system, and we count the number of releases made per day, both of which are stored in the central metrics database. so we monitor our ecosystem, we store metrics in the ecosystem, and then we can write policy such as "if number of errors per day per release exceeds this ratio, introduce a bug day"
ok - bad example but the overall system seems a good idea
Re: The Death of Process
#6> Every policy or process doc I write now has a section called “Reasons to Revisit.” It is essentially a reverse success criteria. Rather than a short list of things I would expect to see if the policy was successful Wow, what a great piece of advice. It seems so obvious and simple in retrospect and yet I never thought about something like this.
Seems more in line with an Aristotelean ideal of policy. Today the word
has changed to mean a fixed set of codes, a machine by which to make
decisions.
Re: The Death of Process
#7> Every policy or process doc I write now has a section called “Reasons to Revisit.” It is essentially a reverse success criteria. Rather than a short list of things I would expect to see if the policy was successful Wow, what a great piece of advice. It seems so obvious and simple in retrospect and yet I never thought about something like this.
This seems to be very much in line with one of the things to do when writing software: Whatever you're building, think about what would disrupt/break it and deal with it somehow.
Re: The Death of Process
#8> Every policy or process doc I write now has a section called “Reasons to Revisit.” It is essentially a reverse success criteria. Rather than a short list of things I would expect to see if the policy was successful Wow, what a great piece of advice. It seems so obvious and simple in retrospect and yet I never thought about something like this.
The problem with this advice is that process development is evolutionary. The purpose for which the process was instituted can end up being unrelated to the reasons that the process is beneficial.
That's why traditions develop.
Re: The Death of Process
#9This woman always has such great things to say.
Like the previous discussion on safety regulations and societal boundaries, I feel as if tribal knowledge and heuristics are the best approach. This gives training, loyalty, good management, mentorship, experience, and personal judgment extra weight.
Not a popular stance, these days. Everyone wants to figure out how to have vast, transient, armies of disloyal, inexperienced –and, possibly, even incompetent– mercenaries, developing their product. No one wants to filter for the types of employees that can operate in an environment without guardrails and strict rules. They are expensive, and often require a very different management style, from the norm. I used to manage just such a team.
"Any proposal must be viewed as follows. Do not pay overly much attention to the benefits that might be delivered were the law in question to be properly enforced, rather one needs to consider the harm done by the improper enforcement of this particular piece of legislation, whatever it might be."
-Lyndon B. Johnson
Re: The Death of Process
#10This woman always has such great things to say. Like the previous discussion on safety regulations and societal boundaries, I feel as if tribal knowledge and heuristics are the best approach. This gives training, loyalty, good management, mentorship, experience, and personal judgment extra weight. Not a popular stance, these days. Everyone wants to figure out how to have vast, transient, armies of disloyal, inexperie…
Whenever someone suggests introducing process that could lead to just as much harm as good, I remind them that we should prefer to hire smart people, and trust that they are smart enough to recognise when they've made a mistake so they can, if not outright fix it, at least ask for help in fixing it.
Sometimes an ounce of prevention beats a pound of cure. Often an ounce of prevention turned into process becomes several pounds of prevention and the cure is easier.