5 ms·

This type of bureaucracy is not only harmful to dev culture, it's also outrageously expensive. I've been on an engagement with a large healthcare provider and t

This type of bureaucracy is not only harmful to dev culture, it's also outrageously expensive. I've been on an engagement with a large healthcare provider and the dev culture there is very similar to Amazon, loads and loads of procedure and bureaucracy. Now i get a certain level of that at any company, but you often find yourself going: "does it really need to be this hard". Tasks that would take you an hour outside of this companies ecosystem would take you 3-4 inside the ecosystem. It's annoying to devs but should be alarming to management. You're literally spending 2x to 3x the required amount on your labor because of your inefficiencies. Personally I found it easy to convince management of changes like this when you pitch it like: "How would you like to reduce your labor costs by 2x". Now granted many people at these places are salaried which makes this a bit of a moot point but most software shops contract out alot of work, and that's where you're really paying for your inefficiencies.

foobarian 4y ago
Heh, watch out for empire-building middle managers. "Hey how would you like to reduce your headcount by 2x" will not go over well.
- dicriseg 4y ago
  It’s more like, “How would you like to get twice as much done?” I don’t work at Amazon, but I’m sure there’s plenty for folks to do.
- ryandvm 4y ago
  Yup. This is an especially dangerous suggestion when you work for a government contractor. Since a lot of them have their profit margin capped at a specific percentage, the only way for them to increase total profit is by increasing the size of the project. Suggesting efficiencies that would reduce headcount is a good way to get on executive leadership's threat radar. Man, I do not miss working for a fed contractor.
bumby 4y ago
While it's true that arbitrary bureaucratic inefficiencies can get out of control, sometimes "good" bureaucratic requirements can get inflated with the arbitrary ones, simply because people don't understand their reason in the first place. This leads to a Chesteron's fence scenario [1]. Anytime somebody say's something like "does it really need to be this hard" or "all you've got to do..." should make sure they fully understand the rationale behind the requirements. A lot of times, those requirements can be met in a more efficient manner, but sometimes the seemingly "efficient" path will cause more second-order problems down the road because of those blind spots. What you often find in both camps (those bluntly instituting the requirements and those saying they should go away) is a lack of understanding of the entire system dynamics. [1] https://fs.blog/chestertons-fence/ https://fs.blog/chestertons-fence/
- im3w1l 4y ago
  Chestertons fence is basically a prior: Things are the way they are for a good reason. It can be more or less applicable in different contexts, and I'm not sure I would give give bureaucratic procedures such a benefit of the doubt. On the contrary, I think that any departure from doing something in the simplest possible way has to be accompanied by strong evidence.
  - bumby 4y ago
    Here's my take. Any requirement or bureaucratic procedure is meant to mitigate some risk. You must understand what that risk is before removing that process step. Many times that process step is just arbitrarily layered onto an existing process. If you do that enough times we get the inefficiencies that we tend to think of when we say "bureaucracy." That creates a risk in itself, namely a productivity risk. But that stems from my earlier point: when process steps are just layered on without thinking about the second-order effects, it creates a bad process by incurring outsized risk. But the converse is also true: removing process steps without understanding the rationale behind them can also increase risks. You seem to equate bureaucratic steps with needlessness. I'm not sure I agree. I tend to think they are there for a reason, but possibly just implemented poorly. Same goes for decisions to remove steps from a process.
- 4y ago
0x445442 4y ago
> Now granted many people at these places are salaried… This shouldn’t make a difference because in theory they would be doing 2x more work which is essentially cutting their salary in half. I realize that the dev team being twice as efficient doesn’t necessarily double the unit’s revenue but it’s some multiple.

foobarian 4y ago

Heh, watch out for empire-building middle managers. "Hey how would you like to reduce your headcount by 2x" will not go over well.

dicriseg 4y ago
It’s more like, “How would you like to get twice as much done?” I don’t work at Amazon, but I’m sure there’s plenty for folks to do.
ryandvm 4y ago
Yup. This is an especially dangerous suggestion when you work for a government contractor. Since a lot of them have their profit margin capped at a specific percentage, the only way for them to increase total profit is by increasing the size of the project. Suggesting efficiencies that would reduce headcount is a good way to get on executive leadership's threat radar. Man, I do not miss working for a fed contractor.

bumby 4y ago

While it's true that arbitrary bureaucratic inefficiencies can get out of control, sometimes "good" bureaucratic requirements can get inflated with the arbitrary ones, simply because people don't understand their reason in the first place. This leads to a Chesteron's fence scenario [1]. Anytime somebody say's something like "does it really need to be this hard" or "all you've got to do..." should make sure they fully understand the rationale behind the requirements. A lot of times, those requirements can be met in a more efficient manner, but sometimes the seemingly "efficient" path will cause more second-order problems down the road because of those blind spots. What you often find in both camps (those bluntly instituting the requirements and those saying they should go away) is a lack of understanding of the entire system dynamics. [1] https://fs.blog/chestertons-fence/ https://fs.blog/chestertons-fence/

im3w1l 4y ago
Chestertons fence is basically a prior: Things are the way they are for a good reason. It can be more or less applicable in different contexts, and I'm not sure I would give give bureaucratic procedures such a benefit of the doubt. On the contrary, I think that any departure from doing something in the simplest possible way has to be accompanied by strong evidence.
- bumby 4y ago
  Here's my take. Any requirement or bureaucratic procedure is meant to mitigate some risk. You must understand what that risk is before removing that process step. Many times that process step is just arbitrarily layered onto an existing process. If you do that enough times we get the inefficiencies that we tend to think of when we say "bureaucracy." That creates a risk in itself, namely a productivity risk. But that stems from my earlier point: when process steps are just layered on without thinking about the second-order effects, it creates a bad process by incurring outsized risk. But the converse is also true: removing process steps without understanding the rationale behind them can also increase risks. You seem to equate bureaucratic steps with needlessness. I'm not sure I agree. I tend to think they are there for a reason, but possibly just implemented poorly. Same goes for decisions to remove steps from a process.
4y ago

0x445442 4y ago

> Now granted many people at these places are salaried… This shouldn’t make a difference because in theory they would be doing 2x more work which is essentially cutting their salary in half. I realize that the dev team being twice as efficient doesn’t necessarily double the unit’s revenue but it’s some multiple.