It always bothers me that people say that "communication" is the problem in engineering organisations.
We have near-constant access to each other via Email, Slack, JIRA and even GitHub PR comments.
Saying "communication" blindly is like telling a potentially Olympic runner to "run". That might be part of the overall strategy, but it's an oversimplification.
For example, if the problem is that a new feature broke another area of the system, then that's not a communication failure. Why?
- The idea was conceived and translated into a ticket (communication)
- That ticket was then iterated upon, and a specification was formed (communication)
- That ticket was then delegated to a developer (communication)
- That ticket was spoken about at stand-up (communication)
- That ticket was then submitted for code review (communication)
More communication is not the answer here.
So what is?
The answer, of course, varies on a case-by-case basis.
But, I have found people blaming communication as a scapegoat for the real problems in the team.
Some teams attempt to get around this with a "5-why's" system. But, in practice, the same groups that blame communication are also blind to the problems they are trying to solve. Many see a problem and jump to a solution they read that a FAANG company do.
First, list the problems and the impact on the team (from low to high). Then look at the high-impact issues and understand why they are problematic. For example, if the issue is that shipping features is slow, then its high impact is because a business needs to ship certain features by deadlines.
Next, being requirements led, look at your needs for the "ideal" system. Following the above example, the conditions might be that you can ship once per day, not require manual work to check new features and deploy new code in 15 minutes or less.
From there, you can design solutions to solve those problems.
This way, you solve your problems and are mindful of the issues. It's easy to read about solutions that FAANG's use. But the reality for many organisations is that those solutions would not fit and even do more harm.
Finally, you can measure the impact of these changes and iterate on the approach you have created.
Communication might be the problem. But I'd suggest looking at other failings in your engineering process, as it might surface some more positive changes you can make.