>> > ? ? You could talk with the TX team.
As with all the 20Qs, there is significant value in having something
more than an open ended question that teams can't fully comprehend.
Some sort of context (checklist, description, URL, Best Practice,...)
so that the teams can say "hey, that sounds like something our stuff
might or should do" rather than "No, we don't do {TX, branded zones,
zones}, ignore the question - uhm, what is {TX, branded zones,
zones}?".
Even better would be some sort of "answer" - a "how to architect and
design things so they play well with {TX, branded zones, zones}"
document that teams can use to reduce the need for /everyone/ to
interact with the {TX, branded zones, zones} team in order to get a
clue.
Without such a document to disseminate {TX, branded zones,
zones}-clue, you can't expect teams to do anything to play well with
{TX, branded zones, zones} - the default "ignore {TX, branded zones,
zones} because it isn't obvious that it applies to us" pressure is too
great. Even cryptic ARC 20Q references won't really change behaviors
- although they will increase the tension and conflict that surfaces
in ARC meetings as teams get blindsided with new-to-them undocumented
requirements.
-John
