Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

I’ve seen this a lot, too, but only in specific company cultures. The common problem among all of them was that people in middle upper management thrived in chaos. They didn’t want the important things to be well documented or stable because that took away their opportunities to be the important person who held the secret knowledge to make things work. When something broke they wanted it to remain impenetrable for other teams so they could come in as the heroes.

Oddly enough, these same people would be the ones pushing for documentation and trying to stonewall other teams’ work for not being documented enough. It was like they knew the game they were playing but wanted to project an image of being the people against the issue, not the ones causing the problem. Also, forcing other teams to document their work makes it easy for you to heroically come in and save the day.





I mean, asking for other people to document their work takes zero effort.

In the couple of instances I experienced this, the problem is that the system is like the proverbial elephant that a bunch of blind people are familiar with through touching the parts they are next to; but the complexity is in the relationships in-between.

There needs to be a person who will take charge and learn/document the whole system, except people who work on it are overloaded and too exhausted to take this on. And management doesn't necessarily have the insight or incentive to make this happen. It's an interesting phenomenon.


Asking doesn't always mean it will happen. It also depends on how many times you ask, and which method you're asking.

I've had countless conversations about this with examples. Still, tickets remain some variation of "called, did some troubleshooting, fixed it".




Consider applying for YC's Winter 2026 batch! Applications are open till Nov 10

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: