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.
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.
What I found is almost the inverse of a Chesteron's Fence. Often times I see a complex process and start asking the reasoning behind such a process, everyone I talk to always has the same response: "you know I'm not sure why we do it this way, but it's important that we do it this way". At the end of the day you realize that no one really knows why they do a thing a certain way, and they are too afraid to change it.
I remember working for an insurance company in IT and we would always get a type of ticket that we were told to re-assign to another team. When I asked the obvious question of "why doesn't that team we send it to get it in the first place", I got all sorts of answers basically culminating in: "I don't know but it's the process and it's important". I eventually got someone to walk me through it and admit through their own answers that there was really no good reason to keep this process manual, as it must have been a holdover from when they had an older ticketing system. Even with all this it was impossible to change that process (at least while I was there) because the answer was always: "yeah your idea sounds good, I don't really see where we could break anything....but what if we do break something, let's just keep it as is".
I think you may have gotten the wrong impression about why I brought up Chesteron's Fence. It's not about blindly following a process; it's about understanding what risk the process is trying to mitigate.
“If you don’t see the use of it, I certainly won’t let you clear it away. Go away and think. Then, when you can come back and tell me that you do see the use of it, I may allow you to destroy it.”
This means somebody needs to first understand the reasoning behind it. If, as in your example, that rationale no longer holds, getting rid of that step is perfectly inline with the principle. I would argue that if somebody truly understood the process there would be no issue with changing it.
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.
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.
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.
> 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.
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.