6 ms·

I’d love something like this: I loathe the bullshit factory process has become.

ska 6y ago
Process is one of those things you have whether you think about it or not. It's up to you collectively to decide if it is BS or not, too heavy, too light, etc. I'm not suggesting everyone has the influence to change process much at the place they work, but they idea that there is a single "thing" called process and some places have it and some don't is just dangerously misleading. It is true that process tends to naturally scale with org size and longevity because communication becomes more complicated with this scaling - but that only gives you a bit of a lower bound (i.e. if you go below this, you start shooting yourselves in the feet)
- wussboy 6y ago
  https://en.wikipedia.org/wiki/The_Tyranny_of_Structurelessness https://en.wikipedia.org/wiki/The_Tyranny_of_Structurelessne...
- tartoran 6y ago
  It really depends how that process is adopted. If it's organically in-house grown and it does makes sense then it becomes a synergic glue. If it's imposed top down from the outside because "that company does it, lets follow suit" then it can become a pain and cause more harm than good. I liken that to goo.
  - tomnipotent 6y ago
    > "that company does it, lets follow suit" This is always a red flag I'm dealing with someone inexperienced, or desperate. Processes can be very unique to each company, especially the problems that they're facing, and trying to shoehorn someone else's process into your own business without understanding the problems that process is solving is a recipe for failure.
    - GoatOfAplomb 6y ago
      Cargo cults: not just for code!
  - nradov 6y ago
    There are two sides to that. Some processes grow organically in house in ways that ignore industry best practices. Everyone likes to think that their organization is special but few really are. They could often benefit from an improved process imposed top down by someone with broader experience and an ability to see the big picture. Of course changing processes always involves some short term pain.
- dkdk8283 6y ago
  > but they idea that there is a single "thing" called process and some places have it and some don't is just dangerously misleading. Is that what I said? No. I got into computers because I dislike people: leave me alone and let me work.
  - tartoran 6y ago
    I personally don't dislike people but prefer small teams where we almost get to read each other's mind. There's no magic formula for that, it's just compatibility and it usually forms organically. But I also like to get some 'let me think alone' time without which my performance starts slipping..
  - flyinglizard 6y ago
    Work on what, though? Work how? What gets prioritized? How are things released? How are issues handled? Without process, more employees just increase entropy. The process brings everything together. What’s described in the OP is a process. I run a very similar process myself - contractors, minimal friction, weak deadlines, no stand ups and all. Supremely effective.
    - castlecrasher2 6y ago
      Exactly. Good process is there to protect you, bad process slows you down. For example, in companies that deal with medical data/PHI/PII, having to go through processes is necessary because of liability, no way of getting around it.
  - bumby 6y ago
    Surely, you have a process that you follow in your own work though? There are formal codified processes and there are informal tribal ones. Often when I hear people have disdain for processes, it’s usually they don’t like someone else’s process. Unfortunately, standardized processes tend to become more necessary as systems get more complicated in order to ensure an operation becomes fault tolerant by not being reliant on a person that may leave but instead reliant on a process that stays. Processes mitigate risk. Just because that risk isn’t important to you doesn’t mean that risk isn’t important to someone. With that said, there are smart, efficient ways to mitigate risk and there are inefficient, burdensome ways
- lscotte 6y ago
  Indeed, I agree with all this. The trick is finding a balance, as a friend once told me the sweet spot is "as little process as possible, as much process as necessary".
- rokalakt 6y ago
  Spoken like a true worker. Please your boss now with a new policy to follow. Obey a few rules to show how you should be promoted and maybe approved time off this Friday.
- eldavido 6y ago
  This is a really thoughtful comment. "Process weight" is a good concept I wished more people understand. Building released-to-web software without hardware, big teams, long-term API support, etc. should really have almost no process, except for maybe high-level prioritization of features/functional areas (which a small-company CEO or PM can do). Reflecting on my own experience, it's the micro-management of most development processes that kills me -- 45 minute stand-ups where I'm arguing over whether something will take 2 or 4 hours. I honestly don't know and the powers that be just can't accept that. "How do you not know how long doing that will take!?!" I think most teams would be capable of this, it's just that the people signing the checks get really, really uncomfortable with the apparent lack of accountability.
  - beaconstudios 6y ago
    it's the tension between the bean-counter side of the company (finance, top level management, marketing vis-a-vis timelines) versus the creative side of the company (design & development, R&D). One side requires rigid predictability to perform optimally and the other side flexibility and ambiguity. Where the line is drawn and expectations are set is a function of company culture, hence why bigger companies/enterprises tend to come down heavy on requiring estimates. (I don't mean bean-counter pejoratively; the world needs order and predictability just as much as it needs creativity).
- tharne 6y ago
  This is 100% spot on. There's always a process to one's work. It's just a matter of whether you want to be intentional about it or not.
- theptip 6y ago
  Agreed. One additional source of disconnect in discussions is that the appropriate amount of process varies depending on what your goals are, your team composition (seniority, personality, communication styles, etc.), your regulatory environment, and myriad other factors. If you're early-stage Facebook or most consumer-facing recreational apps, "move fast and break stuff" with minimal process is great, since the potential downsides of pushing a bug to production are usually far outweighed by the value of iterating quickly. You can trust your developers to do the right thing, because for the most part developers will, and on the rare occasion that someone doesn't, the consequences are not severe. If you're Signal, or a FinTech company, or NASA, or a medical device company, then you need significantly more robust process to ensure that appropriate quality control, chain of custody, etc. is being applied at each stage of the process. Trust alone no longer works because even though it will get you the result you need _most_ of the time, that is not a high enough success rate. Put more generally, more/improved process is required when you cannot tolerate a given failure rate, and in general you trade off throughput against failure rate. Having said all of this, many companies cargo-cult Google and add process when they don't need to raise the quality bar, or implement poor process that fails to increase the quality bar; these would be examples of bullshit process as the GP puts it. However I feel like we're often not presented enough context to disambiguate appropriate process from BS.
- mbrodersen 6y ago
  Yep exactly. Process is like culture: you always have one. The question is whether it works well or not.

ska 6y ago

Process is one of those things you have whether you think about it or not. It's up to you collectively to decide if it is BS or not, too heavy, too light, etc. I'm not suggesting everyone has the influence to change process much at the place they work, but they idea that there is a single "thing" called process and some places have it and some don't is just dangerously misleading. It is true that process tends to naturally scale with org size and longevity because communication becomes more complicated with this scaling - but that only gives you a bit of a lower bound (i.e. if you go below this, you start shooting yourselves in the feet)

wussboy 6y ago
https://en.wikipedia.org/wiki/The_Tyranny_of_Structurelessness https://en.wikipedia.org/wiki/The_Tyranny_of_Structurelessne...
tartoran 6y ago
It really depends how that process is adopted. If it's organically in-house grown and it does makes sense then it becomes a synergic glue. If it's imposed top down from the outside because "that company does it, lets follow suit" then it can become a pain and cause more harm than good. I liken that to goo.
- tomnipotent 6y ago
  > "that company does it, lets follow suit" This is always a red flag I'm dealing with someone inexperienced, or desperate. Processes can be very unique to each company, especially the problems that they're facing, and trying to shoehorn someone else's process into your own business without understanding the problems that process is solving is a recipe for failure.
  - GoatOfAplomb 6y ago
    Cargo cults: not just for code!
- nradov 6y ago
  There are two sides to that. Some processes grow organically in house in ways that ignore industry best practices. Everyone likes to think that their organization is special but few really are. They could often benefit from an improved process imposed top down by someone with broader experience and an ability to see the big picture. Of course changing processes always involves some short term pain.
dkdk8283 6y ago
> but they idea that there is a single "thing" called process and some places have it and some don't is just dangerously misleading. Is that what I said? No. I got into computers because I dislike people: leave me alone and let me work.
- tartoran 6y ago
  I personally don't dislike people but prefer small teams where we almost get to read each other's mind. There's no magic formula for that, it's just compatibility and it usually forms organically. But I also like to get some 'let me think alone' time without which my performance starts slipping..
- flyinglizard 6y ago
  Work on what, though? Work how? What gets prioritized? How are things released? How are issues handled? Without process, more employees just increase entropy. The process brings everything together. What’s described in the OP is a process. I run a very similar process myself - contractors, minimal friction, weak deadlines, no stand ups and all. Supremely effective.
  - castlecrasher2 6y ago
    Exactly. Good process is there to protect you, bad process slows you down. For example, in companies that deal with medical data/PHI/PII, having to go through processes is necessary because of liability, no way of getting around it.
- bumby 6y ago
  Surely, you have a process that you follow in your own work though? There are formal codified processes and there are informal tribal ones. Often when I hear people have disdain for processes, it’s usually they don’t like someone else’s process. Unfortunately, standardized processes tend to become more necessary as systems get more complicated in order to ensure an operation becomes fault tolerant by not being reliant on a person that may leave but instead reliant on a process that stays. Processes mitigate risk. Just because that risk isn’t important to you doesn’t mean that risk isn’t important to someone. With that said, there are smart, efficient ways to mitigate risk and there are inefficient, burdensome ways
lscotte 6y ago
Indeed, I agree with all this. The trick is finding a balance, as a friend once told me the sweet spot is "as little process as possible, as much process as necessary".
rokalakt 6y ago
Spoken like a true worker. Please your boss now with a new policy to follow. Obey a few rules to show how you should be promoted and maybe approved time off this Friday.
eldavido 6y ago
This is a really thoughtful comment. "Process weight" is a good concept I wished more people understand. Building released-to-web software without hardware, big teams, long-term API support, etc. should really have almost no process, except for maybe high-level prioritization of features/functional areas (which a small-company CEO or PM can do). Reflecting on my own experience, it's the micro-management of most development processes that kills me -- 45 minute stand-ups where I'm arguing over whether something will take 2 or 4 hours. I honestly don't know and the powers that be just can't accept that. "How do you not know how long doing that will take!?!" I think most teams would be capable of this, it's just that the people signing the checks get really, really uncomfortable with the apparent lack of accountability.
- beaconstudios 6y ago
  it's the tension between the bean-counter side of the company (finance, top level management, marketing vis-a-vis timelines) versus the creative side of the company (design & development, R&D). One side requires rigid predictability to perform optimally and the other side flexibility and ambiguity. Where the line is drawn and expectations are set is a function of company culture, hence why bigger companies/enterprises tend to come down heavy on requiring estimates. (I don't mean bean-counter pejoratively; the world needs order and predictability just as much as it needs creativity).
tharne 6y ago
This is 100% spot on. There's always a process to one's work. It's just a matter of whether you want to be intentional about it or not.
theptip 6y ago
Agreed. One additional source of disconnect in discussions is that the appropriate amount of process varies depending on what your goals are, your team composition (seniority, personality, communication styles, etc.), your regulatory environment, and myriad other factors. If you're early-stage Facebook or most consumer-facing recreational apps, "move fast and break stuff" with minimal process is great, since the potential downsides of pushing a bug to production are usually far outweighed by the value of iterating quickly. You can trust your developers to do the right thing, because for the most part developers will, and on the rare occasion that someone doesn't, the consequences are not severe. If you're Signal, or a FinTech company, or NASA, or a medical device company, then you need significantly more robust process to ensure that appropriate quality control, chain of custody, etc. is being applied at each stage of the process. Trust alone no longer works because even though it will get you the result you need _most_ of the time, that is not a high enough success rate. Put more generally, more/improved process is required when you cannot tolerate a given failure rate, and in general you trade off throughput against failure rate. Having said all of this, many companies cargo-cult Google and add process when they don't need to raise the quality bar, or implement poor process that fails to increase the quality bar; these would be examples of bullshit process as the GP puts it. However I feel like we're often not presented enough context to disambiguate appropriate process from BS.
mbrodersen 6y ago
Yep exactly. Process is like culture: you always have one. The question is whether it works well or not.