For complex backend projects we usually whiteboard/flowchart as a team first (high level), and use that diagram to pick which parts should be assigned to which

For complex backend projects we usually whiteboard/flowchart as a team first (high level), and use that diagram to pick which parts should be assigned to which person. At that point we start individually writing documentation for our respective pieces, (as if those services already existed). This might take the form of Readme files, wikis, or formal API documentation. Normally the process of writing documentation (and getting feedback on it) flushes out of a lot of issues. When everything is documented and everyone is on the same page about what everybody else is doing, then we write our tests and repeat the same feedback process. Once everyone's tests are on the same page, then we write our code, and do a code-review when that is done. Even with all those checks and balances, mistakes and confusions and miscommunications still happen. But having those regular check-ins to flush out issues before the real code gets written can save a lot of headache. If you get to the code review and find an issue, it's probably not going to be a huge one.