Hacker News new | past | comments | ask | show | jobs | submit login

I totally agree on your final sentence there. There's a number of things in that chapter you mention, and there's also material on managing upwards earlier on in the book.

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.

We have an internal website with user-maintained groups/content. Every week, you get an email with major updates from the teams you want based on the important information they've been telling themselves. That's been useful for culling and focusing the information flow to each person.

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.

You really hit the nail on the head there. It's so hard to give the right people the right information at the right time.

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.

Thank you!

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.

Gifs? Don’t low quality animations make it hard to read?

When they're embedded in a Google Doc, they're pretty good at getting the point across - then they can have a link to the app itself too.

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact