I really appreciate when someone takes a few minutes to answer my question on a public (rather than 1-1 chat), so I endeavour to do the same for others. Treat others as you'd like to be treated.
Well, in this particular company, everything was public. Even the 1-1 discussions tended to be threads in the public slack channel. Or at least comments on the ticket.
The main point was if you want the other team to do something, you create a ticket so that they can schedule it in, rather than interrupting them demanding they drop whatever they might be doing to do your thing. And if your question is already addressed in the documentation, then its a waste of the teams time and energy to answer the same thing over and over.
If you have a legitimate question that isn't answered in the documentation, then you can absolutely ask and get an answer. The main goal is to reduce interruption with needlessly (everyone is busy!) and to reduce low quality low effort questions. Answers then often also made it back into the documentation.
So its not about treating the requester badly, but rather that its easy and low effort to ask someone to do or answer something, while it can be incredibly disruptive for the team being asked. This is a means of managing that, and in my opinion it worked great. It also pushed me to put enough effort into questions when I did have them (what am I trying to achieve, what have I tried, where have I looked for answers, what problems am I having).
This is why you should ask on a public chat; if I'm really too busy to read the Slack channel, I won't read the Slack channel. If, on the other hand, I need a breather or "I'm waiting for the compiler", I might be able to give you some pointers in the right direction or encouragement with what you've already discovered.
I'm not encouraging lazy questions per se; I want people to demonstrate effort (what have you tried?) and ask the right question (X-Y questions), but equally, I appreciate that documentation takes a long time to digest and maybe my opinion is what you want rather than discrete facts.
The main point was if you want the other team to do something, you create a ticket so that they can schedule it in, rather than interrupting them demanding they drop whatever they might be doing to do your thing. And if your question is already addressed in the documentation, then its a waste of the teams time and energy to answer the same thing over and over.
If you have a legitimate question that isn't answered in the documentation, then you can absolutely ask and get an answer. The main goal is to reduce interruption with needlessly (everyone is busy!) and to reduce low quality low effort questions. Answers then often also made it back into the documentation.
So its not about treating the requester badly, but rather that its easy and low effort to ask someone to do or answer something, while it can be incredibly disruptive for the team being asked. This is a means of managing that, and in my opinion it worked great. It also pushed me to put enough effort into questions when I did have them (what am I trying to achieve, what have I tried, where have I looked for answers, what problems am I having).