Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The Death of Process

bellmar.medium.com

Post reply on HN
Print view View original

11–20 of 49 posts

Re: The Death of Process

#11

Post by doctor_eval »

kqr wrote: post #10
ChrisMarshallNY wrote: post #9

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, 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 severa…

Came here to say something similar. Sometimes the best policy is to avoid creating policies.

Re: The Death of Process

#12

Post by krisoft »

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?

Re: The Death of Process

#13

Post by smitty1e »

> 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_...

Re: The Death of Process

#14

Post by forgotusername6 »

"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.

Re: The Death of Process

#15

Post by kqr »

tempodox wrote: post #7
cntainer wrote: post #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.

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.

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.

Re: The Death of Process

#16

Post by kqr »

thaumasiotes wrote: post #8
cntainer wrote: post #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.

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.

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.

Re: The Death of Process

#17

Post by nosianu »

krisoft wrote: post #12

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?

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.

Re: The Death of Process

#18

Post by rapnie »

krisoft wrote: post #12

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?

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

Re: The Death of Process

#19

Post by cgio »

kqr wrote: post #10
ChrisMarshallNY wrote: post #9

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, 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 severa…

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.

Re: The Death of Process

#20

Post by cgio »

cntainer wrote: post #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.

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.
Post reply on HN