No news is bad news

I wrote yesterday about an issue I've had a few times, and I thought I'd expand on it a little more today. Often while I'm in the middle of a an uncertain situation, I also need to provide information about that situation. Sometimes that's because, like recently, I'm writing about what I'm doing. But it also comes up when I'm working with other people, and even in minor ways like when a friend asks whether I can hang out but I'm in the middle of something. In those situations, my instinct is to wait until I have a good answer before I respond, which often means I respond late or not at all.

I think there are a few angles into this one. The first is the value of certainty. Because I don't always know whether the thing I'm doing is going well or badly, I also don't know what kind of answer to give. That information has some value and I want to maximise it. If I'm optimistic, I also expect to be able to give a more positive answer later. So "I don't know" right now loses to "it's going well" later, which itself loses to "good news, it's done!" much later than that. Of course, that's assuming the situation is getting better over time and that the value of that certainty beats the cost of the delay. Both of those assumptions are pretty unreliable.

The second angle is the implies both ways fallacy. Obviously, if things are going badly, I will need to report that they are going badly. It is very easy, then, to put off reporting that things are going badly in the hope that it will prevent that from being the case. It would be nice if implication worked that way, but unfortunately it does not. I think this is especially pernicious in the face of uncertainty; when you're definitely going to miss the deadline, you're not going to convince yourself you can change that by keeping quiet. But if there's still a chance...

The last angle, and I think the one that probably trumps the other two, is just plain dependency hell. When I make one task dependent on other tasks, the situation becomes much more complicated and brittle, and that's no less true when one of the tasks is communication. If I'm trying to manage the communication about a task as a dependency of that task, it requires a lot more thinking and makes both more difficult. And the timelines around communication are often a lot tighter than those around work, so making the tight timeline a dependency of the loose timeline is particularly silly.

So it's pretty clear that there are a few issues feeding into this one. Fortunately, that means I have a lot of ideas for solutions. The first is to make sure I just keep the two goals separate in my own thinking. One goal is to do the thing, and another is to communicate about the thing. The strategies I mentioned in dependency hell should help. I don't think trading off the value of certainty is necessarily wrong, but I need to be careful to balance it against the value of time. In many cases, people are happy to trade timely communication for more accurate communication.

And that brings me to perhaps the main observation: this is sounding very similar to the philosophy I wrote about in feedback loops, done, and continuous everywhere. It's usually preferable to have more, smaller communications than one large communication, for the same reason it's preferable to have more and smaller tasks. It's actually a bit surprising that I didn't think to apply these ideas to communication, given how much time I spent thinking about them with respect to work.

I'm hopeful this bit of reflection will help fix that, by giving me a bit of time to reinforce the association. Relatively speaking, I spend a lot less time thinking about how to communicate than how to work, but it's still important to get right.