I think your approach to this situation is fine. There are poor ways to handle it, though. A recent example: The developer maintains a tool that communicates

I think your approach to this situation is fine. There are poor ways to handle it, though. A recent example: The developer maintains a tool that communicates with another internal system maintained by another group. That system is being migrated from a suite of applications running on internal blades to something that runs on kubernetes. The migration affects how processes are accessed (IP addresses and ports), and changes are required on our end. This developer does not know anything about kubernetes and does not know anything about the changes in the other system. He does not understand why any access methods may have changed, and he is irritated that an external system is pushing a new requirement onto his task list when it worked perfectly fine before. To be fair, he does not need to know anything about kubernetes to make this change, but his resistance to the modification almost demanded an explanation of why it is necessary, and then it devolved into the situation I just described.