I was very fortunate in starting out as an administrator to work in a small and nimble organization, SCALE. I was extraordinarily green at the time, but very eager for the work and with some intuitive feel for how to get things done. Probably, this is what it's like in a startup and why running your own business has such appeal. Having a strong sense of motion was more important than reaching a pre-specified final destination and the primary near term goal was to sustain the momentum.
The University of Illinois is a large organization and like any large organization, it has its bureaucratic side. That can place unintended roadblocks on innovative activity, particularly with teaching and learning. Many things are done by rules. Even if the rules were conceived with good intent and were sensible in the environment in which they originated, as there are changes in the environment the rules can seem like impediments to innovation rather than as sensible regulation. (This is what provides the small business person's natural antipathy to government. But to assess whether the rules are still appropriate or have become excessive burden, one must look more broadly. I will make some brief comments about that at the end of this piece.) The traffic helicopter theory was born by the observation that such blockages occur fairly frequently and thus should be anticipated. When a particular blockage was detected, the idea then was to "reroute traffic" so as to keep things moving. I will illustrate with a few examples below. They will show that the traffic helicopter approach is not strategic. I would call it tactical+. There is a bit of forward look. Then it is very opportunistic in finding ways to keep things working.
* * * * *
I came into SCALE with an open portfolio, simply to promote ALN (online learning) around campus. Four months later I was running the show. I came up with the traffic helicopter theory after only a few weeks on the job. There were quite enough examples already within that time frame. I continued to practice the traffic helicopter theory for several years thereafter.
One source of blockage on campus is that there frequently are several distinct units with overlapping or complementary missions. Each unit sets its own agenda. Often those agendas are in conflict. It is rare to see the actions of the various units brought into concert, at least that was my experience when I became the Assistant CIO for Educational Technologies - six years later. SCALE, because of its soft-money status and small size, could cut through a lot of the red tape.
The first activity with SCALE I was involved in was the evaluation. It was an important component of the project as it was the formal way that the sponsor (The Alfred P. Sloan Foundation) would learn about the results and how interested parties around campus - the Provost's office, the faculty who were already doing SCALE-supported ALN work, other faculty who might be interested in trying ALN, and various other related players could see what SCALE was accomplishing. But the evaluation was done outside of SCALE, by then OIR (Office of Instructional Resources). OIR had a certain methodology they used on all evaluation work. SCALE leadership was unsure that this method would get at the interesting questions to ask about ALN implementation. There was also the issue of how to report bad news - part and parcel of the data collected or subordinated so the sponsor was presented with a more rosy picture. My recollection is that this question about bad news was more an issue in anticipation of how to handle the problem than it was after the fact because there was much to cover up. Actually, much of what SCALE did was quite good in those days so there were real reasons to be proud of the activity. Nonetheless, there was unmistakeable tension between OIR and SCALE over the evaluation at the time I got involved.
There were two main components of the evaluation. One focused on faculty experiences and was done both via survey and via interviews with individual faculty. The other centered on student experiences, which was done mainly through a survey and then some sampling via focus groups. For the faculty part, OIR was having trouble getting the faculty to grant them interviews. I wanted to meet these instructors so I could develop an ongoing relationship with them. So it was agreed that Cheryl Bullock of OIR, who was tasked to do the faculty interviews, would conduct them with me. Cheryl and I would go to the faculty member's office or to a convenient location of mutual agreement and discuss things with the faculty member. Cheryl's role was quite different from mine. We agreed on (I believe 5) questions that needed to be posed during the course of the conversation. But given that those question were posed the conversation could otherwise be free ranging. I did much of the talking for our side and Cheryl did all the note taking. The faculty were willing, even eager in some cases, to talk to me. This approach worked for all parties concerned and it helped build some trust for what came next.
The student component came next and it was harder - partly because SCALE staff weren't directly involved at all, partly because the data collection effort for the spring 1996 had already taken place (there had been a prior such effort for fall 1995) and the issue of whether the right sort of data was being collected came up pretty soon after I joined SCALE. This could have readily come to an impasse, which in some sense is the easy way out. In that case, everyone gets to stick to their guns. On the other hand, there's no use crying over spilled milk. While I don't recall exactly how this happened, the resolution we arrived at was for me to edit the evaluation document. I could correct errors and suggest other changes to frame things better. But the evaluation team needed to okay these. My training on doing this, it might not seem obvious that it was the right sort of preparation but that turned out to be the case, was in writing referee reports for Econ journal pieces. Over time I learned to be a reasonably good referee in that setting, where if I didn't think the paper should be rejected outright then I saw my role as trying to make the paper better. Refereeing is quite unlike writing the paper yourself. The author is still the owner of the ideas in the paper. In other circumstances, I'd have liked to play more of the author role with the SCALE evaluation. The traffic helicopter theory has no room for such wishful thinking. It requires finding what will work in the here and now. Editing the evaluation document worked.
Another source of blockage is with innovative activity that emerges in one college on campus, but which has value in other places on campus. The first college doesn't have it in its mission to diffuse the innovation elsewhere. But unless that first college goes beyond its own mission to enable such diffusion, that can block the diffusion and thus prevent the activity from scaling enough to where it is supported more centrally.
At around the time I started as an administrator in SCALE, I became the first person on campus to teach with Mallard who was outside the College of Engineering. I did that in the summer session 1996. Mallard was the brainchild of Donna Brown, a professor of Electrical and Computer Engineering, and a graduate student who was doing his Masters work under Donna, Mike Swafford. It was run on an Engineering Workstation Server. Randy Cetin administered that server. Randy worked for the then campus computing organization, CCSO, and the College of Engineering contracted with CCSO for such server administration work. In that contract the rule was the Engineering Workstation services were for faculty and students in the College of Engineering. This is the backdrop for my first encounter with Randy. He initially told me I couldn't use Mallard, for that reason.
I should say that Randy is a nice guy and was patient with me. Further, it was evident that an exception should be made in this case, as it was in the interest of Engineering to promote Donna Brown's work and therefore to let instructors outside the College of Engineering use Mallard, especially early on till a more scalable solution was found. Eventually I was given permission to use Mallard, though I don't recall exactly what greased the skids enough to enable that outcome. But do let me point out here that SCALE itself was administered in ECE, with the SCALE office on the third floor of Everitt Lab, so quite apart from my use SCALE wanted to see Mallard promoted. That may have been what did the trick. In any event, the experience was not so unpleasant at the time and laid some foundation for Randy and I to negotiate on other matters soon thereafter.
Within six months - a few months after I started to run SCALE, Dave Liu, who was a new Associate Provost with online learning in his portfolio, purchased a new Sun Server that CCSO would run and that was supposed to host all the Ed Tech applications on campus, a grand vision. Randy was the administrator for that server. This mattered in two ways.
First, one of the applications that Dave thought would run on this Sun Server would be Mallard. Dave was a professor of Computer Science, another department in the College of Engineering, and he understood the issues entailed with instructors outside the College of Engineering using Mallard on the Engineering Workstation server. He and somebody else (maybe Randy, I don't remember who the other person was) came to visit me at SCALE with the following proposal. Campus would support Mallard on the new Sun server if SCALE would fund an FTE for a Mallard administrator, whose job was to interface between faculty who wanted to use Mallard, the Mallard development team lead by Donna, and the server administration team that Randy oversaw. Given my earlier experience with Mallard and that the students in my summer class reacted favorably to the way we deployed it, I was very receptive to Dave's proposal. We ended up hiring John Groppe as a consequence and later Konstantinos Yfantis to replace John. Mallard use grew substantially over the the next several years as a result.
Eventually that usage outstripped the capacity of the Sun server. But early on there was substantial idle capacity. Part of the reason was the CyberProf, an alternative to Mallard, ended up not being on that Sun server. Another part was that a planned home grown development into a toolkit to support online learning failed. So, given this idle capacity, Randy was looking for other content to support. At the time SCALE had an interest in instructors experimenting with RealAudio, the then current way to stream audio over the Internet. Randy and I agreed that his unit would support the software if SCALE paid for the license. That arrangement stuck for quite a while.
Yet a third blockage can emerge when higher ups tell an innovative faculty member how to proceed, based on an emerging technology that the higher ups would like to see promoted on campus. Innovative faculty are used to making their own decisions, based on their local knowledge of the issues at hand. The higher ups may very well believe they are empowering faculty on campus by promoting the new technology. But the innovative faculty member will view this more as a constraint than as anything else. The innovative faculty member trusts her own instincts about what works and what doesn't. This promotion by the higher ups is really asking the innovative faculty member to surrender her own good judgment.
SCALE had an internal grant program, one of the more important things it did, and once I took over my job was to read grant proposals early on and then negotiate with the proposal writers about their ask - what they intended to do, why that was the approach, make suggestions, and provide counsel about possible pitfalls. Armed with this I could then be quite informed in discussing proposals with the larger review committee. The total ask was in excess of what was to be granted, so there were issues about whether some proposals should be funded but at reduced levels or if some proposals should be rejected outright. My views were important on this as to how the ultimate judgment should be made.
One of those proposals came from Diane Musumeci, who was then teaching the introductory course in Italian. Like me, Diane was using both Mallard and FirstClass to support instruction and we learned soon thereafter that we had several students in common. That was more than mere coincidence and offered some indirect evidence that at least a few students were interested in online learning for their own benefit. Diane and I hit it off almost immediately. We later got quite involved in a larger project in Spanish, did a presentation on that work at the Sloan-C annual conference in 1998, and still later wrote a paper together on some related work. Hitting it off is what got us through the obstacle.
That obstacle was provided by the aforementioned RealAudio streaming. To an outsider like me, foreign language instruction seemed like a natural area to do early experimentation with streaming audio. Burks Oakley, in particular, who was my predecessor running SCALE and who was still on the proposal review committee, thought it should be the centerpiece of Diane's project. But Diane wasn't particularly interested in that. She had in mind the production of an image database. The pedagogic reason is that language learners have ideas that are separate from the English word used to connect to the idea and one can learn the word in the foreign language quicker by making reference to the image than to the English word. There is translation with the latter while no translation is needed with the former. To me this seemed insightful and I wanted to support Diane in this work. It only occurred to me later that such an image database could be used in teaching any language, so doing it then for Italian would accelerate the development of the Spanish project when that came along, the following year.
It is also true that RealAudio was an exotic application at the time. Bandwidth was scarce - on many places around campus and certainly at home where most of us were on dialup. Without ample bandwidth the files could choke and the user would grow impatient with the software when that happened. Larger classes might very well experiment with technology a little, but there are limits to doing so based on the reliability of the software.
So in this case I provided some cover for Diane by pushing back against Burks. She got to do the project she intended to do and it went well. Subsequently, the Spanish project became the most important of the various SCALE Efficiency Projects, which saved our necks with regard to support from Sloan, so all was forgotten about this temporary conflict. It was brought up here not for that reason, but to illustrate a different point. A campus administrator needs to trust his innovative faculty. They are his greatest asset. Running interference for them is part of the job description.
* * * * *
With these examples in hand let me switch to some lessons learned.
1. The traffic helicopter theory is fundamentally a bottom up approach where others drive the bus. As an administrator, you will not hear from these others most of the time unless they are having problems. From the administrator's perspective, the approach is to be on the look out for the problems and then to find reasonable fixes asap.
2. Being on the look out means you keep a file of potential issues (I kept it in my head) and another file of potential uses and then you periodically check whether some issue might block a particular use. In the ideal, the data gathering on issues happens well before the use and the issue is managed in such away that most users are never aware there was a problem to begin with. This is another reason to champion innovators and early adopters. They identify these issues for you and can give a heads up so that those who come later don't have to got through all that hassle.
3. The role is primarily as broker - matching the person(s) with the problem to the person(s) with the fix. There may be a bit of creativity involved in reframing the problem in a way where a fix can be found. But there is not creativity in the sense of fundamental design.
4. The willingness to engage in the broker function vigorously and sublimate the design function requires a suspension of ego. Indeed much of the conflict discussed above can be viewed as different egos butting heads. Adding one more ego to the mix doesn't help. There is a question then about how ego can be suspended. Most of us are not saints. Taking care of number one is a prime motivator. What can offset that? Here are two different answers that make sense to me.
I was very naive when I took over SCALE. I felt inadequate to do the job as a result. In many respects that was actually an advantage. I put in a lot of effort to compensate for the lack of experience. And I was quite willing to suspend my own ego at the time because I didn't have the experience on which to base good judgment, so I was willing to assume others knew more than I did.
The above works for anybody who is new to the job, but over time the novelty wears off. What then? Here I think failure has a lot of value. There are some obstacles that are insurmountable. It may not be clear why that is up front; one can try and yet fail with those. A substantial area where I failed, and the campus failed, quite miserably actually, was in tech transfer. Mallard should have been commercialized. CyberProf too. They may not have succeeded on the open market, but we couldn't even get them out the door. I experienced other failure with particular people who worked for me. Failure enables a sense of humility based on experience. With sufficient humility, ego can be suspended.
Nevertheless, I believe it is hard to sustain the traffic helicopter theory indefinitely as done by a single individual. Eventually the person wants to have his hand at being a designer.
5. There is enormous desire by others on campus for somebody to practice the traffic helicopter theory and do so effectively. Everybody and his brother does strategic planning. We've been to that movie many times before. Who does effective implementation? It is rarer to see.
One of the true surprises for me after I had been running SCALE for between six months and a year was to see an embrace of these efforts by some of the techies at CCSO, who had apparently been waiting to see this for quite some time.
Via Donna Brown I learned about Bluestem, a Web Iso, then a hot form of Internet security. Donna was very keen on putting Bluestem in front of Mallard. Doing so was one of the reasons why its use grew geometrically at the time. Grade information was being stored there. That information was secure. Elsewhere similar transactions were happening in other online environments, but done in the clear.
Bluestem was developed by Ed Kubaitis, a top programmer at CCSO, who marched to the tune of his own drummer. At around the time that Mallard implemented Bluestem I gave a presentation in then Comm West (now Wohlers Hall) about SCALE activities and during it I must have talked about Mallard and possibly showed my own class use. The presentation was targeted at potential faculty users. But Ed Kubaitis was in the audience. At the end of the talk he came up to introduce himself, shake my hand, and thank me for my efforts. It was one of those MasterCard moments - priceless.
6. There may be no rewards from one's superiors in embracing the traffic helicopter theory, even if it works quite well when implemented. Let me say this cuts both ways. Building a good reputation does matter and effective implementation of the traffic helicopter theory helps, no doubt, in building one's personal reputation. But for the same reasons that research trumps teaching on campus, the rewards, and here I'm talking about personal recognition - salary and promotion in particular, result from designing a program that works. That's what is visible and what one's superiors can judge. In contrast, making the design of others work when their project starts to confront "traffic problems" is not something you should claim credit for.
I don't know that this is the reason why only a few practice the traffic helicopter theory. I think it more that people don't perceive the need or don't feel they should play the role given the position they are in. Yet if you are enlightened enough on that point, you should not be naive on how it will impact your own career advancement. There might be no impact at all.
Wrap Up
The purpose of this piece was to use a bit of personal history to advocate for an enlightened tactical approach to support of teaching and learning on campus (and quite possibly in other areas as well, and maybe the same message applies to other large institutions). Motion is important, more important than most people acknowledge. Gridlock demoralizes terribly and becomes the recurrent expectation. To cut past that things must get done. But Illinois is a very decentralized place and to expect things to get done in a top down manner is for administrators to kid themselves. The Traffic Helicopter Theory offers a way to make progress. It is not perfect. But it can work.
Another possibility would be to have fewer obstacles by having fewer rules and mandates - the deregulation approach, so to speak. In considering this alternative I'd ask whether the rules make sense to govern ordinary function. There can be bad regulation, which should be gotten rid of, here measured by how the rules do in regulating ordinary function. (Here I'm talking about campus imposed rules as presented, for example, in the Campus Administrative Manual. Those are the rules that are within scope to possibly be changed or eliminated.) If the rules do reasonably well in the ordinary context, however, then they should be preserved, even if they serve as blockage of innovative activity. This is an argument for rules plus the Traffic Helicopter Theory rather than for no rules and Laissez-faire. That's what makes sense to me in the academic environment, if not more broadly as well.
No comments:
Post a Comment