The Death of Process
bellmar.medium.com
bellmar.medium.com
Wow, what a great piece of advice. It seems so obvious and simple in retrospect and yet I never thought about something like this.
Make it easy to find out when it can be removed, in other words.
On one long-term project we even had special comments with an expiry date attached. Every time the build was running a script would scan all comments and print to output those comments that were expired to make sure someone revists them. And you could either remove, keep and extend expiry or modify that code, depending on context.
I guess it never crossed my mind I could do the same when creating company policies and processes.
That's why traditions develop.
Every time you revisit a process you can keep it, kill it or amend it. It sounds pretty evolutionary to me.
What I liked is that adding some fail indicators as part of the policy actually gives ammunition to the people that want to change the policy for the better against people that are abusing the current form of the policy.
If it's updated, it's sent out to all employees. Some require a digital signature (i.e., a process for handling customer data) to make sure it's read and understood.
Each review has a commenting period (4 weeks) for techs to ask questions or voice their opinion on the changes before it's approved.
It's helped keep the important documentation current, helped the processes evolve and allows the people that actually use the process to have input on the matter.
Perhaps by "archive" you mean something like "delete", in which case I would like to strongly encourage you to not use "archive" to mean that, because it's the opposite of the standard meaning of "archive".
I liked the advice because it actually applies to good processes that become embedded in the everyday work.
The point of the article being in how to prepare for the cases when a good policy becomes broken or is abused over time.
- summary of issue/opportunity
- things we know are true
- things we think are true
- things we should do
- what if we were wrong in the second part?
- what are the admin/technical negatives of success?
- when do we need to look at that
Nobody reads all the way to the bottom, but the process of writing it out makes sure that I think about it, and it also helps dig up potential Metcalfe's Law impacts on resources, combinational explosions etc.
I submit that people scale poorly.
Sure, Gall's Law[1], but note an empirical military truth: people in quantity do not accomplish tasks without a loss of individuality and a heavy authoritarian structure.
The U.S. military is also hugely expensive and wildly inefficient. Why are SpecOps teams all? Less is more.
Attempts to externalize and codify successes within corporate policies are worthwhile, but have a half-life associated with them as people turn over and contexts shift.
In summary, all human organizations tend toward the Tower of Babel. Lack of scalabilty is intrinsic. We can stop wondering.
[1] https://en.m.wikipedia.org/wiki/John_Gall_(author)#Gall.27s_...
She's right that the later bureaucrats just cite phrases from the policy as if they were Holy Writ. It becomes literally like a religion, where the ultimate appeal is always to some sacred ancient text, and then they argue about what the ancient text means now.
So I like the idea of adding to the soon-to-be-ancient text words to the effect that "here's how you'll know this is becoming obsolete."
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
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.
Not necessarily (in general)! It could be that those other two locations are part of the eyes for someone in management. This report not adding a status update could represent 10% of 25% of the stuff they're tracking on a regular basis. Do you notice if some small percentage of all the things you're tracking stops reporting? Or does it fall through the cracks? I'm betting the people tracking that work in the other two locations would notice if everyone stopped reporting.
Should they notice the reporting drop off? Yeah. But we're only human and must rely on process and the cooperation of other humans for everything to work efficiently.
(In no way am I saying someone should have to report in four places. They should fix their process so they're reporting in one place and anyone who need eyes on those people can check there.)
During my time in the corporate world, I'd say most policies and processes are the exact opposite. They're invented to try and formalize human behaviors and interactions, either because the people inventing them are deficient in social skills and anything that makes other humans more predictable is preferrable to them or because they just generally fear uncertainty and don't trust people to have good judgement in unique situations.
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”.
An alternative hypothesis is that, as organizations grow, their focus shifts from innovation to maintenance. It's a counterargument to the obscession with innovation.
"I think in paying more attention to maintenance and maintainers , it’s really signaling a shift in values away from glittery new things, consumer culture and those sorts of things, and toward work, towards labor, towards maybe even sacrifice in the form of taxes or effort to sustain society, and to pay a little bit more respect to the people whose jobs do that. They’re not superstars, they’re just grinding it out from day to day."[1]
[1] https://freakonomics.com/podcast/in-praise-of-maintenance/
The above may not be right, but it fits the data just as well
Innovation happens at large companies as well. However not always in the same way.
Did the article cover the five, and I missed it? Seems like popsci clickbait, if you have to buy the book to hear the basic premise.
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
Still, I prefer not to nitpick over design and code choices when the focus of a link is the content. It's not like our discussion here of the technology will do anything. It only distracts from the discussion of the content. If an author shows up it's different, then it may make sense to tell them. Otherwise, my position is to just let it slide.
If discussion forums such as this had multiple levels and replies about the content, "fun" replies, and discussions about unrelated aspects could be separated, then sure, but if it's all mixed I think it's better to leave it be and concentrate on that main point.
Especially since the article is interesting and makes good points, like this one.
What are the failure signals for a vaccination policy?