4 ms·

I've worked in environments like that (in and out of software), and this is almost always driven in reaction to something, which is why it's hard to unteach. In

I've worked in environments like that (in and out of software), and this is almost always driven in reaction to something, which is why it's hard to unteach. In my current office there is a culture of consensus building and feedback. If someone feels they were not given sufficient opportunity to participate in a decision, they will complain, resist or otherwise cause an issue in the future. Sometimes they are correct, which is why it's not as easy as simply firing them. Sometimes the red tape is in response to problems in the past. Policies that were poorly enforced that resulted in negative consequences for customers (support failures or discriminatory behaviors). Sometimes it's there to protect low level staff from accusations of the above or to provide clear guidance when dealing with a high stakes/high stress situation. Sometimes it's to protect customers, such as regular security reviews. So no, I do not think this is about "low effort", though that can be a side-effect. No one sits in an office wanting to find ways to make their coworkers lives difficult. More often than not the policy is a response to pressure to do something to prevent whatever failure prompted the policy. The people who like the process heavy approach, in my experience, anyway, are often remembering a time when failure to follow a procedure resulted in negative consequences for someone.

PragmaticPulp 5y ago
> No one sits in an office wanting to find ways to make their coworkers lives difficult. That’s not exactly what’s happening. It’s not about making coworkers’ lives more difficult. It’s about preferring pseudo-work that looks like progress (meetings, process, consensus-building, planning sessions, endless documents) instead of work that delivers results. Once a project ships, everyone can see whether it was a success or failure. However, if you can keep it in the planning limbo for as long as possible you can avoid that moment of truth. Another round of meetings and refactoring and consensus building is safe because it’s easy to say you’ve followed the process and therefore produce good process-work. Shipping to customers is risky because then the product can actually fail. In companies where someone’s reputation and promotion prospects depend on avoiding project failures, it becomes attractive (and safer) to deal more in the pseudo-work than the actual work.
- orangeoxidation 5y ago
  > In companies where someone’s reputation and promotion prospects depend on avoiding project failures, it becomes attractive (and safer) to deal more in the pseudo-work than the actual work. Isn't this almost all companies? Remembering one's success and other's failure better seems to be human. "Jim really fucked the project up" vs. "Our project was a great success" (junior dev Jim getting no mention).
- stinkytaco 5y ago
  > it becomes attractive (and safer) to deal more in the pseudo-work than the actual work. More charitably, they feel this work will make the product better. That may or may not be true, but if you've been involved in failures and part of the after action review was "this person should have been consulted because they are the expert in whatever failed", that becomes part of the process. Pretty soon, this refactoring and consultation becomes expected, and so on until we're at the point you are speaking of. And I say this as someone who is part of the problem. I have unfinished projects right now that are stuck in meetings and consensus building. I want, at minimum, to be able to say, "you were given the opportunity to participate in the process, but you left it to me." but I've also made mistakes and poor decisions for lack of those steps more than once. I have no doubt that there are people avoiding failure by not shipping, but I do not think it is as simple as that, there are a variety of cultural norms and experience colliding here.
blaze33 5y ago
I agree that procedures to follow, meant as a way to benefit from past experiences are usually well intentioned. However, a common problem usually arises over time as the nature of the work evolves: is the procedure still relevant in the current context, still beneficial despite its overhead? Better have some system that can give an idea of the actual usefulness and current relevance of whatever procedures people have to follow. AFAIK, most people mainly focus on what they do and deliver, as it's what matters the most, but many fail to consider that how they do it might matter as much. Yet, knowing how every aspect of the environment impacts the efficiency of the work would be priceless. Being able to continuously improve and adapt the work environment so that the work keeps being done in the best possible way? One can dream ;) The technical debt concept somewhat applies to the organizational field: what may have worked well for the small startup is almost always re-worked once the company grows, and even when the company no longer grows in size, but still in age, frequent maintenance is required for the business to stay relevant in this changing world. Obviously, how to design how good work is done is no silver bullet, but as someone said: “I would rather have questions that can't be answered than answers that can't be questioned.” Like the not-to-be-further-questioned answer I once got: "Look, that's just how things are done around here." ;)

PragmaticPulp 5y ago

> No one sits in an office wanting to find ways to make their coworkers lives difficult. That’s not exactly what’s happening. It’s not about making coworkers’ lives more difficult. It’s about preferring pseudo-work that looks like progress (meetings, process, consensus-building, planning sessions, endless documents) instead of work that delivers results. Once a project ships, everyone can see whether it was a success or failure. However, if you can keep it in the planning limbo for as long as possible you can avoid that moment of truth. Another round of meetings and refactoring and consensus building is safe because it’s easy to say you’ve followed the process and therefore produce good process-work. Shipping to customers is risky because then the product can actually fail. In companies where someone’s reputation and promotion prospects depend on avoiding project failures, it becomes attractive (and safer) to deal more in the pseudo-work than the actual work.

orangeoxidation 5y ago
> In companies where someone’s reputation and promotion prospects depend on avoiding project failures, it becomes attractive (and safer) to deal more in the pseudo-work than the actual work. Isn't this almost all companies? Remembering one's success and other's failure better seems to be human. "Jim really fucked the project up" vs. "Our project was a great success" (junior dev Jim getting no mention).
stinkytaco 5y ago
> it becomes attractive (and safer) to deal more in the pseudo-work than the actual work. More charitably, they feel this work will make the product better. That may or may not be true, but if you've been involved in failures and part of the after action review was "this person should have been consulted because they are the expert in whatever failed", that becomes part of the process. Pretty soon, this refactoring and consultation becomes expected, and so on until we're at the point you are speaking of. And I say this as someone who is part of the problem. I have unfinished projects right now that are stuck in meetings and consensus building. I want, at minimum, to be able to say, "you were given the opportunity to participate in the process, but you left it to me." but I've also made mistakes and poor decisions for lack of those steps more than once. I have no doubt that there are people avoiding failure by not shipping, but I do not think it is as simple as that, there are a variety of cultural norms and experience colliding here.

blaze33 5y ago

I agree that procedures to follow, meant as a way to benefit from past experiences are usually well intentioned. However, a common problem usually arises over time as the nature of the work evolves: is the procedure still relevant in the current context, still beneficial despite its overhead? Better have some system that can give an idea of the actual usefulness and current relevance of whatever procedures people have to follow. AFAIK, most people mainly focus on what they do and deliver, as it's what matters the most, but many fail to consider that how they do it might matter as much. Yet, knowing how every aspect of the environment impacts the efficiency of the work would be priceless. Being able to continuously improve and adapt the work environment so that the work keeps being done in the best possible way? One can dream ;) The technical debt concept somewhat applies to the organizational field: what may have worked well for the small startup is almost always re-worked once the company grows, and even when the company no longer grows in size, but still in age, frequent maintenance is required for the business to stay relevant in this changing world. Obviously, how to design how good work is done is no silver bullet, but as someone said: “I would rather have questions that can't be answered than answers that can't be questioned.” Like the not-to-be-further-questioned answer I once got: "Look, that's just how things are done around here." ;)