Other examples would be fear of altering any deeper parts of the system due to fear of punishment or war room style crisis.
Touching production is a lot like being an electrician working on a live circuit.
- an employee avoids sharing key technical information with colleagues, either verbally or writing anything down, and becomes a bottleneck for all changes relating to some system or component. this could be adapted to maximise tenure at a previous org that had decided to outsource/"offshore" technical roles, where sharing key knowledge would result in you being promptly laid off
- an employee demonstrates an extreme reluctance to estimate when any task they are involved with might be done. this could be adapted to survive in environments where estimates from individuals are interpreted politically as commitments to deadlines for unconditional delivery of work, and used to pressure workers to extract free labor (unpaid overtime)
- an employee never communicates bad news about schedule delays, plans not being feasible, designs having serious flaws, etc. this could be adapted to prior environments where voicing bad news triggers retribution, and only good news flows up the org chart
Ah, there are so many reasons for this. I won't give a deadline when I anticipate the requirements will change. Experienced workers can look at a planned implementation and tell management 'This isn't going to work, we're going to have to change this' and be handwaved away, because they know inevitably, after management has played out whatever fabricated 'negotiation' they've set up for themselves, inevitably the requirements will change and a new deadline will need to be established.
I started my career in a software agency, maybe I was unlucky, but in this particular agency I overheard the more senior employees staying after-hours and making fun of the the junior employees (in their absence) and the quality of the code they had wrote. There was no actual code review process but this memory had made me very defensive in regards to my code. I was always trying to push the perfect code in one shot, which led me to overthink solution, and if for whatever reason I had to push a rushed change I felt guilty and tried to find excuses preemptively.
At one time I had to onboard the client's new dev team to a project that I had built alone for about one year. The product had become successful so the client wanted to invest in rebuilding it on better foundations to prepare for accelerating its growth.
Working alone on the code for a year had subdued my fears of public shaming but, once I started going through it with a team of seniors looking over my shoulder, my anxiety went through the roof. For every new file I was opening I started my explanation with an apology about the quality of the code and tried to explain why I didn't have the time during implementation to write that code properly.
After the 2nd or 3rd explanation one of the new guys stopped me and said something like: "You don't have to explain yourself to us. This code is the result of the context it has been written in. We are only having this conversation because the product that you helped build by writing that code is successful. Because of this success we now have the chance to spend time and think about how we can improve the code".
I only realized later, but that was one of the most liberating things anyone has ever told me. It felt like a huge weight had just been lifted of my shoulders. People were looking at my code and discussing it not as a reflection of my quality as a person but as the output of different factors and priorities at a given point in time.
I worked with that team long enough to feel deconditioned from the previous toxic behavior.
Beautiful!