In software architecture, one of the best advice you will be told is to name things properly. A golden rule towards maintainable systems.

The craftsmen out there will plead you to fight the urge to name your class a “manager” or “utility”. These names tend to mask objectives within black boxes. The code becomes less readable and the exact functionality will require unnecessary digging. Instead, use actions for functions with sanely consistent prefixes (such as get/set/read/write etc.) and nouns for classes to reflect objects and models.

Same goes for divisions within companies: whenever you have a “Support Group” you will find people stepping on each others toes, unclear accountability, and an escalating need for meetings to define roles and responsibilities.

A good name for a sub-organization should be a reflection of its KPIs. If a group is expected to train customers, that group would be called “Curriculum & Training Group”. If it was to acquire customers it should be called “Customer Engagement Group”, and so on.

Unclear accountability can be dreadful to companies. Always curate names around metrics and consider lack of ownership as a sign of unclear purpose.