I was recently contacted by a colleague looking for a bit of advice.

C: "We are thinking about merging two teams together and we're not sure how to message the change."

D: "What do you think will be your biggest challenges?"

C: "Well, for one, we're not sure how the funnel flow team will respond to being folded into the purchase page team."

D: "The 'funnel flow' team and the 'purchase page' team?"

C: "Right."

D: "Explain to me what these teams do."

C: "Well 'purchase page' is responsible for the purchase page experience - how efficient is the actual purchase process. And 'funnel flow' team is responsible for everything from adding to cart up to the actual purchase."

D: "Wait. And you're folding the funnel flow into the purchase page? Shouldn't that be the other way around?"

C: "Well, purchase page is a more mature team. We've always had a purchase page, but only in the last year did we add a cart and other aspects to the overall funnel. It makes sense to add the few funnel team to the purchase team and expand their responsibilities."

D: "Right. What's the problem?"

C: "Well, we can't very well call the new team 'purchase page' since that'll be only a portion of their responsibility. And we can't call them 'funnel flow' because that implies we folded the larger more mature team into the smaller team. I suppose we could name them 'purchase flow' to represent the merger and give 'purchase' first billing."

D: "Yes. Or you could stop naming teams after projects and maybe let the team pick their own names."

C: "But then how would we know what project they're working on?"

D: "I don't know. Maybe the same way you know who is on what team."

D: "Wait... You don't rename your employees when they switch teams, do you?"

When you name teams after projects, you subordinate the team to the project.
— Michael (Doc) Norton (@DocOnDev) May 28, 2015