Communication and Documentation (longer, connection-enhanced version)
Communication and Documentation
[I am feeling a bit like Chuck Lorre, the producer for several extremely popular television series, including the The Big Bang Theory (TBBT). Chuck has “vanity cards” which appear very briefly at the end of each episode of the shows. These vanity cards express Chuck’s perspectives, insights, and fevered rants on a variety of topics, and basically act like a blog. Since I record TBBT quite extensively (any similarities I have to Sheldon Cooper will be, and have been, hotly contested), I have gotten good at pausing the recording to read the card. Every once in a while, the card makes some reference to censoring, but with a website address to indicate where you can read the uncensored version of the card. When I first created the “Communication and Documentation” entry for the Indiana Space Grant Consortium Director’s Blog / Notes, it was pointed out that it was long and tangential and wouldn’t appeal to some of the readers. Well, in Chuck Lorre fashion, I edited the blog entry for that audience, but here’s the full version. Why? It’s GROUPER—so, it’s because I can. And those of you in GROUPER will recognize Karim and know why Shannon and Weaver are important. So there. –BSC]
“Document your code!”
This is a lesson I remember from my first computer programming course as a college frosh, now more than 30 years ago. The language was FORTRAN, and the computer was a PDP 11/44[*] but the lessons were the same. If you didn’t provide enough comments in your code for the instructor to understand what your logic was intended to accomplish, or what the variables meant, or what that subroutine was for, you got points off. The essential message was not subtle: no matter how good a job you think you did, you haven’t done the whole job unless you’ve effectively documented it. Over the past few weeks, I’ve had substantial reminders of the importance of those lessons of communication and documentation.
Since the Affiliates’ Meeting in April, the INSGC staff have been trying to upgrade our processes and activities, and bringing onboard a new set of student interns for the summer. Part of this comes from our Affiliates’ survey of communications with the Central Office. Although the overall responses were excellent (from the perspective of demonstrating to NASA that we take our performance seriously and assess it regularly), there were some areas of concern (from the perspective of continuous improvement and achieving a model of excellence). It’s clear that we could use our website to better advantage, and thus that is a priority for us this summer. Angie has reported a much more timely and useful set of responses to our requests for reporting, due in part to our more clear presentations of what, when, and why we need those reports to meet our NASA grant reporting and documentation obligations. Wow… we can get that much more just by being more explicit about what we’re looking for, and how we need to use it?
Effective communication is a tricky thing. Some people like their documentation “spiced up” a little bit; others just want the immediate facts, in order, with an agenda of what will be covered and how many minutes are associated to each fact. I just had two conversations this weekend highlighting these challenges. On Friday, I had dinner with one of my former students, who recently started a new job at a major hospital as a quality engineering and improvement manager. He noted that some of the physicians and others at the hospital were frustrated with some of his meetings, because they couldn’t see how, or whether, there was a point to the meeting and what they were supposed to recognize and respond to that point. (Interesting: that was, almost verbatim, one of the comments from our Affiliates’ survey.) He said that those people would have found our research lab meetings intolerable, but he then took the feedback as an indication to simply write down what he already had in his head and give it a more formal structure as a meeting agenda. I have had to learn the same lesson in our INSGC Central meetings and those with Dawn and Angie—it’s the agenda that helps focus time and understanding, and improves advanced preparation.
What level of communication works for you? A friend of mine commented on my software commenting style over the weekend, because I was the only person they’d known who actually used “emotion” and eloquent language structures in their code [†]comments. On the one hand, there is a big world of language out there, and it’s nice to be able to use it well and communicate richly. On the other hand, one doesn’t want to turn into Dennis Miller as the color commentator for Monday Night Football, making snarky or esoteric literary references that even your colleagues don’t understand, when all they wanted to say was that it was good that the guy in the blue uniform tackled that guy in the white uniform. Do people find your style amusing and intelligent, or obscure and elitist? This is an important question when you’re trying to do public outreach and engagement for the general population. There are lots of different audiences (faculty and students who receive awards, administrators who want to know effectiveness of campus cost sharing, people who stop you on the street and ask you questions about airspace utilization), and I want to learn how to connect with them all.
Is this where I mention that one of our primary ways of regular communication with our affiliates, partners, and friends is the INSGC Director’s Blog? I try to put together a new blog entry every month or so, and use it to communicate some of our strategic concerns and general oversight topics. Great, right? Except that Dawn told me a few days ago that people don’t look at the blog entries. (That is the point of website analytics—is anyone actually receiving the message you’re sending?) Well, if we never updated the blog, that would be the expectation. Or, if it was assumed that nothing important ever showed up there. But what if I said that the best way to see what we’re planning for (and why) will show up first, or best, or most explicitly, in that Director’s Blog? Would that get more visits? Perhaps, but the goal of the blog is not more visits. It’s to communicate more effectively with our constituents.
According to information theory (as developed by Bell Laboratory researcher Claude Shannon and MIT professor Norbert Weiner), communication includes a sender, a transmission channel, and a receiver. There have to be several effective elements of good communication: the sender has to send a message that is meaningful to the receiver; the channel must be able to support that message; there has to be a minimum of noise or signal loss to distort the message; there has to be enough redundancy of the message so that the receiver understands the intent of the message even if some of it gets lost. (This seems very tangential to the point of anything else relevant for Space Grant Directors. However, it’s actually part of my research background and training. For me, the analysis of communication effectiveness is a social and technical engineering problem, and not just a management or persuasion issue. Remember, the message is based in part on the context of the sender as well as the context of the receiver. I’m trying to explain more of my context in a more explicit way. Any resemblance to Dennis Miller’s football color commentary is accidental.)
So, what next? Over the rest of the summer, expect additional upgrades to our communications: not just in the use of the available technologies, but in our strategies, messages, and references. This is a critical point in Space Grant evolution, and I believe that one of the ways that INSGC will succeed in the future is to be a powerful and effective source of communication and documentation of STEM engagement in the State of Indiana.
[*] The specifics here are only to suggest that I have been a geek for a very long time. Some of you may fondly remember coding in FORTRAN, or even what a PDP is. If you don’t, just think of it as part of that quaint long-ago time when there were pay phones that people used coins to operate when they weren’t at home to access their permanently wired landline phone.
[†] Yes, these are the sorts of friends I spend my time with. We talk about styles of software comments, and mathematical models of information exchange in company meetings, and the use of multi-dimensional graphs to understand social dynamics. Don’t judge. It works for us.
September 5, 2016
Back to School
The Labor Day holiday weekend is drawing to a close, and I have finished up my second week of the Fellowship. Even though the start dates of the semester and my tenure here in DC were the same, I have gotten to notice how much the routines differ between the two environments. Unlike my academic routine that can adapt and adjust based on the day of the week and the differences between class and no-class, committee and research schedules, things feel distinct here. There is a bus I catch, most days, between 8:14 and 8:40. On Wednesdays, there will usually be lunch with the other Fellows. There are Monday and Thursday morning “huddle” meetings.
However, that is not what I notice the most from the past two weeks. I admit that I have developed a particular appreciation for my manager. Each day, there is a specific new thing I have to learn. How do I send a particular type of email? What is the formatting for this kind of documentation? Who do I contact for this activity? Of course, he’s seen this all before, but it’s my first time. And it’s not like I have had 3-4 weeks of easing into the situation. I’ve already worked on international memoranda, and meetings between embassy staff and local representatives, and sat in on planning discussions with the offices of some folks whose name might appear on someone’s bumper sticker. (But notably, the importance of the office is communicated by an acronym, or even a single letter; the people whose names are used are names I don’t recognize, and even those names go with acronyms.) The most appropriate phrase for this experience is one that I learned during my first few weeks as an undergrad at MIT: “Drinking from the firehose.”
In that environment, where I’m supposed to come up to speed quickly, it seems like a luxury to have someone check in with me as many as 3-5 times per day to help me with one task or another. In truth, some of the help sessions seem a bit remedial, teaching me things I do already know. But he doesn’t know that. And more importantly, I don’t always know when something I think I know how to do isn’t exactly how this organization does it. So, I find myself learning to be more patient when being taught, and listening all the way through the lesson. I even have a guiding document for goals to achieve over the next month or so—distinct from a to-do list of tasks, and an in-process list of assignments.
One of the things that surprises me most about this firehose experience is a new-found empathy and appreciation for the situations that confront new students in the lab. We’ve been working on SoS and PoSE conceptualizations of ICT use in the SHARK and DOLPHIN and PERCH* streams for years—why are you nodding blankly at me? Of course. I’ve been doing it for years. You just got here. I just used a bunch of acronyms—shorthand for me, incomprehensible jargon for you. Even when we get to time for a thesis outline, or a prelim draft, or a set of PhD defense slides, it does take some reminders to recognize that two dozen years of practice and 75 or more iterations don’t get transmitted easily to someone who is experiencing it all new and in an intense, nervous state.
I would like to hope that this lesson comes back to Purdue with me next Fall. For a new student, or new faculty member, each new item can be part of an overwhelming onslaught of novelty and complexity. Maybe it won’t stay that way for long, but it feels like that now. In the senior capstone design course I teach, I remind the students to take the time to capture those initial moments of novelty and first attempts at processing and decision making, because it will be really hard to recall those feelings (and assumptions, and senses of confusion) again later. I can tell them that, but it was a long time since I have felt that at the level I feel it now. It’s good to be reminded of what the first few, chaotic weeks of new experience feel like.
Photo of Little Kern Golden Trout by Middleton and Liitschwager (1988), hanging in the C Street entrance lobby of the National Academies.
*Acronym decluttering:
SoS: Systems-of-Systems. or a description of complex systems engineering settings where individual components of an overarching system represent complex systems in their own right (such as individual aircraft, with pilots and co-pilots, in the airspace over Washington, DC while Marine One is traveling across town).
PoSE: Perspectives on Systems Engineering. This is a course that I developed to teach about four distinct traditions of systems engineering, ranging across systems thinking, cybernetics, component-whole relations, and project management. Only in its second iteration as a hybrid distance / on-campus course, it is one of the most subscribed courses in Engineering Professional Education (and I’m not even teaching it this semester).
ICT: Information and Communications Technology. When I first started as a faculty member, most computers had line-by-line display screens in single colors of amber or green; email and word processors and bulletin board chat groups were the most sophisticated information exchange tools available. Even with all of the changes in capability, it’s still important to recognize that the point of these technologies were, and are, for humans to communicate.
SHARK, DOLPHIN, PERCH: These are designations of project areas within the research lab, referring to knowledge sharing architectures, information flow delays, and applications to healthcare delivery improvement, respectively. Check them out at https://engineering.purdue.edu/GrouperLab/streams/.