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

41–49 of 49 posts

Re: The Death of Process

#41

Post by unfocussed_mike »

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.

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.

Re: The Death of Process

#42

Post by unfocussed_mike »

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.

As well as FIXME:, maybe REMOVEME:

Re: The Death of Process

#43

Post by chrisweekly »

tomnipotent wrote: post #33
chrisweekly wrote: post #31

Earlier quoted context omitted.

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.

It's push and pull. Someone not giving regular updates is just as bad as a nagging manager.

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.

Re: The Death of Process

#44

Post by bumby »

bluGill wrote: post #35
bumby wrote: post #34

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

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

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.

Re: The Death of Process

#45

Post by CSMastermind »

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.

Re: The Death of Process

#46

Post by kragen »

romeoblade wrote: post #39
cntainer wrote: post #24

Earlier quoted context omitted.

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.

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

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

Re: The Death of Process

#48

Post by bluGill »

bumby wrote: post #44
bluGill wrote: post #35

Earlier quoted context omitted.

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

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.

No, size explains it. You cannot be large without bureaucracy - bureaucracy means there are experts to do everything better than you can yourself. Sure small companies you can do things yourself, but you are often not the best person possible to do it - just that you are the only person.

Innovation happens at large companies as well. However not always in the same way.

Re: The Death of Process

#49

Post by bumby »

bluGill wrote: post #48
bumby wrote: post #44

Earlier quoted context omitted.

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.

No, size explains it. You cannot be large without bureaucracy - bureaucracy means there are experts to do everything better than you can yourself. Sure small companies you can do things yourself, but you are often not the best person possible to do it - just that you are the only person. Innovation happens at large companies as well. However not always in the same way.

I agree with the overall sentiment but perhaps disagree with the idea that bureaucracy is the result of specialization. I tend to think bureaucracy grows as a side effect of network effects. As the number of nodes in a corporate network grows, the interaction depth grows exponentially and processes help manage all those interactions. If there's a high level of specialization, but minimal interaction, there's still no need for a bureaucracy. In theory, you could have a large organization with so many silo'd departments that don't interact, there'd be no need for bureaucracy.
Post reply on HN