5 ms·

You can look at process as "a list of stuff we have to do" or you can look at it like "stuff we need to worry about" The first way, you are relieved of worryin

You can look at process as "a list of stuff we have to do" or you can look at it like "stuff we need to worry about" The first way, you are relieved of worrying -- you do the list, and the list thinks for you. The second way is much more difficult. The problem in big organizations is that different folks are worried about different things. That's why they keep making and giving out lists of stuff for people to do -- they don't want you screwing up. If you have a hundred teams and one of them takes down production for a day, I can guarantee you somebody is going to make a list of how-not-to-do-that-again, like it or not. We all know where this heads -- mindless trolls doing paperwork and following the list while nothing gets done. But it's important to realize how we get there too. There are no bad guys in this story. It's not just descriptive process that causes the problem, it's letting the "chickens run the farm" as one other commenter put it. There has to be some give and take. I wish you could throw out some kind of slogan and have an easy answer, but a lot of this is highly dependent on organizational culture, previous history, the people involved, etc. It depends. :)

aaronblohowiak 16y ago
risk aversion is a rational strategy when you have a lot to lose.
draebek 16y ago
>The problem in big organizations is that different folks are worried about different things. That's why they keep making and giving out lists of stuff for people to do -- they don't want you screwing up. If you have a hundred teams and one of them takes down production for a day, I can guarantee you somebody is going to make a list of how-not-to-do-that-again, like it or not. Why is it a problem to make procedures to avoid making the same mistake twice? In terms of "[taking] down production for a day" I'd prefer to make permanent changes to my systems so that I don't have to rely on procedure, but for those things that I can't or won't fix with more code or automation, making and following procedures to avoid e.g. unplanned service outages seems perfectly fine, even advisable? Of course this ignores the specifics of each individual situation, although I am having trouble imagining any product that I'd want me or my business to depend on that is also known to fail with any great frequency. (Even my home broadband Internet connection, for example, hasn't failed more than once or twice in the past year, and they have a veritable monopoly.)

aaronblohowiak 16y ago

risk aversion is a rational strategy when you have a lot to lose.

draebek 16y ago

>The problem in big organizations is that different folks are worried about different things. That's why they keep making and giving out lists of stuff for people to do -- they don't want you screwing up. If you have a hundred teams and one of them takes down production for a day, I can guarantee you somebody is going to make a list of how-not-to-do-that-again, like it or not. Why is it a problem to make procedures to avoid making the same mistake twice? In terms of "[taking] down production for a day" I'd prefer to make permanent changes to my systems so that I don't have to rely on procedure, but for those things that I can't or won't fix with more code or automation, making and following procedures to avoid e.g. unplanned service outages seems perfectly fine, even advisable? Of course this ignores the specifics of each individual situation, although I am having trouble imagining any product that I'd want me or my business to depend on that is also known to fail with any great frequency. (Even my home broadband Internet connection, for example, hasn't failed more than once or twice in the past year, and they have a veritable monopoly.)