

Let process be implemented by those who practice it - curtis
http://algeri-wong.com/yishan/engineering-management-process.html

======
wccrawford
There's a fine line here. Letting the chickens run the farm is not a good
idea, but neither is letting the bank.

In the company I work for, The CS Manager often dictates the workflow. If we
let the CSRs do it, they'd pick the way that was easiest for them, but would
ignore things that were less visible or useful to them. So their direct
manager does the deciding. Whenever she outlines how changes to the system
work, she always talks about how it'll improve their efficiency and how it'll
improve the efficiency of the company as a whole. When work comes from the
next rung up the corporate ladder, it's almost always about management's side
of things instead.

So you have to balance it all out, and have someone that can see all the
angles. And let them decide on the process.

------
curtis
_As a company scales, it becomes necessary to add or codify process. The key
tradeoff under consideration is always whether the drag imposed by the process
is worth the gains in efficiency or effectiveness._

I kind of like "process drag" as terminology for the overhead associated with
formalized processes. It sounds a little more pejorative than simply "process
overhead". It might make a good addition to the lexicon, right next to
"technical debt".

------
dotBen
_(OP link is worth a read btw despite how heavy it is presented, btw)_

This post articulates a bug-bear I've had throughout my career which is the
pedantic "RTFM" culture in software - where no one wants to help anyone and
instead gives them a pointer to a document (the 'Descriptive Process" as the
author describes it).

Proscriptive Process, actually sitting down with someone(s), not only is
valuable for the reasons the author suggests (re-examining process, updating,
refining, improving) but often new issues and idea and opportunities emerge
from going over something together or in a small group.

Sure, you can't do it _all the time_ but there are loads of examples when it
is valuable and should be considered part of the cost of development.

I think it's sad when you enter a workplace where everyone just wants to tell
you to RTFM all the time and no one has the time to sit down and go over
anything. Ultimately, I don't believe its how good product/software is made.

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

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

------
da5e
I think a way to avoid the negative calcification of descriptive process
documents, would be to have those who use the document as a guide to append
their own experiences using the document to that document for future
implementers.

------
gcb
Fighting chaos with well defined goals.

