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:
- 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
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
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.