Is it practical to compile a list of things that every developer on the team should know about the department?
Sure, it's practical to make the list... it's just impractical to maintain it, especially as teams, their processes and their work shift.
In my experience across a few companies, written documentation of this sort gets out of date pretty quickly. The good part of this is that if people really need to know something, then they'll find it out during the process of doing their work. Better yet, good teams will naturally streamline this process by going "ugh, I wish I knew that earlier! What process can I implement to help future people in my position?".
Your management (and/or project management) should facilitate this by removing obstacles:
- Sprint retrospectives (or similar periodic process improvement meetings) are great. You might not see results right away, but it gets people in a mindset of refinement.
- "How are we going to prevent this issue in the future?" rather than blaming people for mistakes. Blame makes people hide issues, questions like this make them think of ways to improve the company.
- Your leads should spread technical items of interest. Your PMs should spread project items of interest. Your management should spread business items of interest. Your developers should focus on developing. Nobody can know everything that is going on; make your team comfortable with that inevitability by saying "these other people (you trust) will help filter all this info to the relevant stuff". The key there is of course building trust...
- By identifying rumors and squashing them.
- Make it clear what you the individual are doing/responsible for (have useful 1 on 1's). If someone doesn't know what they do, its hard for them to tell others, and it's hard for them to know what they need to know within the larger group.
- Get good tools (chat, wiki, etc) so communication is easier.
- Continually culling/questioning processes that give the illusion of structure without the benefits of collaboration.