This reminds me of my last job. There were some instances where two teams would work on the same feature. The team leads and devs would regularly get together t

This reminds me of my last job. There were some instances where two teams would work on the same feature. The team leads and devs would regularly get together to make sure that we were on the same page in terms of who was developing what and what the specifics of the design were. It worked well. However, management would sometimes feel the need to bring in a developer from neither team who was supposed to facilitate development, I believe to cut down on meetings (because developer meetings that weren't standups, retros, or refinements were bad, apparently). What ended up happening is that this dev would have a meeting with Team A, get the details about the project, then go to Team B and talk about the implementation. Team B would have another idea for how the development should go, so the median dev would agree that the plans would change. That dev would not write down any of the details, let alone communicate back to Team A about Team B's changes. It caused a lot of unnecessary friction and wasted time. Management pretended like this wasn't something that could be avoided. So long story short (and also to your point): communicating once isn't enough, but not communicating at all is unacceptable