Knowing and Doing

... with folks in university administration, colleagues whom I respect and with whom I like to work.

[earlier]

Them: These reports can't be combined. Please make separate ones.

Me: They will be identical.

Them: That's okay.

Me: Fine.

[later]

Them: These reports are identical. That's a problem.

Me: That's what you asked me to do.

Them: They can't be identical. Please make them different.

Me: But the committee in charge told us long ago to combine the tasks, so we did. Most of the resulting document really is one item, so we have a common report.

Them: But the reports can't be the same. Please make them different.

Me: But they aren't different.

Them: If they aren't different, the board will be unhappy.

Me: But if I make reports that differ artificially, they'll see that, too. And if they differ only a little, then it will be hard to tell where they differ.

Them: If they aren't different, the board will be unhappy. Please make them different.

Me: But...

Them: Please.

~~~~~

This is the sort of situation that makes me wonder (1) if the board really understands how universities work and (2) what I am doing in The Office.

They can say:

"You! Off the bus!"

The key task, then, becomes getting people into the right seats. That can be difficult when folks are happy with their current seats and have an almost inalienable right to stay on the bus. That's part of the challenge...

My three-year review as department head is over, and a couple of weeks ago the dean asked me to serve a second three-year term. I accepted. My first three years went quickly, and as time passed my ideas for the department have evolved and come into better focus. I welcome the opportunity to work with the faculty to achieve them for three more years. Even still, I told the dean that I miss having more time to do computer science. Opportunities to teach and program are more valuable to me than ever before.

When I became head, I thought that I would find myself writing patterns to document my experience, but that has not happened. I spent much of my first three years in a bit of a haze, without any clear grasp on patterns of success in management, leadership, promotion, and the like. In retrospect, that isn't surprising, giving my near-complete lack of experience in these areas before starting!

Since re-upping, I have been thinking about some of the things I have learned in my first three years. Here are three. Maybe they will become parts of patterns at some point.

You have to be comfortable knowing and not doing.    I am something of a control freak and have had to learn to let my secretary and other faculty do things. For example, in today's world, technology makes it almost as easy for me to do a lot of clerical work, but time spent doing it is time not spent doing something else. On the flip side, I can't let not doing something being a reason not to know how to do it, or how it works. I need to be able to fill in when the person responsible is gone, and I have to understand how things work so that I can manage budgets, re-engineer processes, and the like.

Talking is doing something.    I am a programmer, and I like to make measurable progress. Like many folks who tend more toward introvert than extrovert, I tend to prefer doing to talking about doing. This is so even when I know intellectually the great importance of communication. Three years as head have taught be in a more visceral way the value of talking -- to faculty, to administrators, to business leaders and legislators, and to potential students and their patterns. The stories we tell to outsiders matter so very much. And the bonds we on the faculty build among ourselves, and the bonds we nurture between the head and the faculty, are essential to the functioning of the team that is the department.

You can't not be that guy.    No matter how much or how well a department head tries to communicate with the faculty in his or her charge, there is likely always going to be someone for whom the head is "the boss". Those relationships takes extra care, because you need to work on being part of the team at the same time you also work on being a good boss.

I hope that those are not the only things I have learned in the last three years, but they are a start.

Leave it to George Costanza. In the episode of Seinfeld titled The Masseuse, George finally has a great relationship with a wonderful woman. Inexplicably, she likes everything about him. Yet all he can think about is Jerry's current girlfriend, a masseuse who can't stand George. Rather than turn his attention to his own loving partner, he makes such a strident effort to get the masseuse to like him that he drives her even further away -- and loses his own girl, who can't understand George's obsession. But it's really quite simple: George wants everyone to like him.

I understand that not everyone will like me. But deep inside it's easy to lose sight of that fact in the course of daily interactions. When I became department head, one of my goals was to treat everyone fairly, to be open and honest so that each member of the faculty could trust that I was giving him or her a fair hearing and doing the best I could to help him or her succeed within whatever conditions we found ourselves to be operating.

That's where George's problem tries to sneak in the door. What if I do treat everyone fairly and am open and honest; what if I do all I can so that each faculty can trust me and my intentions -- and still someone is unhappy with me? What then?

Trying to do what George tried to do is a recipe for disaster. As hard as it is sometimes, all I can do is what I can do. I should -- must -- act in a trustworthy manner, but I cannot make people like what I do, or like me. That is part of the territory. For me, though, the occasional encounter with this truth sucks a lot of psychic energy out of me.

This is the second semester of my third year as head, which means that I am undergoing a performance evaluation. I suppose the good news is that the dean feels comfortable enough with how I've done to do the review at all, rather than look for a new person for the next three-year appointment. He is using an assessment instrument developed by the IDEA Center at Kansas State. The faculty were asked to judge my performance on a number of tasks that are part of a head's job, such as "Guides the development of sound procedures for assessing faculty performance" and "Stimulates or rejuvenates faculty vitality/enthusiasm". My only role in the process was to rank each of the tasks in terms of their importance to the job.

I look at the review as both summative and formative. The summative side of the review is to determine how well I've done so far and whether I should get to keep doing it. The formative side is to give me feedback I can use to improve for the future. As you might guess from my fondness for so-called agile software development practices, I am much more interested in the formative role of the assessment. I know that my performance has not been ideal -- indeed, it's not even been close! -- but I also know that I can get better. Feedback from my colleagues and dean will help.

Though I was not asked to assess my performance on these issues, I do have a sense of my job performance. I have been only marginal in managing day-to-day affairs. That task requires a certain kind of focus and energy that I've had to develop on the job. I've also had to learn how to respond effectively in the face of a steady barrage of data, information, and requests. I have also been only marginal in "leadership" tasks, the ones that require I take initiative to create new opportunities for faculty and students to excel. This is an area where I have had a lot of ideas and discussed possibilities with the faculty, but finding time to move many of these ideas forward has been difficult.

In an area of particular importance to our department given its history, I have done a reasonable job of communicating information to the faculty, treating individual faculty fairly, and encouraging conversation. I recognized these tasks as primary challenges when I accepted my appointment and, while I had hoped to do better, I've done well so far to keep this dynamic front and center.

The results of the faculty survey are in; they arrived in my mailbox yesterday. I decided not to read the results right away... I have been a little under the weather and wanted to preserve my mental energy for work. The last session of my 5-week bash scripting course meets today, and I would rather be focused on wrapping up the class than on the data from my evaluation. I can tell myself not to fall victim to George's masseuse problem, but sometimes that is more easily done with conscious choices about how and when to engage relationships.

This afternoon, I'll look at the data, see what they can help me learn, and think about the future.

Today I spent the morning meeting with prospective CS majors and their parents. These prospective majors were high school seniors visiting campus as part of their deciding whether to come to my university. Such mornings are exhausting for me, because I'm not a natural glad-hander. Still, it is a lot of fun talking to folks about computer science and our programs. We end up spending a lot of time with relatively few folks, but I think of it like the retail politics of Iowa's caucus campaign: the word-of-mouth marketing is more valuable than any one or two majors we might attract, and these days, every new major counts.

Twice today I was surprised but a question that more high school students and parents could ask, but don't:

Me: So, you're interested in computer science?

Student: I think so, but I don't really know what computer science is.

Parent: Can you tell us what computer science is and what computer scientists do?

I'm glad that kids are now interested enough in CS to ask. In recent years, most have simply bypassed us for majors they understood already.

My answer was different each time but consistent in theme to what I talk about here. It occurs to me that "What Is Computer Science?" could make a good blog entry, and that writing it in concise form would probably be good practice for encounters such as the ones I had today.

My horoscope says so:

Thursday, January 24

Scorpio (October 24-November 22) -- You are smart enough to realize meeting force with force will only result in non-productive developments. To your credit, you will turn volatile matters around with wisdom, consideration, and gentleness.

Now, I may not really be smart enough, or wise enough, or even gentle enough. But on days like today it is good to hear such advice. Managing a team, a faculty, or a class involves a lot or relationships and a lot of personalities. Using wisdom, consideration, and gentleness is usually a more effective way to deal with unexpected conflicts than responding in kind or brute force.

Some days, my horoscope fits my situation perfectly. Today is one. But I promise not to turn to the zodiac for future blogging inspiration, unless it delivers a similarly general piece of advice.

Yesterday was the the sort of day that makes my CS friends and colleagues ask if I am crazy for being department head. It was the third day of classes this semester. A dozen students came by, for advising on course selection, for help switching sections, and the like. I produced a schedule mapping graduate assistants to open lab hours, ran it past the GAs and the faculty, and then distributed it. The phone rang repeatedly, with calls from other offices on campus and from off-campus folks asking questions about scholarship application deadlines.

Every time I started a new train of thought, an interrupt occurred. Context switch, new process, and return. Each task was, individually, just fine. In fact, I enjoy talking to students, new and returning, and helping them make choices about their studies. But little or no computer science happened.

Today was my teaching day, so I got to spend plenty of time thinking about shell scripts. That's not Computer Science, but it's computer science, and as a hacker I loved it. Of course, yesterday's interrupt-fest cut into my prep time enough that I didn't feel as prepared for class as I like to be. But I got to think about software tools, writing code, duplication, abstraction -- many of the things that make me a happy computer scientist.

Tomorrow I travel to Des Moines to help select the winners of the 2008 Prometheus Awards, the Academy Awards of IT in my state. Four hours on the road. A great outreach activity, an important role for my university, and conversation with some sharp, interesting people who are involved in my discipline's industry -- but little or no computer science.

The weekend will be here soon.

After "worrying out loud" in a recent entry, I suppose I should report that our faculty retreat went well. We talked about several different across over the course of the day, especially long-term goals, outcomes assessment, and tactics for the next few months. The biggest part of our goals discussion related to broadening our reach to more students who are not and may never want to be CS majors. That includes science majors but also social science, business, humanities, and education students.

While discussing how to determine whether or not our courses and programs of study were accomplishing what we want them to accomplish, we had what was in many ways the most interesting discussion of the day. It dealt with our "capstone" project course.

In all of the CS majors we offer, each student is required to complete a "project course" in one of the areas of study we offer. This will be the third course the student takes in that area, which is one way that we try to require students to gain some depth in at least one area of computing. When we added this requirement to our programs, the primary goal was to give students a chance to work in teams on a large piece of software, something bigger than they'd worked on in previous courses and bigger than one person could complete alone.

Some of our project courses are "content-heavy", in that they introduce new topical content while students are working on the project. The compilers course is an example of such a course; "Real-Time Embedded Systems" is another. Others do not introduce much new content and focus on the team project experience. "Projects in Systems" (for the OS/networking crowd) and "Projects in Information Science" (for the database/IR crowd) are examples. Over the years, as we've broadened our faculty and the areas we teach, we've added new project courses to the broaden the type of experience offered as well. In some of these courses, code is not the primary deliverable. For example, in "Software Testing", students might develop a testing environment, a suite of test plans, and documentation; in "User Interface Design", students focus on developing a front end to an existing system or to a lighter proof-of-concept back end that they write. Some of these courses implement looser versions of the original idea in other ways, too. My compiler students usually work in pairs or threes, rather than the four or five that we imagined we designed this part of the curriculum over a decade ago.

Our outcomes assessment discussion turned quickly to the nature of a project course and in particular the diversity we now offer under this banner. We can't write outcomes for the project requirement that refer to code as a primary deliverable if, in fact, several courses do not require that of students. Well, we could, but then we would have to change how we teach the courses -- perhaps drastically. The question was, is code an essential outcome of this part of our curriculum?

We faced similar questions as we explored the other elements of diversity. How much new content should a project introduce? Must students write prose, in the form of documentation, etc.? Should they give oral presentations? If so, should these be public, or is an internal presentation to the class or instructor sufficient? What about the structured demos that our interface design students give as a part of an end-of-the-term open house?

I enjoyed listening to all of my colleagues describe their courses in more detail than I had heard in a while. After our discussion, we decided for the most part to preserve the rich ecology of our project course landscape. Test plans and UIs are okay in place of code in certain courses; the essential outcome is that students be expected to produce multiple deliverables across the life of the project. We also found some common themes that we could agree on, even if it meant tweaking our courses. For example, whatever kind of presentation our students give at the end of the project, it should be open to the public and allow public questioning. We will be writing these outcomes up more formally as we proceed this semester and use them as we evaluate the efficacy of our curriculum.

I was impressed with the diversity of ideas in practice in our project courses. Perhaps the results of this discussion were interesting mostly because we have had this sort of conversation in a long time, at least not as a whole faculty. It's funny, but "shared knowledge" isn't always what we think it is. Sometimes we don't share as much as we think we do, at least of the surface. When we dig deeper, we can find common themes and also fundamental differences, which we can then explore explicitly and in the context of the shared knowledge. It was neat to see how each of us learned a little something new about the goals of the project course and left the conversation with an idea for improving our own courses. My compiler students certainly don't write enough technical prose in my course, certainly not as much or as structured as students in some of the other project courses. I can make my course stronger, and more consistent with the other options, by changing how I teach the course next time, and what I require of the class.

Our retreat didn't answer all my questions about the direction of the department or our strategic and tactical plans. Only in the fantasy of a manager could it! My job now is to take what we learned and decided about ourselves that day, help craft from that a coherent plan of action for the department, and begin to take concrete actions to move us in the direction we want to go. I hope that, as in most other endeavors, we will do some things, learn from the feedback, and adjust course as we go.

I have always liked the week before classes start for a new semester. There is a freshness to a new classroom of students, a new group of minds, a new set of lectures and assignments. Of course, most of these aren't really new. Many of my students this semester will have had me for class before, and most semesters I teach a course I've taught before, reusing at least some of the materials and ideas from previous offerings. Yet the combination is fresh, and there is a sense of possibility. I liked this feeling as a student, and I like it as a prof. It is one of the main reasons that I have always preferred a quarter system to a semester system: more new beginnings.

Since becoming department head, the joy is muted somewhat. For one thing, I teach one course instead of three, and instead of taking five. Another is that this first week is full of administrivia. There are graduate assistantship assignments to prepare, lab schedules to produce, last-chance registration sessions to run. Paperwork to be completed. These aren't the sort of tasks that can be easily automated or delegated or shoved aside. So they capture mindshare -- and time.

This week I have had two other admin-related items on my to-do list. First is an all-day faculty retreat my department is having later this week. The faculty actually chose to get together for what is in effect an extended meeting, to discuss the sort of issues that can't be discussed very easily during periodic meetings during the semester, which are both too short for deep discussion and too much dominated by short-term demands and deadlines. As strange as it sounds, I am looking forward to the opportunity to talk with my colleagues about the future of our department and about some concrete next actions we can take to move in the desired direction. There is always a chance that retreats like this can fall flat, and I bear some responsibility in trying to avoid that outcome, but as a group I think we can chart a strong course. One good side effect is that we will go off campus for a day and get away from the same old buildings and rooms that will fill our senses for much of the next sixteen weeks.

Second is the dean's announcement of my third-year review. Department heads here are reviewed periodically, typically every five years. I came into this position after a couple of less-than-ideal experiences for most of the faculty, so I am on a 3-year term. This will be similar to the traditional end-of-the-term student evaluations, only done by faculty of an administrator. In some ways, faculty can be much sharper critics than students. They have a lot of experience and a lot of expectations about how a department should be run. They are less likely to "be polite" out of habits learned as a child. I've been a faculty member and do recall how picky I was at times. And this evaluation will drag out for longer than a few minutes at the end of one class period, so I have many opportunities to take a big risk inadvertently. I'm not likely to pander, though; that's not my style.

I'm not all that worried. The summative part of the evaluation -- the part that judges how well I have done the job I'm assigned to do -- is an essential part of the dean determining whether he would like for me to continue. While it's rarely fun to receive criticism, it's part of life. I care what the faculty think about my performance so far, flawed as we all know it's been. Their feedback will play a large role in my determining whether I would like for me to continue in this capacity. The formative part of the evaluation -- the part that gives me feedback on how I can do my job better -- is actually something I look forward to. Participating in writers' workshops at PLoP long ago helped me to appreciate the value of suggestions for improvement. Sometimes they merely confirm what we already suspect, and that is valuable. Other times they communicate a possible incremental improvement, and that is valuable. At other times still they open doors that we did not even know were available, and that is really valuable.

I just hope that this isn't the sort of finding that comes out of the evaluation. Though I suppose that that would be valuable in its own way!

Over on one of the mailing lists I browse -- maverick software development -- there has been a lot of talk about how a lack of trust is one of the primary dysfunctions of teams. The discussion started as a discussion of Patrick Lencioni's The Five Dysfunctions of a Team but has taken on its own life based on the experiences of the members of the list.

One writer there made the bold claim that all team dysfunctions are rooted in a lack of trust. Others, such as fear of conflict and lack of commitment to shared goals, grow solely from a lack of trust among team members and leaders. This is, in fact, what Lencioni claims in his book, that a lack of trust creates an environment in which people fear conflict, which ensures a lack of commitment and ultimately an avoidance of accountability, ending in an inattention to the results produced by the team.

The writer who made this claim asked list members for specific counterexamples. I don't know if I can do that, but I will say that it's amazing what a lack of confidence can do to an individual's outlook and performance, and ultimately on his or her ability to contribute positively as a team member.

When a person lacks confidence in his ability, he will be inclined to interpret every contingent signal in a different way than it was intended. This interpretation is often extreme, and very often wrong. This creates an impediment to performance and to interaction.

I see it in students all the time. A lack of confidence makes it hard to learn! If I don't trust what I know or can do, then every new idea looks scary. How can I understand this if I don't understand the more fundamental material? I don't want to ask this question, because the teacher, or my classmates, will see how little I know. There's no sense in trying this; I'll just fail.

This is, I think a problem in CS classes between female and male students. Male students seem more likely than females to bluff their way through a course, pretending they understand something more deeply than they do. This gives everyone a distorted image of the overall understanding of the class, and leaves many female students thinking that they are alone in not "getting it". One of the best benefits of teaching a CS class via discussion rather than lecture is that over time the bluffers are eventually outed by the facts. I still recall one of our female students telling me in the middle of one of my courses taught in this way that she finally saw that no one else had any better grasp on the material than she did and that, all things considered, she was doing pretty well. Yes!

I see the effects of lack of confidence in my faculty colleagues, too. This usually shows up in a narrow context, where the person doesn't know a particular area of computing very well, or lacks experience in a certain forum, and as a result shies away from interacting in venues that rely on this topic. I also see this spill over into other interactions, where a lack of confidence in one area sets the tone for fear of conflict (which might expose an ignorance) and disengagement from the team.

I see it in myself, as instructor on some occasions and as a faculty member on others. Whenever possible I use a lack of confidence in my understanding of a topic as a spur to learn more and get better. But in the rush of days this ideal outlook often falls victim to rapidly receding minutes.

A personal lack of confidence has been most salient to me in my role as a department head. This was a position for which I had received no direct training, and grousing about the performance of other heads offers only the flimsiest foundation for doing a better job. I've been sensitized to nearly every interaction I have. Was that a slight, or standard operating procedure? Should I worry that my colleague is displeased with something I've done, or was that just healthy feedback? Am I doing a good enough job, or are the faculty simply tolerating me? As in so many other contexts, these thoughts snowball until they are large enough to blot everything else out of one's sight.

The claimant on the mailing list might say that trust is the real issue here. If the student trusts his teacher, or the faculty member trusts his teammates, or the department head trusts his faculty, either they would not lack confidence or would not let it affect their reactions. But that is precisely the point: they are reactions, from deep within. I think we feel our lack of confidence prior to processing the emotion and acting on trust. Lack of confidence is probably not more fundamental than lack of trust, but I think they are often orthogonal to one another.

How does one get over a lack of confidence? The simplest way is to learn what we need to know, to improve our skills. In the mean time, a positive attitude -- perhaps enabled by a sense of trust in our teammates and situation -- can do wonders. Institutionally, we can have, or work to get, support from above. A faculty member who trusts that she has room to grow in the presence of her colleagues and head, or a new department who trusts that he has room to grow in the presence of his dean, will be able to survive a lack of confidence while in the process of learning. I've seen new deans and heads cultivate that sort of trust by acting cautiously at the outset of their tenure, so as not to lose trust before the relationship is on firm ground.

In the context of software development, the set of tasks for which someone is responsible is often more crisply delineated than the set of tasks for a student or manager. In one way, that is good news. If your lack of confidence stems from not knowing how Spring or continuation passing style works, you can learn it! But it's not too simple, as there are time constraints and team relationships to navigate along the way.

Ultimately, a mindset of detachment is perhaps the best tool a person who lacks confidence can have. Unfortunately, I do not think that detachment and lack of confidence are as common a package as we might hope. Fortunately, one can cultivate a sense of detachment over time, which makes dealing with recurring doubts about one's capabilities easier to manage over time.

If only it were as easy to do these things as it is to say them!

I felt my agile tendencies come through yesterday.

First of all, let me say that by and large I am a rule follower. If a rule exists, I like for it to be applied, and applied consistently. Because I tend to follow rules without much question, even when the rule is inconvenient, it often disturbs me to learn that someone else has gotten out of the rule, either because they asked for an exception or because the relevant authority chose not to enforce the rule when it was skirted. This tendency is almost certainly a direct result of my upbringing. That said, I also know that some rules simply get in the way of getting things done.

Now for a story. Several years ago, we had a particular student in our undergraduate program. His work habits weren't very good, and his grades showed that. Before finishing his coursework, he left school and got a job. Fast forward a few years. Perhaps the student has grown up, but whatever the reason he is ready to finish his degree. He comes back to school part time and does well. He completes the coursework for his degree but comes up a bit short of the graduation requirements, due to the grades he earned during his first stint as a student. (The rule in question is rather picayune, but, hey ,it was written by faculty.)

The students asks if the department will consider waiving the rule in question. His request doesn't seem like some students' requests, which are often demands masquerading as questions, or which presume that the department really should say yes. This request seems sincere and not to presume that the department owes him anything. If we say no, he will re-take another course in the fall and try to satisfy the requirement. However, a waiver would enable him to move on professionally with a sense of closure.

Now, I am a rule follower, but... A colleague expressed well how I felt about this case: There is reason that we have this rule, but this case isn't that reason.

Part of my job is to hear and decide on such requests, but I prefer not to make such decisions without input from the whole faculty. So I make it a practice to poll faculty whenever new requests come in. The purpose isn't to take a vote that decides for me but rather to get a sense of what the group thinks. I get to hear pros and cons, maybe learn to think about the request in a way I hadn't considered before. I still have to make the decision, but I do so in a state of greater knowledge -- and a state of transparency. I'm also willing to bow to a consensus that differs from my instinct, unless there is a really good reason not to.

Faculty responses rolled in, without a consensus. More agreed with the idea of granting the request than disagreed, and a few offered suggestions for resolving the issue in another way. One person suggested that we should not waive the requirement without having a much more detailed policy in place. The more detailed policy would address the many dimensions of the case. His proposal was quite complete and well thought out. But it seemed like overkill.

This is a one-off case. We haven't had a case like this in my memory, and I don't expect that we'll have many like it in the future. Perhaps students don't ask for this kind of waiver because they don't expect it to be granted, but I think it's simpler than that: there aren't many students in this situation. It seems unnecessary and perhaps even detrimental for us to specify rules that govern all possible combinations of features when we don't know the specifics of future cases yet -- and may never face them at all. In the realm of the policy, this feels like a prototypical case of YAGNI. If we see a second case (soon), we will at least have reason to believe that the effort designing a detailed exception policy will be worth it for both faculty and students. There is one other fact that makes this increasingly unlikely as time passes: the particular set of requirements under discussion is no longer in effect, and applies only to students who began their CS majors under an older catalog that has been superseded. In any case, I'd like to give us the opportunity to learn from the next request before we try to get a detailed policy just right.

I do like to create policy where it is useful, such as for recurring decisions and for decisions that involve well-understood criteria. An example of this sort of policy is a set of guidelines for awarding a scholarship each year. I also think policy helps when it eliminate ambiguity that makes peoples' lives harder. An example here is a set of guidelines for faculty applying for and being awarded a course release for scholarly work. Without such a policy, the process looks like a free-for-all and is prone to unfairness, or appearance of the same; the result would be an inefficient market of projects that would hurt the faculty's collective work.

Otherwise, I think that policy works best when it reflects practice, rather than prescribing practice. This reminds me of a discussion that America's founding fathers had in creating the U.S. Constitution, which I mentioned in an earlier entry on Ken Alder's The Measure of All Things.

Ultimately, I trust my judgment and the judgment of my colleagues. In situations where I don't think we know enough to define good rules, I'd rather encourage a conversation that helps us reach a reasonable decision in light of current facts. When the conversation turns from giving value to wasting time, then a policy is in order. To me that is better at forecasting a policy for experiences we've not had and then facing the prospect of tinkering at its edges to get it right later. That creates just the sort of uncertainty, both in the folks applying the policy and in the folks to whom the policy applies, that a good policy should eliminate.

Trusting judgment means trusting people. I'm comfortable with that, even as a law-and-order kind of guy.

Last night my wife and I went to see a presentation by Ken Blanchard, author of many bestselling books on leadership, starting with The One Minute Manager. I previously blogged on his Leadership and the One-Minute Manager, and I very much enjoyed his Raving Fans. His talk was as good as advertised, full of great stories that made memorable a focused message: if you wish to excel, people and energy matter.

If you have a chance to hear Blanchard speak, I encourage you to do so, with one small caveat. If you are averse to spiritual talk of any sort or prefer your professional talks not to mention God even in passing, then you may be turned off. I thought he did a pretty good job keeping faith out of the talk and focusing on how to lead and why. Certainly the books of his on management and leadership that I've read stay on topic, though I can't speak to his latest book. If you can look past an occasional bit of spirit talk, then Blanchard can probably psyche you up to be a better leader. And you are a leader if you see any part of your life to be about influencing others, whether you have an organizational role as leader or not. Teachers fit the definition, and I think that agile software developers do, too.

I won't try to give a full accounting of the talk. You would be better served by reading Blanchard's books, which tend to be slim, fast reads. Here are a few takeaway points that seem applicable to my roles as software developer, teacher, and head of a university CS department:

• The computer and the human mind share at least one similarity: neither know the difference between the truth and what we tell it. You can use this fact to help you change how you think by giving yourself the right sort of input.

• You don't beat your competition with good product. Without that, you aren't in the game. You don't even beat your competition with a lower price. Without a fair price, you won't even be in the game. You beat your competition with "moments of truth". Blanchard didn't define that phrase, instead illustrating it with stories. My take is that a moment of truth is a moment when your customer senses something bigger than a transaction, a moment when value exceeds cost and expectation.

• Separate listening from deciding.

• When you make the transition from vision to implementation, the hierarchy of the organization must be inverted: the leaders become servants, and the customers become the focus.

• Servant leaders believe their positions are on loan. They are leading not to gain power or treasure, but to be helpful. For this reason, they love feedback; they look at feedback as a gift.

• Your next interaction with a client/student/parent/prospective student or donor may be your last.

Right now my thoughts are on moments of truth. What are the moments of truth that my students experience? My faculty? My external customers?

The end of our academic year has begun. The first task I face this time of year is reviewing activity reports submitted by faculty to document their teaching, research, and service activities since last May. The proximate cause of my reading this reports is that I must complete a salary worksheet for the Dean. The worksheet shows each faculty member's current salary, plus contractually mandated raises for next year. My contribution is a single entry for each person: a "merit adjustment".

I think that Eric Sink has expressed how I feel about this task as well as I could, and certainly more colorfully:

For most people, the touchiest and most sensitive topics are money and sex. I'm not expected to decide how often everybody gets laid. Why do I have to decide how much everybody gets paid?"

The academic world is a bit different than the ISV world in which Eric lives. Once a faculty member earns tenure at the time of promotion to associate professor, these annual reviews have little to do with whether or not a faculty member will have a job next year. At some universities, department heads and deans may have access to a larger pool of money for merit pay, but here faculty salary increases are driven more by across-the-board money than by merit. And in the end, I think salary is a relatively small part of why most faculty members are at a university, or even a particular university.

So. My discretion has relatively little effect on faculty members' salaries, but I still feel funny exercising it. Allocation decisions are inherently subjective. Weighing contributions across the teaching, research, and service categories are difficult, and sometimes weighing contributions within the categories is no easier. I am a strong believer in recognizing differences, but that is easier said than done.

The task is complicated by an interesting effect I've noticed over the last fifteen years. When the pool of money is small, it has little use as an incentive, even for folks who may be motivated in this way. But even then it has powerful possibilities as a demotivator. The effect of a $0 in that slot, or a token value that is emotionally equivalent to a $0, is remarkable -- and sad. So, while the absolute effect of my salary decisions are quite small, but their relative effect can be much larger.

I don't have any great wisdom or insight into the process yet. In fact, I'm pretty sure that I can improve upon what I've done the last two years. Eric Sink's article does a nice job exploring the space and putting me into the right frame of mind for doing the task (with appropriate context-specific modifications to all the details, of course). If I remain head for much longer, this is one area that I would like to think harder about.

It occurred to me recently one thing that makes administrative work different from my previous kinds of work, something that accounts for an occasional dissatisfaction that I never used to feel as a matter of course.

In my administrative role, I can often work long and hard without producing anything.

It's not that I don't do anything as department head. It's just that the work doesn't always result in a product, something tangible, something complete that one can look to and say, "I made that." Much of a head's work is about relationships, interaction, and one-one interaction. These are all valuable outcomes, and they may result in something tangible down the road. Meeting with students, parents of prospective students, industry partners, or prospective donors all may result in something tangible -- eventually. And the payoff -- say, from a donor -- can be quite tangible, quite sizable! But in the meantime, I sometimes feel like, "What did I accomplish today?"

This realization struck me a week or so back when I finished producing the inaugural issue of my department's new newsletter. I wrote nearly all of the content, arranged the rest, and did all of the image preparation and document layout. When I got done, I felt that sense one gets from making something.

I get that feeling when I write software. I think that one of the big wins from small, frequent releases is the shot of adrenaline that it gives the developers. We rarely talk about this advantage, instead speaking of the value of the releases in terms of customer feedback and quality. But the buzz that we developers feel in producing a whole something, even if it's a small whole, probably contributes more than we realize to motivation and enjoyment. That's good for the developers, and for the customer, too.

I get that feeling when I write code and a lesson for teaching a class, too. The face-to-face delivery creates its own buzz.

This makes me wonder how students feel about frequent release dates, or small, frequent homework assignments. I often use this approach in my courses, but again more for "customer-side" and quality reasons. Maybe students feel good producing something, making tangible progress, every week or so? Or does the competing stress of several other courses, work, and life create an overload? Even if students prefer this style, it does create a new force to be addressed: small frequent failures must be horribly disheartening. I need to be sure that students feel challenge and success.

Sheepishly, I must admit that I've never asked my students how they feel about this. I will next week. If you want to share your thoughts, please do.

Today I am reminded to put a variant of this pattern into practice:

The old-fashioned idea (my door is always open; when you want to talk, c'mon in) was supposed to give people down the line access to you and your ears. The idea was that folks from layers below you would come and clue you in on what was really happening.

I don't think that ever worked for most of us. Most folks didn't have the courage to come in, so we only learned what was on the minds of the plucky few. We were in our environment, not theirs. We couldn't verify what we were hearing by looking, touching, and listening in the first person. And we got fat from all that sitting.

I ran into this quote in Jason Yip's post Instead of opening the door, walk through it. Jason is seconding an important idea: that an open door policy isn't enough, because it leaves the burden for engaging in communication on others -- and there are reasons that these other folks may not engage, or want to.

This idea applies in the working-world relationship between supervisors and their employees, but it also applies to the relationship between a service provider and its customers. This includes software developers and their customers. If we as software developers sit in a lab, even with our door open, our customer may never come in to tell us what they need. They may be afraid to bother us; they may not know what they need. Agile approaches seek to reduce the communication gap between developers and customers, sometimes to the point of putting them together in a big room. And these approaches encourage developers to engage the customer in frequent communication in a variety of ways, from working together on requirements and acceptance to releasing working software for customer use as often as possible.

As someone who is sitting in a classroom with another professor and a group of grad students just now, I can tell you that this idea applies to teachers and students. Two years ago tomorrow, I wrote about my open office hours -- they usually leave me lonely like the Maytag Repairman. Learning works best when the instructor engages the student -- in the classroom and in the hallway, in the student union, on the sidewalk, and at the ballgame. Often, students yearn to be engaged, and learning is waiting to happen. It may not happen today, in small talk about the game, but at some later time. But that later time may well depend on the relationship built up by lots of small talk before. And sometimes the learning happens right there on the sidewalk, when the students feel able to ask their data structures question out among the trees!

But above, I said that today reminded me of a variant of this pattern... Beginning Monday and culminating today, I was fortunate to have a member of my department engage me in conversation, to question a decision I had made. Hurray! The open door (and open e-mail box) worked. We have had a very good discussion by e-mail today, reaching a resolution. But I cannot leave our resolution sitting in my mail archive. I have to get up off my seat, walk through the door, and ensure that the discussion has left my colleague satisfied, in good standing with me. I'm almost certain it has, as I have a long history with this person as well as a lot of history doing e-mail.

But I have two reasons to walk through the door and engage now. First, my experience with e-mail tells me that sometimes I am wrong, and it is almost always worth confirming conclusions face-to-face. If I were "just" faculty, I might be willing to wait until my next encounter with this colleague to do the face-to-face. My second reason is that I am department head these days. This places a burden on communication, due to the real and perceived differences in power that permeate my relationships with colleagues. The power differential means that I have to take extra care to ensure that interactions, whether face to face or by e-mail, are building our relationship and not eroding it. Still being relatively new to this management business, it still feels odd that I have to be careful in this way. These folks are my colleagues, my friends! But as I came to realize pretty quickly, moving into the Big Office Downstairs changes things, whatever we may hope. The best way to inoculate ourselves from the bad effects of the new distance? Opening the door and walking through it.

Oh, and this applies to the relationship between teachers and students, too. I understand that as an advisor to my grad students, having been a grad student whose advisor encouraged healthy and direct communication. But I see it in my relationship with undergraduates, too, even in the classroom. A little care tending one-on-one and one-on-many relationships goes a long way.

(And looking back at that old post about the Friends connection, I sometimes wonder if any of my colleagues has a good Boss Man Wallingford impression yet. More likely, one of my students does!)

... to the Sixth

My dad turned 64 yesterday. That's a nice round number in the computing world, though he might not appreciate me pointing that out. It's hard for me to imagine him, or me, any different than we were when I was a little boy growing up at home. It's also hard for me to imagine that someday soon my daughter might be thinking the same about the two of us. Perhaps I need a bigger imagination.

... Months

This is the time of the academic year when folks seeking jobs at other institutions, in particular administrative promotions, begin to learn of their good fortune and to plan to depart. Several of my colleagues at the university will be moving on to new challenges after this academic year.

In a meeting this week, one such colleague said something that needed to be said, but which most people wouldn't say. It was on one of those topics that seems off limits, for political or personal reasons, and so it usually just hangs in the air like Muzak.

Upon hearing the statement, another colleague joked, "Two months. You have two months to speak the truth. Two months to be a truth teller."

It occurred to me then that this must be quite a liberating feeling -- to be able to speak truths that otherwise will go unspoken. Almost immediately on the heels of this thought, it occurred to me just how sad it is that such truths go unspoken. And that I am also unwilling to speak them. Perhaps I need greater courage, or more skill.

Heard on my drive to SIGCSE today:

These experiences have caused him to think very hard about what he is doing and where he is going. And the result of all this thinking is that he now understands he doesn't know what he is doing or where he is going.

This quote is about Ray Porter, a character in Steve Martin's novella Shopgirl, which I listened on my drive to SIGCSE today. While I am in most ways nothing at all like the divorced, 50-something Porter, I can certainly appreciate his sudden need to think very hard and his sudden realization that he is essentially clueless. Over the course of my career, I had grown to feel comfortable in my roles as an academic, as teacher and scholar. Which I switched into the Big Office Downstairs, I just assumed that things would proceed as usual.

But after a year and a half as department head, I experience occasional moments of "midterm crisis", in which I think that I don't really know what I'm doing or where I'm going. I often have a pretty good 50,000-foot view of what I want, but down in the trenches I usually feel a little disoriented. With experience, things have gotten better, but a year filled with academic program review, two time-consuming searches, and a curriculum revision have sapped my reservoirs of creativity and energy.

At least now I think I understand that I don't know what I am doing or where I am going. You know what they say about acceptance being the first step toward recovery!

By the way, I do recommend Shopgirl. I have read the book and then listened to it several times on tape while driving to PLoPs, SIGCSEs, and ICFPs. For some reason, Martin's writing holds my attention, and the story is sweet enough that I can get over constantly wondering, "Why does she put up with this?" Martin is a surprisingly good writer; though he is never going to win a Nobel Prize, he can spin a decent short yarn. My first exposure to his literary work was Picasso at the Lapin Agile, a stage play about a fantasy meeting between Picasso and Einstein at a Paris bar around the turn of the century.

Oh, and as for Shopgirl -- I haven't seen the movie yet! I'm glad that I read the book first, and then heard it read before seeing the film version. Just knowing that Martin and the glorious Clair Danes play the leading roles has changed my experience of the book...

The people always know what's wrong
... but given the wrong leadership,
they won't ever talk to you about it.

Jason Yip

A month or so ago, I wrote about my involvement in a search for a college sysadmin. That search proceeds slowly. In the mean time, the second search I mentioned -- for an Assistant Vice President of Information Technology of the university -- has wrapped up with a disappointing result: a closed search. This means that the university decided not to hire any of the candidates in our applicant pool. If you have ever served on a search committee and put in the many hours required to do a good job, only to have it closed at the end, you know how disappointing this can be.

Why close the search? The campus community couldn't get 100% behind any of the candidates. The search exposed some of the rifts on campus, within the IT community and between that community and the arms of the university it serves. The administration felt it better to put our house in better order before trying to bring someone in from the outside to lead the organization forward.

Any time a search is closed, there is a sense of disappointment at the time spent for no tangible gain. In this case, though, that sense is offset somewhat by a sense of learning. This search was a discovery process for the campus and new president, and that is valuable in its own right, if intangible. But there is a second sort of disappointment, too. Many people on campus felt that one of the candidate was just what the university needed -- a leader with a strong technical background and a strong vision of the future of information technology. Thus the lament "a missed opportunity".

Personally, I learned a lot about university politics by participating in this search, as well as developing a better sense of what sort of person one must seek in a university CIO. This person doesn't need deep technical skills because he or she will be doing technology hands-on, but because he or she must have a deep enough understanding of technology to evaluate ideas, set priorities, select and mentor a staff, and educate administration on the needs, opportunities, and threats that confront the university. Of course, deep technical knowledge isn't enough, as communication can often dominate the technical in most non-technical peoples' minds. At least in the immediate moment, that is; when the technology choices are bad, suddenly the technical side of the leader matters a lot.

I shouldn't say much about the details of the search publicly, but let's leave it at this: The quip quoted above from Jason Yip lit up my screen when I first read it, and because of this search. When people know what's wrong but can't or won't tell you, you have a big problem.

Striving for excellence leaves one prone to occasional or even frequent disappointment. Back to the drawing board.

Today, I've been sitting all day (except for class) in a seminar put on by my university's Office of Compliance and Equity Management, called "Preventing Employee Issues". The presenter is a lawyer who defends organizations against lawsuits from employees on grounds of discrimination, harassment, unlawful termination, medical difficulties, and so on. The idea is that we in attendance might learn how to do our jobs more effectively, both from the perspective of our employer and from the perspective of our employees. The thought of faculty in my department as my "employees" makes me chuckle almost as much as it would make them, but the legal effect is the same.

This is the sort of event that I would never have been asked to attend as a faculty member. And so this is the sort of post I would never written before, and the sort that my friend Joe could probably do without! While I'd rather have been writing code, I have found the seminar quite interesting. I've always enjoyed listening to lawyers talk about the law, and this would have been a bit of fun even if it didn't apply more directly to my current work duties.

I'm surprised at just how much of the advice we've received is simply good practice for how any person should live and treat others. It's almost a re-telling of Fulghum's dicta:

• Communicate clearly. Tell people what you expect. Give specific, concrete feedback.
• Be consistent. Treat everyone the same way. Apply rules the same way across similar situations.
• Don't make promises you can't keep.
• Do your homework. Do due diligence when you hire, evaluate, and terminate employees.
• Treat people with respect.
• Be accountable. Take responsibility for your actions. Admit mistakes and correct them.
• Don't retaliate.
• Follow the rules. Set a good example. Model expected behavior.

These seem like good behaviors for most any part of one's life. They remain important when you are a manager, whether at a university or in a software house. The lawyer's essential point is that they become even more important for supervisors and organizations, because they create environments in which employees can work reasonably and thus in which employers have met their legal obligations to employees.

One stream of advice running throughout the presentation is: Document. Document everything. Document, document, document. Documentation creates the historical record that supports the actions a manager has taken, should those actions ever be called into question. Indeed, even if you prefer not to follow the "good behavior" guidelines above for moral or ethical reasons, you might decide to do so cynically because they create a living documentation that you try to create a reasonable working environment. This is one situation where the law, both statute and case law, create a "market" in which good behavior has value beyond a person's own belief system.

The biggest thing I learned is this regard is the importance of documentation even when you don't think you need it. For example, when I became a department head, I became supervisor to the department secretary, whom I consider to be meeting the expectations of her position. My university recommends but does not require that I do an annual performance evaluation. The secretary and I discussed it, and we figured that there wasn't much of a need to go through all of the paperwork that an annual performance evaluation. But now I realize that I do need to do the evaluation annually -- in case I ever need to in the future. Suppose that our current secretary leaves and we hire a new one. The new person exhibits a pattern of performance problems, so I decide to do the annual performance evaluation to help the secretary improve and to begin to document the problems. The very fact that I did not evaluate the previous secretary could come back to haunt me, because the new employee could allege that I was treating him or unfairly just by evaluating them! This could be spun as a form of harassment. This may seem like a stretch, but we know how the law can work sometimes, especially when a jury comes into play. The safest thing for me to do is "do the right thing" and evaluate my current secretary, to set the right example and to create a track record of doing so.

I'm trying to think of a way in which I can relate this to a principle of software design or programming; it seems like the sort of idea that bridges many kinds of activity. Maybe this is similar writing tests for code that you "know can't break", because one of these days it might, or following the practices of a methodology such as XP even when they seem like overkill. These have the sense of "do it anyway" but perhaps not the same sense of "historical record". Oh, well.

Another stream is that there are a lot of laws that matter. FERPA, OSHA, and ERISA are just the beginning. I'm glad that my university should and does provide support to us front-line managers. One benefit of this sort of seminar is learning what kinds of situations trigger issues that need to be addressed.

Perhaps the most immediate result of attending the seminar is to have a small sense of unease about my recent roles on a couple of search committees. Have we done our due diligence? Has the university done what the committee didn't? Yikes. I'd better be sure that we know what we need to know about our candidates.

Indeed, for those of you with a strong, charismatic personality, it is worthwhile to consider the idea that charisma can be as much a liability as an asset. Your strength of personality can sow the seeds of problems, when people filter the brutal facts from you. You can overcome the liabilities of having charisma, but it does require conscious attention.

-- James Collins, Good to Great, page 73

I may have to worry about folks not telling me the brutal facts, but it won't be due to the force of my charisma.

Good to Great offers folks like me other assurances as well. Helping a group to transform itself from good to great is usually more a matter of working with the right people, listening to the facts, and discipline than it does with charisma or vision.

In my last post, I commented on academic searches. One of the articles I linked to gives some pretty good advice to prospective faculty applying for positions at smaller schools. They aren't fallback positions; they are different kinds of positions altogether. In the spirit of that post, I thought I'd share some of my recent experiences with other kinds of academic search.

This year, I am involved in a couple of high-profile searches on my campus, both of which matter very much to the faculty in my department. The first is for the chief sysadmin in the College of Natural Sciences, and the second is for the Assistant Vice President of information technology for the university. Both matter to us for the same reasons, though in different doses. In this post, I'll talk a bit about the sysadmin search.

Being a medium-sized "teaching university", we do not maintain and manage most of the basic computational resources that we use on a day-to-day basis. In the early years, before the rest of the college and university were deeply into technology, we did. But as our needs grew, and as other departments came to need computer labs and e-mail and the web, the college took on more and more of the systems burden. These days, the college sysadmin team implements and supports the network and server infrastructure for the college, manages the general college labs that our students use, and supports CS faculty labs and computer equipment. Not having the research money to maintain all of our department resources, this has worked out well enough for the last decade or so, with only occasional control issues arising. (One current one involves our web server, which for the last few weeks has been rewriting URLs in such a way as to break my blog permalinks.)

So, the college's lead sysadmin has a challenging job to do. There are a lot of technical tasks to do, plus managing student staff and providing user support. The diversity of issues that arise in the college is yet another challenge, ranging from a CS department, a math department, and industrial technology department, and the traditional natural sciences. In some ways, CS demands less personal support from the college, but we do have specific technical needs, sometimes outliers from the rest of the crowd, that we rely heavily on.

I'm chairing the college sysadmin search. In the process, I've come to appreciate just how hard it is to find candidates with sufficient technical skills and experience, sufficient "people" skills to work with a diverse audience of users, and sufficient managerial experience. Add to that a salary that is almost certainly lower than market value in private industry, and the task is even tougher. Even with these challenges, we have a promising pool of finalists and hope to begin on-campus interviews soon.

Here are some things that I've learned in the last few years and am trying to put into practice for this search:

• Technical skills matter. Period. You can't hire a sysadmin with marginal or insufficient skills and hope that they can grow into the job. technology changes so fast that most such folks never have the chance to catch up. They just fall farther and farther behind. Strong Unix and Windows background; experience setting up and configuring servers; broad experience with software -- all are essential. Don't settle for less lightly.
• Communication skills matter. A college-level sysadmin must be able to work with advanced and novice users alike, train students, and mentor full-time assistants. They also have to be able to explain technical choices and trends to department heads and deans, so that these administrators can make informed decisions about equipment and budgets. This latter is more important than many folks realize. Being a sysadmin at this level isn't just about hacking Ruby scripts to automate mechanical tasks; it also contains an element of helping others set vision.
• But do not emphasize communication skills to the detriment of technical skills. Of course, you can't emphasize technical skills to the detriment of communication skills either, but at my university and in our current environment, favoring tech skills to the expense of communication skills just hasn't been a problem. Folks are more inclined to go with someone who has people skills and is agreeable, even if they lack the skills necessary to do the job well. Don't do it. You'll always pay in the long run.
• On the search process itself: Fairness matters. Once you have published a job description, stick to it. It can be really tempting to say "I like this candidate's application..." and then start looking away from the ways in which the candidate falls short of the requirements and preferences that you had defined for the position at the outset of the search. This is a sure way to let your hidden biases get in the way of hiring the right candidate. The job description is your specification. If it is well thought out, you're almost certainly better off letting it guide the committee's actions.

  But I think it's also wrong to skirt the job description for another reason: It's unfair to other candidates who were honest about not meeting the requirements of the position and so didn't apply at all. If you are willing to consider folks in your pool who do not meet the specs, then you might really want to consider some of those who self-selected out of the pool through a sense of honor. And then there is the practical problem of having to relax the requirements fairly for all of the applicants in the pool, not just the one who caught your attention for some other reason.

  Maybe I'm too strict on this matter, but this sort of fairness is a sticky point for me. I try to manage my classroom similarly. If I feel a need to repeatedly relax a particular rule, then I probably need to change the rule, not relax it. Otherwise, exceptions tend to favor that certain group of students who are bold or needy enough to ask for exceptions, at the expense of the students who live by the rules quietly. (Can you guess which sort of student I most likely was?)

• Leadership matters. Once a sysadmin can put ship into seaworthy condition and have things running as they should, it's awfully nice to have someone in place who can think bigger thoughts and help guide the department or college. This isn't crucial, as faculty and other administrators are already charged with this task, but why waste the expertise that your sysadmin brings to the table, especially if they are inclined to help lead? Allowing them to do so helps the college and lets the sysadmin grow professionally.

We'll see how successful the college is at finding the right sort of person, with what bit of influence I have been able to exert.

Physics blogger Chad Orzel has written a couple of articles on the process of searching for new faculty, including his recent tips for applicants to schools like his. I haven't been part of a CS faculty search in a couple of years, after what seemed an interminable decade of trying and failing to feel an open slot or two. Our last two searches resulted in three hires, and we couldn't be much happier with the results. Our department is much better now than it was before.

I attribute our success as much to good fortune as to any particular actions we took. When I first became involved in job searches, I thought that a good search committee could reliably produce a good result. Write the correct job description, do the right sort of applicant screening and reference checking, and interview the finalists in the correct way, and out would pop the Ideal Candidate. After years of trying to do the job better, I came to understand how naive I had been. The process of searching for and hiring a member of the faculty is inherently risky, and the best one can do is hope to hire a good person while avoiding any major disasters. It's much easier to watch for the red flags that indicate a higher-than-usual level of risk than it is to recognize the signals that ensure a winner, but even on that side of the equation the committee must have the the patience it needs not to rush ahead in the presence of red flags.

Faculty searches are tougher than most, because the outcomes on which success will be measured are forecasts based on a small set of data points from a world that is not all that representative of the world in which new faculty will operate. We do our best and then act on faith in a person. Sometimes we just guess wrong. When things don't turn out right, both the new faculty member and the hiring department have suffered a loss. The split may be amicable, but neither party is better as a result.

For some staff positions, I think a good search committee can deliver a good result with a much higher probability, if only because the parameters of the position are easier to delineate and evaluate. Besides, there usually isn't the messy specter of a tenure decision complicating most such hires. But there's still an element of risk involved.

As a department head, I've come to appreciate that another challenging kind of search is for administrators and staff who affect the longer-term strategies of the department. I'll write a bit about this kind of search next time.

Our dean is relatively new in his job, and one of the tasks he has been learning about is fundraising. It seems that this is one of the primary roles that deans and other to-level administrators have to fill in these days of falling state funding and rising costs.

This morning he gave his department heads a short excerpt from the book Asking: A 59-Minute Guide to Everything Board Members, Volunteers, and Staff Must Know to Secure the Gift. Despite the massive title, apparently each chapter of the book is but a few chapters, focused on a key lesson. The excerpt we received is on this kernel: Donors give to the magic of an idea. Donors don't give to you because you need money. Everybody needs money. Donors give because there is something you can do.

For some reason, this struck as a lesson I have learned over the last few years in a number of different forms, in a number of different contexts. I might summarize the pattern as "It's not about me." Donors don't give because I need; they give because I can do something, something that matters out there. In the realm of interpersonal communication, the hearer is the final determinant of what is communicated. Listeners don't hear what I say; they hear what they understand me to have said. The blog Creating Passionate Users often talks about selling how my book or software is about empowering my users -- not about me, or any of the technical things that matter to me. The same applies to teachers. While in an important sense my Programming Languages course is about the content we want students to learn, in a very practical sense the course is about my students: what they need and why, how they learn, and what motivates them. Attending only to my interests or to the antiseptic interests of the "curriculum" is a recipe for a course almost guaranteed not to succeed.

Let's try this on. "Students don't learn because you think they need something. They learn because there is something they can do with their new knowledge." They learn because the magic of an idea.

That sounds about right to me. Like any pattern taken too far in a new context, this one fails if I overreach, but it does a pretty good job of capturing a basic truth about teaching and learning. Given the many forms this idea seems to take in so many contexts, I think it is just the sort of thing we mean by a pattern.

Two comments from the human side of our world have caught my eye in the last little bit:

On needs, courage, and respect

Dale Emery relates these concepts concisely:

A big part of courage is remembering that my needs matter. A big part of respect is remembering that the other person's needs matter.

In many ways, it's easier for me to integrate the latter into my daily life than the former. I usually feel guilty for placing my needs too high in the pecking order. Perhaps I place too much concern on the risk of being self-centered. (And that probably because I already have that weakness!)

On badmouthing one's competitor

A lot of folks have linked to Tom Peters' article on "loving thine enemy", but my take on Peters' article best matches Jason Yip's take:

My take on this is that I don't want to be someone who badmouths other people for my own self-interest. And that's enough.

Well said. I'm certainly sympathetic to the pragmatists' philosophical stance, which would summarize Peters' position as saying that working to hurt your competitors "doesn't work". But one ought not need an economic or altruistic reason not to speak ill of others. It is simply wrong.

One of my colleagues occasionally comments that many of the folks in our department don't often practice in the rest of our professional lives what we preach in our areas of technical expertise. For example, in software engineering we often speak of the importance of gathering requirements, writing a complete specification, and then later testing our product to ensure that it meets the spec. But CS faculty are often reluctant to practice these ideas in the context of curriculum and departmental mission, which leads to a lack of motivation for tasks such as academic program review both on the side of specifying concrete department goals and concrete course competencies and on the side of measuring outcomes.

My colleague's observation is usually true. Expertise doesn't transfer very well across domains of practice; and, even when the mindset transfers, the practices and habits don't. It takes a lot of work to translate the mindset into the new habits we need in the new domain, and we have to watch out for pitfalls that let us convince ourselves that the new domain is so different that we can't practice what we preach.

Though my colleague has never made his observation to me when commenting on my performance, I know well that I am guilty. I strongly encourage the use of agile methods in software development, and I've even written in this space on how I have intended to "be agile" in how I approach my administrative duties. But as I look back over my first fifteen months as a department head, I see a path littered with good intentions leading to a very different place than I wanted to be.

I had hoped to write a retrospective of my first year in the Big Office by now, but I haven't yet -- in part because I don't feel I have synthesized much of an understanding of what I do yet, but also in part, I think, because I feel a bit ashamed of my weaknesses. I haven fallen woefully behind on several major projects, including ones that were centerpieces of my desire to become head. As I look back, I see many of the signature problems of big software projects falling behind. As Fred Brooks tells us in The Mythical Man-Month, how do disastrously late projects get that way? "One day at a time." When I fall farther behind, it is rarely because a major task preempts my time; most of the slippage in my schedule results from "termites" -- little interruptions, small distractions, and bad decisions made in the small.

I am agile in mindset, but not in practice. How can I change that? Go back to the basics: Define small tasks. Define "tests" that will help me know that I have made concrete progress. Release small deliverables frequently to the folks who depend on my work, especially the faculty.

I know what to do. Now it is time to get serious about new practices for the new tasks I tackle.

Academic departments at universities can sometimes be quite agile, introducing new courses and new approaches into curricula in response to feedback from students and the world. But, like large corporations and almost any organization that reaches a certain size, the modern university also tends to calcify certain processes to the point that they become almost useless. Academic program review is an example.

Every seven years, my university conducts an academic program review of each academic department, on a rolling schedule. My department was last reviewed in 1999, so we were on the schedule for Fall 2006. As a part of the review, the department conducts a self-study of each of its programs, reviewing curriculum, student outcomes, faculty, facilities and resources, budget and finance, and program strengths and weaknesses. Then a set of external auditors come to campus to conduct an independent review, informed by the self-study reports. Finally, the dean uses the results of the internal and external reviews to help the department plan for improvement and maintenance.

Periodically examining one's practice, gathering feedback from independent reviewers, and then feeding what you learn back into process improvement seems like a good idea, a natural way for an organization to monitor itself. So why don't faculty take to it enthusiastically? Instead, they dread it.

Any agile software developer knows one part of the answer. Waiting seven years to gather feedback and adjust course is simply a bad idea. Imagine how far off track a department can go in seven years!

Of course, it's not really that bad. To some extent, faculty, department head, and dean are all in a continual process of monitoring the state of the department and making changes. In the seven years since our last review, we have hired three faculty, changed department heads twice, launched two new majors, and moved into a new building. All of these changes resulted from collective discussion or managerial choice.

Part of the problem is documentation process that accompanies the review. Since returning from OOPSLA, I have spent much of my time encouraging faculty to find time to finish their work on the review and finding time myself to assemble and complete the reports for our undergraduate and graduate programs. None of us has a lot of unencumbered time to devote to such a big task, and the result is process thrashing and delays.

This is my first time leading a review (last time around I wrote a big part of the M.S. program self-study but had another department head to do the encouraging, assembling, and completing), and I think I've learned something about how to make this work better in the future. Most of my ideas are inspired by agile methods.

• Data collection and analysis should be an ongoing process. As department head, I am inundated with institutional data, and I have begun to seek out other data that we need to make good decisions. I need to make a standard part of my work week the assimilation of this data into a meaningful, "running total" that is the current snapshot of our department's state.

• Documentation should also be ongoing. Not the onerous over-documentatation required by university policy, but the sort of reporting that faculty and dean can use to make decisions. From these reports, assembling the self-study should be a straightforward matter.

• Whenever possible, our plans and actions should include "unit tests". These quantifiable metrics will help us know whether we have accomplished our goals. We academics are like anyone else in being content to make a decision and then assume that we are doing the right thing and that all is working out fine. That may work most of the time when we teach courses in our specialty areas for many years, but even then it is a dangerous attitude. In matters of programmatic and departmental direction, it really is a head-in-the-sand attitude.

• Talk to our stakeholders. We need to communicate as much as possible with our students, alumni, and corporate supporters, to find out what they need and how our programs fit into the world. We've always done that informally with our students, but we need to document the feedback we get. Our department has never had much of an alumni outreach effort, but we are doing more and more. I also plan this semester to form an advisory board of folks from outside the university to help us monitor our performance.

To be fair to the university and its policy, we are already charged with doing some of this by the university itself, in the form of a Student Outcomes Assessment plan. This plan should be monitoring student outcomes throughout their time on campus and then into their alumni years. Unfortunately our department -- and many others, I suspect -- have never taken these plans seriously. Some faculty view this process as an unnecessary bureaucratic burden, and others think that we are all too busy to do it right. I think that this means we need to develop a better plan, one in which data collection is manageable under supervision of instructors and staff and immediately useful in evaluating our progress. (Because many of us didn't take student outcomes assessment seriously when we wrote the plan, we wrote a plan that was unrealistic and aimed more at satisfying the committee charged with approving the plan than at satisfying our needs!)

There are practical reasons for doing some elements of program review every seven years. For example, getting on-campus feedback from good external reviewers is difficult. They are busy people, in demand, and bringing them to campus is costly. But an advisory board can provide a lighter-weight feedback more frequently.

Of course, who knows who will be our department head in 2013, so my learning may or may not have an effect on how we do our next academic program review. But I will proceed with some of these ideas now in an effort to help us improve as a group.

Our self-study reports were due today at 5 PM, and we haven't submitted them yet. You know what I'll be doing this weekend.

Today, my university installed its new president. The installation was high ceremony, with faculty dressed in full academic regalia, a distinguished platform committee, and an appearance by one of Iowa's U.S. senators, who is a UNI alumnus. (Alas, business on Capitol Hill changed his plans at the last minute and limited him to a video address.) As much as universities have changed in the last thousand years or so, we still hold onto some of our oldest traditions and ceremonies. That's a good thing, I think. It creates a sense of purpose and history, tying us to our forebears in the quest to understand the universe.

I am excited by our new president. He comes to us from a major research school, a sister institution with which my department has dealt recently. Everyone I've spoken to from his old university, whether staff or administrator, regular faculty to research superstar, has praised his intellect, his ability, and his character in the most glowing of terms. We need a leader of high intellect, ability, and character as we face the many changes that confront universities, especially public universities, these days.

President Allen's installation address gives those of us in the sciences reason to anticipate the future. He seems to understand clearly the role that science, math, and technology will play in the world in the coming century, and he seems to understand just as well that a comprehensive university such as ours must play an essential role in educating both capable citizens and professionals prepared to work in a technological world. And his vision takes in more than just the aims of education; he sees the importance of participating in developing our state's economy and to lead in areas where our strengths meet the greatest needs of the public. These include the training of capable teachers and -- perhaps surprising to folks who think of the Great Midwest as only a homogeneous population of old European ancestry -- the integration and development of modern immigrant communities.

I feel great hope that the new president of my medium-sized public institution in the heartland of America believes that we can and must become world leaders in the areas of our strengths. As he is fond of saying, good is the enemy of great, and we must ask and answer difficult questions in order to discern where we will excel -- and then carry out a plan to do so. Even greater is my hope in his belief that science, math, and technology are among the areas we must come to lead.

Now my department faces a big challenge. At what can we be great? What specialty can we develop that will be world class?

The first session of our department heads' retreat is on fundraising. When I became department head I did not think of fundraising as a part of the head's job. But in today's funding climate for universities, it is, even for a small, public university that doesn't have massive research infrastructure. As this passage from an article at Chronicle Careers begins,

It's not uncommon to hear administrators at public universities joke that their institutions once were "state supported," then became "state assisted" and now are merely "state located."

The loss of state support has had a substantial impact on academic programs, with universities often left scrambling to fill the gap. In light of those cutbacks, the role of fund raising is ever more important to the health and development of academic programs.

University foundations do this sort of fundraising, but increasingly the colleges and departments themselves are taking active roles in raising the dollars for their programs. And that makes a lot of sense, because departments and colleges are much closer to the needs and potential donors than foundation officers -- and we have the passion about our programs and needs.

Our foundation has a collegiate development officer for each college. This officer focuses on "major gifts", which here means gifts of at least $15K. This includes cash gifts and planned giving. The CDO's basic plan is to keep UNI on the radar of potential donors -- even of current donors who currently give small amounts, because many of those folks progress to bigger giving. In fact, that's where most major gifts come from; it's rare for someone who hasn't been involved before suddenly deciding to give a major gift.

What can departments do? We have two primary target audiences. One is corporate. Those who hire our students have a stake in our efforts. They are interested in the sort of labs and software tools our students use. They also want to build name recognition with potential employees.

The second is alumni. In terms of long-term giving, this is perhaps the more important focus. Here, we have some control over the personal element that underlies a strong fundraising effort. We need to keep in touch; let them know what their old profs are doing, what their old classmates are doing, and how the facilities and buildings are changing; and invite their ideas and feedback. Many alumni still feel a deep personal connection to one of their professors, or even to a secretary. What the department can do best is, like our CDO, stay on their radar. And many of our alumni want to be in our radar.

When we approach these audiences, seeking funds for certain purposes will be more successful, and more effective for the department, than others. Scholarships are a relatively easy sell. But we need to approach them strategically. We want breadth of support through the student body, to be sure that we help lots of different kinds of students, but we also want depth in certain areas (say, support for the best students, in order to raise the academic climate of the student body).

Another dimension of fundraising is the liquidity of the gift -- cash versus endowment. Like many universities, ours has a goal of increasing the number and size of our endowments. This is also a goal of mine, with the notion of having a company endow a laboratory, a computer classroom, or even a particular software platform. Rather than chasing dollars all the time to upgrade the computers in a lab, wouldn't it be wonderful to have an annuity keeping the lab fresh? We'd be able to devote our energies to other, more important items.

For us, any attempt to garner endowments will be most effective with corporate donors, at least for a while. We are a young department, at a university offering young CS majors. We separated as a department from Mathematics in 1992, and the math department began offering CS majors only in 1981. Many of our alumni who are old enough to be giving gifts big enough for endowments identify more with the Department of Mathematics than with computer science. Perhaps our most prominent alumnus, the CIO at a major financial services company, earned his degree in mathematics, with a "computer science emphasis", before UNI offered a CS degree. (Fortunately, he identifies himself as a CS guy!)

In truth, though we need a mix of cash gifts and endowments. The number of donors capable of making an endowment-sized gift is relatively small, and endowments grown from smaller gifts need time to mature. Furthermore, we need cash today to do things that need to be done now.

With alumni, this all translates back to relationships. Pay attention to the details -- for example, don't send mail o Mr. and Mrs. if one of the spouses has passed away. Send personal thank-yous to every donor -- even the donor who gives $5. Ultimately, don't think of people as potential donors; think of them as people. That sounds like trite marketing-speak, but it is the best way to succeed in raising funds -- and the best way to succeed in most other respects as well.

This week I've had the opportunity to meet with several colleagues from around my college, as part of some committee work I had volunteered for. This sort of extra work is often just that -- extra work -- but sometimes it is an opportunity to be reminded that I have some impressive colleagues. Sometimes, I even learn something new or am prompted to think about an idea that hadn't occurred to me before.

One of my colleagues spoke of how important it is to get the science faculty working more closely with one another at this time. He couched his ideas in historical terms. Science in the early 20th century was quite interdisciplinary, but as the disciplines matured within the dominant paradigms they became more and more specialized. The second half of the century was marked by great specialization, even with the various disciplines themselves. Computer science grew out of mathematics, largely, as a specialty, and over the course of the century it became quite specialized itself. Even within artificial intelligence, the area in which I did my research, became almost balkanized as a set of communities that didn't communicate much. But the sciences seem to have come back to an era of interdisciplinary work, and CS is participating in that, too. Bioinformatics, computational chemistry, physics students rediscovering computer programming for their own research -- all are indications that we have entered the new era, and CS is a fundamental player in helping scientists redefine what they do and how they do it.

Another colleague spoke eloquently of why we need to work hard to convince young people to enter the sciences at the university level. He said something to the effect that "Society does not need a lot of scientists, but the ones it does need, it needs very much -- and it needs them to be very good!" That really stuck with me. In an era when university funding may become tied to business performance, we have to be ready to argue the importance of departments with small numbers of majors, even if they aren't compensating with massive gen-ed credit hours.

Finally, a third colleague spoke of the "rhythm" of an administrator's professional life. Administrators often seek out their new positions because they have a set of skills well-suited to lead, or even a vision of where they want to help their colleagues go. But minutiae often dominate the daily life of the administrator. Opportunities to lead, to exercise vision, to think "big" come along as fleeting moments in the day. What a joy they are -- but you have to be alert, watching for them to arise, and then act with some intensity to make them fruitful.

For some reason, this reminded me of how sports and other competitive activities work. In particular, I recall a comment Justin Henin-Hardenne made at Wimbledon this year, after her semifinal win, I think. She spoke of how tennis is long string of mostly ordinary points, with an occasional moment of opportunity to change the direction of the match. She had won that day, she thought, because she had recognized and played those big points better than her opponent. I remember that feeling from playing tennis as a youth, usually on the losing end!, and from playing chess, where my results were sometimes better. And now, after a year as an administrator, I know what my colleague meant. But I'm not sure I had quite thought of it in these terms before.

Sometimes, you can learn something interesting when doing routine committee work. I guess I just have to be alert, watching for them to arise, and then act with some intensity to make them fruitful.

(And of course I'm not only an administrator... I'm having fun with my first week of CS1 and will write more as the week winds down and I have a chance to digest what I'm thinking.)

Now that the issue has been resolved, I can finally write on a topic I mentioned three weeks ago, my department's proposal to create a new major in Software Engineering. This is one of those persistent "interruptions" this summer that really was an important task in its own right. It also reminds us all that academic politics are a non-trivial exercise.

A couple of years ago, the faculty in my department decided to propose three new majors. One, bioinformatics, targeted an area of growing importance in which computing is an essential component. Graduate programs in bioinformatics were becoming common at this time, but few or no undergraduate programs existed. We figured that this major would attract a new audience of potential students and capitalize on the strong math and biology departments here. The other two proposals were extensions of the standard B.S. in Computer Science program we already offered: Software Engineering, and Networking and System Administration. These proposals targeted particular professional areas that our students pursue within our existing majors, giving them a little extra heft and their own identity. We figured that these majors would allow current CS students to choose a major that more directly matched their professional careers and hoped that they would attract students interested in these areas who might otherwise not attend our university.

Such "targeted majors" are becoming more common throughout the country, and we hoped to be in the vanguard. Personally, I'm not a big fan of "superset majors" like Software Engineering and Networking, because I think even our most professionally-oriented students are best served with a broad CS major that prepares them for a diverse and dynamic discipline. But I do understand their appeal to students and thus their utility as marketing tools. Add to this reports such as Iowa's Information Technology Strategic Roadmap, which recommends focused majors as tools for developing the state's base of IT workers, and such majors become even more attractive to the univer