As an example of something I personally struggle with: what's the best way to have the rest of the company know what all of our teams are working on without A) going into too much detail B) being obtuse C) opening ourselves up for miscommunication to customers or deadline promises D) giving ourselves room to fail, because not everything will work out.
The current iteration is a fortnightly newsletter that I curate between product and the engineering managers in the department and it gets sent around, but making everyone happy with it is /so/ hard.
In my experience, newsletters don't work well for internal communication. As you said, keeping the content relevant to a wide readership is too difficult. It does, however, work well as a recognition mechanism. A team seeing it's achievements blasted out to the company is very motivating, even if they are the only one's who notice it.
I like the idea of the newsletter. Do you focus mostly on achievements, or discuss 'ways of working' as well?
I'm really looking forward to the book, by the way.
The target audience for the newsletter was decided as "the busy exec". Not too much text, lots of gifs of functionality that we've built, etc.
There's some separate newsletters we do as well - there's a fortnightly "what's going on in the backend" one, curated by our infrastructure teams that's aimed at engineers.
Currently the general case newsletter goes to Engineering, Product, Product Design, and the exec group. We don't think it's quite good enough for the staff@ mailing list yet, but maybe we're just being over-cautious. It's really hard to get the balance right.