[HN Gopher] The Death of Process
___________________________________________________________________
The Death of Process
Author : mbellotti
Score : 150 points
Date : 2022-02-19 04:05 UTC (1 days ago)
(HTM) web link (bellmar.medium.com)
(TXT) w3m dump (bellmar.medium.com)
| bumby wrote:
| > _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._
|
| 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/
| bluGill wrote:
| Most startups fail. The lucky ones add process to avoid
| failure.
|
| The above may not be right, but it fits the data just as well
| bumby wrote:
| But does that explain the transition from "innovation" to
| "bureaucracy"? If that claim was the case, I don't see why
| there couldn't be organizations that are both innovative and
| process-driven.
| caminante wrote:
| _> "But there are five specific traits that scalable ideas must
| possess."_
|
| 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.
| hammock wrote:
| >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.
|
| What are the failure signals for a vaccination policy?
| cntainer wrote:
| > _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.
| thaumasiotes wrote:
| 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.
| cntainer wrote:
| Actually I think the advice is spot on if you want to
| continuously evolve your processes.
|
| 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.
| romeoblade wrote:
| Our company has a process in place that any process or
| policy gets reviewed either six months or one year,
| depending on the subject matter. A tech council reviews
| each, updates, appends, or archives it.
|
| 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.
| kragen wrote:
| One would hope that _all_ of your policies are archived;
| otherwise, how will anyone determine in the future
| whether a past action was in accordance with the policy
| when that becomes a question in a lawsuit?
|
| 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".
| jensensbutton wrote:
| That doesn't make the advice problematic. The section is
| called "reasons to _revisit_" not reasons to kill. If you
| revisit and find that the policy is still beneficial then
| keep it.
| kqr wrote:
| This is one of the reasons I would like to learn more
| anthropology. It's a really powerful skill to observe how
| humans interact and then speculate creatively about what
| forgotten (or never fully understood) purposes the
| interactions fulfill.
| unfocussed_mike wrote:
| I have a bit of a tendency to lay out even the simplest
| technical suggestion in the following pattern:
|
| - 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.
| nonrandomstring wrote:
| 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.
| tempodox wrote:
| 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.
| unfocussed_mike wrote:
| Or just thinking about what the burdens of success are.
| Especially when you know early success is not actually going
| to bring in the funds to pay for them.
| kqr wrote:
| Right. Or when you're introducing code to work around a known
| problem. Add a comment stating that it is a workaround, what
| problem it works around, when the problem is expected to be
| fixed, and, critically, how the reader can verify whether the
| problem exists anymore or not.
|
| Make it easy to find out when it can be removed, in other
| words.
| unfocussed_mike wrote:
| As well as FIXME:, maybe REMOVEME:
| cntainer wrote:
| I've been doing something similar when coding.
|
| 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.
| jdsleppy wrote:
| I've even written a unit test that fails after a certain
| date with a descriptive message for this purpose. It's
| maybe more familiar to developers and already has tooling
| around it.
| cgio wrote:
| Good advice but the reality I usually experience is one where
| processes and policies go to die in a folder on a "portal" that
| no one even has access to anymore. Good processes become
| embedded in tools and follow the lifecycle of their host.
| cntainer wrote:
| The processes that just go and die somewhere were probably
| not good processes from the beginning, else they wouldn't be
| abandoned
|
| 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.
| krisoft wrote:
| 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?
| nosianu wrote:
| That is what I get when I disable Javascript. With JS enabled,
| I got a flash of just the first paragraph and after a second
| the rest is loaded and displayed. Not exactly ideal, that's
| true.
|
| 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.
| rapnie wrote:
| Happened to me too at first, then the rest loaded. Try browser
| text-only mode, or replace Medium domain to load via Scribe.rip
| i.e.: https://scribe.rip/the-death-of-process-cdb0151a41fe
| smitty1e wrote:
| > Think about this way: why do startups start young, idealistic
| and innovative only to eventually grow more and more corporate
| and litigious in nature?
|
| 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_...
| smitty1e wrote:
| "Why are SpecOps teams small?"
| forgotusername6 wrote:
| _" 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"_ 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.
| jerglingu wrote:
| Mine too. Maybe this is different for the especially early
| stages (sub-20 people) where people congregate around that
| shared mission. But for mid-to-late-stage startups, I find more
| bureaucracy propagators and responsibility shunners than
| BigCorps
| CSMastermind wrote:
| 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.
|
| 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.
| jpswade wrote:
| Good process is there to protect people, if it's not doing that
| kill it.
| nikodunk wrote:
| What 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"._
| atoav wrote:
| 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.
| ChrisMarshallNY wrote:
| This 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_
| kqr wrote:
| 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.
| doctor_eval wrote:
| Came here to say something similar. Sometimes the best policy
| is to avoid creating policies.
| cgio wrote:
| Smart people also don't want to be spending their time
| assessing the risks of unknown situations. E.g. something I
| came upon recently when someone asked if they could work
| remotely from abroad for a while. Sure, from a technical
| contribution perspective it made sense to approve straight
| away. But if there was no policy and process I would never
| think to inquire about the tax implications with the relevant
| team. You don't only count pounds and ounces but also who has
| to lift them. I don't like smart engineers having to learn
| tax legislation, and at least some processes act more like
| interfaces between teams rather than stupid controls within a
| team. When it's about the latter I am all with you as long as
| you add responsible team members next to the smart condition.
| ChrisMarshallNY wrote:
| That's pretty much what I mean by "an heuristic approach":
| "Always consider fiduciary obligations. Here's where to
| find..." etc. In the WTF, there are likely to be specific
| directions and policies, but having a "navigator" for these
| policies ("A) Which nation is the employee in? B) Which
| office will be directing their work?, etc.) is a good idea.
| keyraycheck wrote:
| I love it. It reminds me of a story. My friend who joined the
| Big Search Company as tech lead was asked to report progress in
| four places. He thought it was ridiculous. So instead, he
| didn't report at all. He got two questions why is he not
| reporting? So for year's he was reporting in just two places
| instead of four. Two others were unused/unnecessary. However,
| still done by all other tech leads.
| dota_fanatic wrote:
| _> Two others were unused /unnecessary._
|
| 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.)
| chrisweekly wrote:
| Push vs pull solves it neatly; the idea of requiring
| subordinates manually / proactively to push status updates
| to various management nodes seems kind of absurd.
| tomnipotent wrote:
| It's push and pull. Someone not giving regular updates is
| just as bad as a nagging manager.
| chrisweekly wrote:
| Well sure; basic communication skills are prerequisite
| (and assumed). I was talking about GP's ref to formal
| processes that required frequently pushing updates to 4
| different upstream management nodes, which I maintain is
| doing it wrong.
| Cupertino95014 wrote:
| 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).
|
| 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."
| lifeisstillgood wrote:
| I 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
___________________________________________________________________
(page generated 2022-02-20 23:02 UTC)