I'm iffy on this for software (because you can always spin up a separate descriptively-named library to house the "scope creep"), but I'm 100% about this for team names at software companies, for the exact same reason: because you _can't_ easily "spin up" another team to handle the inevitable scope creep.

Let's face it, no software company where any of us work has ever been satisfied with "well, we have enough features already, no need to build more." The incentives _always_ push for-profit software towards "build a shiny new feature", because you can't upsell existing customers the same features they already pay for, but you _can_ upsell them _new_ features.

So companies monotonically grow their featureset.

Companies also do _not_ monotonically grow their employee base, and _certainly_ not at the same rate as they grow their featureset.

So, for example, the "email send team" of today will probably become "the email sending and rendering and link-tracking and some-of-the-reporting-but-not-all-of-it and some-of-the-public-API-but-not-all-of-it" team before long. And they'll probably also gain additional features along the way, some of which are likely to be even _less_ related to things like SMTP and MTAs (which they'll still regularly have to deal with).

In the meantime, those "some-but-not-all" categories will be shared with other teams, usually in a way that's not neatly describable in 1-2 words.

So do you keep constantly changing your "descriptive" team names and fleshing them out into entire often-mutating paragraphs so that they're _actually_ descriptive? Because you're _certainly_ not going to wait to build a feature until there's a new team for it. And what happens when you decide that some of those features should change hands to a different team? Time to go update all your CODEOWNERS files and ACLs and directories and everything so you can change the team's name again?

Or do you accept that memorable-and-unique-but-not-descriptive team names like "Apollo" or "Wombat" are a better use of your time, and find other ways (like relating per-feature PagerDuty "services" to team-level escalation policies) to map "feature X is currently owned by team Y"?

Because honestly? 70% of the time that you would want a "descriptive name" for a team, it's because you're trying to reach/page the right team to fix a problem.

Set up feature/service definitions in your tools of choice (PagerDuty, Jira), and make sure those are many-to-one with the team definitions, and then ensure that those definitions can be easily modified/reparented later.

To put it in programmer-friendly terms, don't use magic strings, factor out real identifier constants, and reference that constant instead of duplicating it.

P.S. to those of you who might say "you can just pick a generally-descriptive-enough name without it listing every feature", I once worked on a team named "<Product> Email Team," and we _frequently_ got questions/tickets/bug-reports about email-related or email-adjacent features that were actually owned by other teams (either on a different product, or as more of a "downstream" thing). We also sometimes _didn't_ get questions passed our way that were related to the non-email features we'd accumulated over time (see also: featureset growth speed vs. "headcount" growth speed). We were eventually renamed "<Product> Email And Content Services Team", ironically because our existing "descriptive" name was deemed "insufficiently descriptive". Rather than fixing the problem, the new name in fact only exacerbates the problem, since no two people can clearly agree on what "Content Services" are.