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

21–30 of 49 posts

Re: The Death of Process

#21

Post by jensensbutton »

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.

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.

Re: The Death of Process

#22

Post by ChrisMarshallNY »

cgio wrote: post #19
kqr wrote: post #10

Earlier quoted context omitted.

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 d…

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.

Re: The Death of Process

#23

Post by cntainer »

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

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.

Re: The Death of Process

#24

Post by cntainer »

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.

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.

Re: The Death of Process

#25

Post by cntainer »

kqr wrote: post #15
tempodox wrote: post #7

Earlier quoted context omitted.

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.

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.

Re: The Death of Process

#26

Post by keyraycheck »

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…

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.

Re: The Death of Process

#27

Post by hammock »

>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?

Re: The Death of Process

#28

Post by dota_fanatic »

keyraycheck wrote: post #26
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…

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.

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

Re: The Death of Process

#30

Post by jerglingu »

forgotusername6 wrote: post #14

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

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