- On the trail of a bug that is likely to block a release? Say something, even if you haven't quite got it pinned down yet.
- Running a bunch of tests for a high profile client issue? Say something, even partway through.
- Got a boss who is constantly getting asked about state? Give him state near constantly.
In general this works pretty well. Your audience - typically developers and (for high profile issues) your boss and/or support and/or the release team - feels like they're not missing anything.
I'm starting to realize that may not be the best course of action, though. There are some serious downsides to always saying something:
- The signal to noise ratio can get out of whack. If your updates aren't substantive, then they'll start to get ignored, and woe on you when you have something really important to say.
- Going on vacation is a pain. Most people don't think to update others as often as you do, so disappointment with the coverage while you're gone is inevitable.
- It takes time. You can be working or providing status, but not both simultaneously.
My new working theory is to set a time when I'll say something, and then provide updates at that frequency unless something truly major comes up. So, for that hot client issue we'll update with test status once a day; two updates in a day means that something major (hopefully a huge fix) has happened.
How do ya'll balance communicating enough with saying little enough to give your communications weight?