I do write status report emails, but that kind of communication has operated very differently at every different organization I've worked in. I'd assume the de

I do write status report emails, but that kind of communication has operated very differently at every different organization I've worked in. I'd assume the department responsible for debugging kernel driver bugs is far less interrupt-driven than the operations-oriented departments I base my experiences on. The common thread though, was usually about prioritizing between the work we already roughly understood how to do. The more common communication failures were about coordinating and scheduling. But when you're doing something specialized enough as debugging multi-threaded embedded drivers, and you have a specific metric like bug closure rate, then all of that information is already captured in the bug log. The first response in the Ars thread says that keeping detailed notes for yourself is both a powerful tool to help you learn, and also a tool for communicating in very specific ways with the rest of the department. One reason better communication isn't a "very easy fix" is that multiple people are involved, and you can't just force everyone to pay attention to all the relevant information already available. Alternatively: I worked on a small development team / startup with daily stand-ups that would tend to last 15 or even 30 minutes. Not a single person in the room ever seemed to know what they were going to say prior to opening their mouths. No amount of "leading by example" seemed to convey the concept that summarization is the most important feature to communication in daily status meetings.