- At work, my colleagues and I help each other improve our "brief ins," which are the memos and messages to others that we use to describe an assignment, request a review of a document, or define a request for the layout and design of a report.#
- When I write my brief ins, I have to remind myself to write more than I initially think and to add details before I send it off. I know this about myself: I usually say too little, either because I haven't fully thought out what I want to say, or because I'm assuming or expecting that the other person will know what I'm thinking.#
- Some of my friends and colleagues are the opposite; they provide a lot of detail and many layers, often too much and too long for busy leaders or peers to be able to quickly scan.#
- The goal for us all, of course, is to communicate with just the right amount of information, definition, and detail to help another person understand the context of what we're requesting, what we need to happen, and when we need it to happen.#
- I appreciate how my colleagues help me improve my writing, and how they respond to my edits and suggestions. We have a great team at DCRI Research Communications and Engagement, always improving and progressing.#
Thinking about all that, recently, I figured I should tell my colleagues about what I've learned from Dave Winer about how to write good bug reports. Over the last decade, Dave has helped me write focused messages about what I encounter when I'm testing or using his software. His request is that I always answer these three questions:#
- 1. What was I doing? #
- 2. What did I expect to happen? #
- 3. What actually happened? #
- I was nervous when I first started submitting bug reports to Dave, but I've come to welcome the rigor of that three-part test. I have used what I learned from Dave to improve my work brief ins, too.#
- I also want to tell my colleagues about Dave's Narrate Your Work. That's his way to keep track of what he's developing day to day and to show others what's he working on. Every now and then, Dave gives us a view to his development worknotes, and I'm always fascinated by how disciplined he is in noting the day's progress and planning the next day's first task or focus. #
- For example, here's his Change Notes for Drummer, his great new outliner-based blogging system. (Last year I helped Dave test Drummer; I contributed bug reports, some better than others.) #
- Drummer, I've been thinking, could be a good way for me and my colleagues to narrate our work according to the performance goals set for us by our managers. I can imagine how an outline of my worknotes can make it easier to write my self evaluation next spring. The better I can show how I met and exceeded those performance goals, the better my chances at a raise or a future promotion.#