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

31–40 of 49 posts

Re: The Death of Process

#31

Post by chrisweekly »

dota_fanatic wrote: post #28
keyraycheck wrote: post #26

Earlier quoted context omitted.

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

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.

Re: The Death of Process

#32

Post by caminante »

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

Re: The Death of Process

#33

Post by tomnipotent »

chrisweekly wrote: post #31
dota_fanatic wrote: post #28

Earlier quoted context omitted.

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

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.

Re: The Death of Process

#34

Post by bumby »

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

Re: The Death of Process

#35

Post by bluGill »

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

Re: The Death of Process

#36

Post by Cupertino95014 »

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

Re: The Death of Process

#37

Post by smitty1e »

smitty1e wrote: post #13

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

"Why are SpecOps teams small?"

Re: The Death of Process

#38

Post by jdsleppy »

cntainer wrote: post #25
kqr wrote: post #15

Earlier quoted context omitted.

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…

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.

Re: The Death of Process

#39

Post by romeoblade »

cntainer wrote: post #24
thaumasiotes wrote: post #8

Earlier quoted context omitted.

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.

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.

Re: The Death of Process

#40

Post by unfocussed_mike »

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.

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.

Post reply on HN