> <i>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</i><p>Wow, what a great piece of advice. It seems so obvious and simple in retrospect and yet I never thought about something like this.
> Think about this way: why do startups start young, idealistic and innovative only to eventually grow more and more corporate and litigious in nature?<p>I submit that people scale poorly.<p>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.<p>The U.S. military is also hugely expensive and wildly inefficient. Why are SpecOps teams all? Less is more.<p>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.<p>In summary, all human organizations tend toward the Tower of Babel. Lack of scalabilty is intrinsic. We can stop wondering.<p>[1] <a href="https://en.m.wikipedia.org/wiki/John_Gall_(author)#Gall.27s_law" rel="nofollow">https://en.m.wikipedia.org/wiki/John_Gall_(author)#Gall.27s_...</a>
Great article. It's rare that anyone considers the old age and death of a policy (actually, "death" would be a good outcome, but that happens too rarely).<p>She's right that the later bureaucrats just cite phrases from the policy as if they were Holy Writ. It becomes <i>literally</i> 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.<p>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."
This woman always has such great things to say.<p>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.<p>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.<p><i>"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."<p>-Lyndon B. Johnson</i>
<i>"It’s because early stage companies tend to hire people who prioritize the company’s well being and mature companies tend to hire people who prioritize their personal gain"</i>
This has not been my experience at all. The people I know involved in start ups are seeking adventure and personal wealth. The people who stay with the company are focused refining what they have to be the best thing it can be.
I 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.
My only criticism of that article is that it seems to assume that policies and processes have good intent to begin with or that they solved a real problem.<p>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.
What an excellent piece! I loved the specific example of how to arm the future policy killer:<p><i>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”.</i>
><i>why do startups start young, idealistic and innovative only to eventually grow more and more corporate and litigious in nature? It’s because early stage companies tend to hire people who prioritize the company’s well being and mature companies tend to hire people who prioritize their personal gain.</i><p>An alternative hypothesis is that, as organizations grow, their focus shifts from innovation to maintenance. It's a counterargument to the obscession with innovation.<p>"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]<p>[1] <a href="https://freakonomics.com/podcast/in-praise-of-maintenance/" rel="nofollow">https://freakonomics.com/podcast/in-praise-of-maintenance/</a>
<i>> “But there are five specific traits that scalable ideas must possess.”</i><p>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.
I suspect software enabled policy will be more explicit - i hope<p>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"<p>ok - bad example but the overall system seems a good idea
I know meta commentary is not welcome, but this page leaves my head scratching. Based on the other comments this sounds to be a worthy and insightful read but when I click on it all I see is a single paragraph (using an ipad safari, no extensions or adblocker) It ends at “There’s no trick to designing process…”, no button to read more, no call to subscribe, or pay a paywall. Are we seeing the same page?
>So when I write policy, I always include a few internal facing failure signals and a few external facing failure signals because I know that five, ten years from now someone is going to think this policy I’ve worked so hard on eff-ing sucks. And they’re probably going to be right! Many of the problems I was worried about probably don’t exist anymore. There are likely some new problems I could never have guessed would come up.<p>What are the failure signals for a vaccination policy?