Timing is Everything
Although it doesn’t always feel like it here in the lab, things are actually going very well. The work calendar is quite full, and the project to-do lists continue to grow—not just in the number of items, but in the number of projects which require to-do items. Three different Institutional Review Board (IRB) applications, with three different students. Four research projects active, with two or three more coming on line. The “March Madness” travel schedule I had last year is even worse: the lab has now officially declared it “Winter Madness” (from January 24 until March 14, there is only one week where I am not in an airport on Friday, Saturday, or Sunday of that weekend—and on March 21-24, I will be driving back from Chicago on Friday, and flying again on Monday).
Last Thursday, though, I was able to appreciate what some good timing could achieve. A day earlier, I had escaped from the ice and snow storm that paralyzed the Southeast US: leaving out of western Virginia early Wednesday morning, on a rebooked flight through Detroit (all flights through Atlanta had been cancelled as of Monday evening). I was only a few hours later arriving home than originally scheduled, even with delays and flight diversions (let’s hear it for multiple daily nonstops from Detroit to Indianapolis!). Thursday was bright, clear, and even relatively “warm” (about 5F that morning, with a high temperature of approximately 30F) for a drive down to Bloomington, IN for a research meeting. That research meeting was in support of one of our new grants, a project with the Purdue Center for Education and Research in Information Assurance and Security (CERIAS) to look at sensemaking, distributed expertise, and information presentation in cyberinfrastructure network operations centers. The meeting was unexpectedly effective in highlighting both people to talk to and additional directions for the research to pursue. A positive attitude to go down on the one nice day where my schedule permitted the trip was better than putting the trip off for later (given “Winter Madness” and the frequency of airspace-paralyzing storms, I am not thrilled about trying to create new one-day visits anytime before April). At the end of the day, I even received one more treat derived from an awareness of good timing. As I left the office, the nearly full moon was visible to the east, while the International Space Station was a fast-moving evening star traveling from northwest to northeast. (No, I don’t have the orbital tracks memorized, but there are NASA websites and software apps for that.) Yeah, that was some good timing.
Timing is a fairly popular subject of GROUPER research, even if there’s only been a couple of blog entries highlighting time pressure (and only one on time perception). But the topic is never far from our mind. In our direct research investigations, we talk about the sense of time pressure as the ratio of time required to complete a task to the time available to complete it (TR / TA), with time pressure increasing as you run out of time to finish faster than you run out of task to complete. We worry about the challenge of the age and “freshness” of data when making decisions about the current state of a dynamic world (and what you need to do based on that state). We consider how experts trade other resources for time, including the decision to create an interim solution (“safe mode”) to stabilize a degrading system to allow for more time to consider a better, more stable recovery and repair. But how does that play out in the lab’s daily activities, other than a posting an ongoing (and continuing growing) list of deadlines?
Fortunately, we have been working on a set of very promising solutions (processes, really). As I go through my travel schedule, the students get a strong sense of the “windows of opportunity” (time periods of available work capacity) where I can respond to a task request or help them make progress towards an external deadline. A few months ago, I described some of my thought process in working in a distributed way on these tasks; I think in terms of a set of scaled answers to the student’s question. In essence, my thought process and general formulation goes like this:
Student: Dr. C., I need you to do xyz by time TD.
(If (TD – Now) is under 12 hours, I tend to get really upset. Don’t do that.)
BSC: What do I need in order to do xyz?
Student: You need A, B, and Q.
(If I don’t have A, B, or Q, and the student doesn’t provide it at the time of the request, I tend to get really upset, Don’t do that.)
Then I usually try to provide one of a set of answers, ranging from:
- NO.
- Not by TD; the best I can do is Talt.
- I can do xyz’ by TD.
- I can do that, but can’t start until TS.
- Yes, working
- DONE.
What I didn’t expect was how providing this type of information to the students could actually change the style of interactions in lab. It’s not that I declared some specific required email format, or that I would refuse to read emails that did not conform to that format. But, within a week or two, I started noticing emails with subject lines including the words:
ACTION REQUIRED / REQUESTED, or
INFORMATION ONLY.
The body of the emails would specify details like:
Estimated time to complete: xxx
Date / time needed: dd mmm yy hh:mm
So, rather than simply complying with a command, the students now understand my motivations, and my constraints, and my strategies for organizing my time. I also pointed out that I try to set aside windows of time in advance for everyone—not just in the weekly 1:1 meetings (which, I confess, is much harder to achieve during the Winter Madness travel), but when I expect tasks towards external deadlines. Knowing in advance how much time to set aside helps me with schedules, and allows for slipping in new tasks on an emergency or opportunistic basis. It’s all part of a goal of “Better Information Now” that we have worked with in our projects with the Jet Propulsion Laboratory and the United Space Alliance. Sometimes, it works very well, and sometimes it still needs adjustment and improvement. But at least, we’re making progress.
It’s about time.
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/.