Knowing and Doing

This morning on the exercise bike, I read a big chunk of Daniel Gross and Tyler Talk Talent, from the Conversations with Tyler series. The focus of this conversation is how to identify talent, as prelude to the release of their book on that topic.

The bit I've read so far has been like most Conversations with Tyler: interesting ideas with Cowen occasionally offering an offbeat idea seemingly for the sake of being offbeat. For example, if the person he is interviewing has read Shakespeare, he might say,

"Well, my hypothesis is that in Romeo and Juliet, Romeo and Juliet don't actually love each other at all. Does the play still make sense?" Just see what they have to say. It's a way of testing their second-order understanding of situations, diversity of characters.

This is a bit much for my taste, but the motivating idea behind talking to people about drama or literature is sound:

It's not something they can prepare for. They can't really fake it. If they don't understand the topic, well, you can switch to something else. But if you can't find anything they can understand, you figure, well, maybe they don't have that much depth or understanding of other people's characters.

It seems to me that this style of interviewing runs a risk of not being equitable to all candidates, and at the very least places high demands on both the interviewee and the interviewer. That said, Gross summarizes the potential value of talking to people about movies, music, and other popular culture in interviews:

I think that works because you can learn a lot from what someone says -- they're not likely to make up a story -- but it's also fun, and it is a common thing many people share, even in this era of HBO and Netflix.

This exchange reminded me of perhaps my favorite interview of all time, one in which I occupied the hot seat.

I was a senior in high school, hoping to study architecture at Ball State University. (Actual architecture... the software thing would come later.) I was a pretty good student, so I applied for Ball State's Whitinger Scholarship, one of the university's top awards. My initial application resulted in me being invited to campus for a personal interview. First, I sat to write an essay over the course of an hour, or perhaps half an hour. To be honest, I don't remember many details from that part of the day, only sitting in a room by myself for a while with a blue book and writing away. I wrote a lot of essays in those days.

Then I met with Dr. Warren Vander Hill, the director of the Honors College, for an interview. I'd had a few experiences on college campuses in the previous couple of years, but I still felt a little out of my element. Though I came from a home that valued reading and learning, my family background was not academic.

On a shelf behind Dr. Vander Hill, I noticed a picture of him in a Hope College basketball jersey, dribbling during a college game. I casually asked him about it and learned that he had played Division III varsity ball as an undergrad. I just now searched online in hopes of confirming my memory and learned that he is still #8 on the list of Hope's all-time career scoring leaders. I don't recall him slipping that fact into our chat... (Back then, he would have been #2!)

Anyway, we started talking basketball. Somehow, the conversation turned to Oscar Robertson, one of the NBA's all-time great players. He starred at Indianapolis's all-black Crispus Attucks High School and led the school to a state championship in 1955. From there, we talked about a lot of things -- the integration of college athletics, the civil rights movement, the state of the world in 1982 -- but it all seemed to revolve around basketball.

The time flew. Suddenly, the interview period was over, and I headed home. I enjoyed the conversation quite a bit, but on the hour drive, I wondered if I'd squandered my chances at the scholarship by using my interview time to talk sports. A few weeks later, though, I received a letter saying that I had been selected as one of the recipients.

That was the beginning of four very good years for me. Maybe I can trace some of that fortune to a conversation about sports. I certainly owe a debt to the skill of the person who interviewed me.

I got to know Dr. Vander Hill better over the next four years and slowly realized that he had probably known exactly what he was doing in that interview. He had found a common interest we shared and used it to start a conversation that opened up into bigger ideas. I couldn't have prepared answers for this conversation. He could see that I wasn't making up a story, that I was genuinely interested in the issues we were discussing and was, perhaps, genuinely interesting. The interview was a lot of fun, for both of us, I think, and he learned a lot about me from just talking.

I learned a lot from Dr. Vander Hill over the years, though what I learned from him that day took a few years to sink in.

Most people, when they become teachers, tell themselves that they won't do all the annoying things that their teachers did. If they teach for very long, though, they almost all find themselves slipping back to practices they didn't like as a student but which they now understand from the other side of the fence. Dynomight has written a nice little essay explaining why. Like deadlines. Why have deadlines? Let students learn and work at their own pace. Grade what they turn in, and let them re-submit their work later to demonstrate their newfound learning.

Indeed, why not? Because students are clever and occasionally averse to work. A few of them will re-invent a vexing form of the ancient search technique "Generate and Test". From the essay:

1. Write down some gibberish.
2. Submit it.
3. Make a random change, possibly informed by feedback on the last submission.
4. Resubmit it. If the grade improved, keep it, otherwise revert to the old version.
5. Goto 3.

You may think this is a caricature, but I see this pattern repeated even in the context of weekly homework assignments. A student will start early and begin a week-long email exchange where they eventually evolve a solution that they can turn in when the assignment is due.

I recognize that these students are responding in a rational way to the forces they face: usually, uncertainty and a lack of the basic understanding needed to even start the problem. My strategy is to try to engage them early on in the conversation in a way that helps them build that basic understanding and to quiet their uncertainty enough to make a more direct effort to solve the problem.

Why even require homework? Most students and teachers want for grades to reflect the student's level of mastery. If we eliminate homework, or make it optional, students have the opportunity to demonstrate their mastery on the final exam or final project. Why indeed? As the essay says:

But just try it. Here's what will happen:

1. Like most other humans, your students will be lazy and fallible.
2. So many of them will procrastinate and not do the homework.
3. So they won't learn anything.
4. So they will get a terrible grade on the final.
5. And then they will blame you for not forcing them to do the homework.

Again, the essay is written in a humorous tone that exaggerates the foibles and motivations of students. However, I have been living a variation of this pattern in my compilers course over the last few years. Here's how things have evolved.

I assign the compiler project as six stages of two weeks each. At the end of the semester, I always ask students for ways I might improve the course. After a few years teaching the course, students began to tell me that they found themselves procrastinating at the start of each two-week cycle and then having to scramble in the last few days to catch up. They suggested I require future students to turn something in at the end of the first week, as a way to get them started working sooner.

I admired their self-awareness and added a "status check" at the midpoint of each two-week stage. The status check was not to be graded, but to serve as a milepost they could aim for in completing that cycle's work. The feedback I provided, informal as it was, helped them stay course, or get back on course, if they had missed something important.

For several years, this approach worked really well. A few teams gamed the system, of course (see generate-and-test above), but by and large students used the status checks as intended. They were able to stay on track time-wise and to get some early feedback that helped them improve their work. Students and professor alike were happy.

Over the last couple of years, though, more and more teams have begun to let the status checks slide. They are busy, overburdened in other courses or distracted by their own projects, and ungraded work loses priority. The result is exactly what the students who recommended the status checks knew would happen: procrastination and a mad scramble in the last few days of the stage. Unfortunately, this approach can lead a team to fall farther and farther behind with each passing stage. It's hard to produce a complete working compiler under these conditions.

Again, I recognize that students usually respond in a rational way to the forces they face. My job now is to figure out how we might remove those forces, or address them in a more productive way. I've begun thinking about alternatives, and I'll be debriefing the current offering of the course with my students over the next couple of weeks. Perhaps we can find something that works better for them.

That's certainly my goal. When a team succeeds at building a working compiler, and we use it to compile and run an impressive program -- there's no feeling quite as joyous for a programmer, or a student, or a professor. We all want that feeling.

Anyway, check out the full essay for an entertaining read that also explains quite nicely that teachers are usually responding in a rational way to the forces they face, too. Cut them a little slack.

Courtesy of Chad Orzel's blog:

This ended up reminding me of the Two Cultures theory of meetings that I heard (second-hand) from a former Dean (a Classics professor, for the record). This was prompted by her noticing that the scientists and engineers always seemed grumpy and impatient about having meetings during work hours, where folks from the non-STEM fields were more cheerful. She realized that this was largely because the STEM folks tended to do research in their labs and offices on campus, during the day, so having a meeting was directly taking them away from productive time. For folks on the more literary side of academia, the actual scholarly work of reading and writing was mostly done elsewhere— at home, in coffee shops, at archives— and at times outside the normal academic workday— in the evening, during the summer, etc. As a result, they tended to only come to campus for classes, meetings, and socialization, and the latter two tended to blend together.

Now I'm thinking back over my years as a faculty member and department head. I've been attending meetings mostly with administrators for so now long that I my experience is blunted: the days of science department heads are less different from the days of arts and humanities department heads than the differences for the corresponding faculty. Most admins seem reconciled, if ruefully, to their meetings.

Being a computer scientist affects my experience, too. Most of our faculty are software people who can read and write code from anywhere. In this regard, we are perhaps more like arts and humanities folks than other scientists are. When I think back on my interactions with CS colleagues, the ones least likely to want to meet at any old time are (1) people who do work with hardware in their labs and (2) people doing the most serious research. The second group tend to guard their creative time more carefully in all respects.

The other thing coloring my experience is... me. I am frequently grumpy and impatient about having meetings at all, during regular work hours or not, because so many of them come up on the wrong side of the cost/benefit ledger. A lot of university meetings happen only because they are supposed to happen. Many of my colleagues are congenial about this and manage to find ways to put the time to good use for them and, presumably, many other participants. I'd generally like to get back to work on more pressing, or interesting, matters.

But that is getting a bit far afield from the basic observation of a Two Cultures-style split, which is founded, I think, on the notion that the meetings in question are essential or at least important enough to hold. In that narrower context, I think Chad's colleague may be on to something.

~~~~~

Photo by Nikola Johnny Mirkovic on Unsplash.

Rands recently wrote about his work-from-home routine. I love the idea of walking around a large wooded yard while doing audio meetings... One of his reasons for feeling so at ease struck a chord with me:

Everyone desperately wants to return to normality. I am a professional optimist, but we are not returning to normal. Ever. This is a different forever situation, and the sooner we realize that and start to plan accordingly, the sooner we will feel unstuck.

I have written or spoken a variation of this advice so many times over my fifteen years as department head, most often in the context of state funding and our university budget.

Almost every year for my first decade as head, we faced a flat or reduced budget, and every time several university colleagues expressed a desire to ride the storm out: make temporary changes to how we operate and wait for our budgets to return to normal. This was usually accompanied by a wistful desire that we could somehow persuade legislators of our deep, abiding value and thus convince them to allocate more dollars to the university or, failing that, that new legislators some future legislature would have different priorities.

Needless to say, the good old days never returned, and our budget remained on a downward slide that began in the late 1990s. This particular form of optimism was really avoidance of reality, and it led to many people living in a state of disappointment and discomfort for years. Fortunately, over the last five or ten years, most everyone has come to realize that what we have now is normal and has begun to plan accordingly. It is psychologically powerful to accept reality and begin acting with agency.

As for the changes brought on by the pandemic, I must admit that I am undecided about how much of what has changed over the last few months will be the normal way of the university going forward.

My department colleagues and I have been discussing how the need for separation among students in the classroom affects how we teach. Our campus doesn't have enough big rooms for everyone to move each class into a room with twice the capacity, so most of us are looking at ways to teach hybrid classes, with only half of our students in the classroom with us on any given day. This makes most of us sad and even a little depressed: how can we teach our courses as well as we always have in the past when new constraints don't allow us to do what we have optimized our teaching to do?

I have started thinking of the coming year in terms of hill climbing, an old idea from AI. After years of hard work and practice, most of us are at a local maximum in our teaching. The pandemic has disoriented us by dropping us at a random point in the environment. The downside of change in position is that we are no longer at our locally-optimal point for teaching our courses. The upside is that we get to search again under new conditions. Perhaps we can find a new local maximum, perhaps even one higher than our old max. If not, at least we have conducted a valuable experiment under trying conditions and can use what we learn going forward.

This analogy helps me approach my new course with more positive energy. A couple of my colleagues tell me it has helped them, too.

As many others have noted, the COVID-19 crisis has accelerated a few changes that were already taking place in our universities, in particular in the use of digital technology to engage students and to replace older processes. Of the other changes we've seen, some will certainly stick, but I'm not sure anyone really knows which ones. Part of the key to living with the uncertainty is not to tie ourselves too closely to what we did before.

When I refactor my code, I most often think in terms of what Martin Fowler calls preparatory refactoring: if it's difficult to add a new feature to my program, I refactor the existing code into a state where the feature fits naturally somewhere, then I add the feature. As is often the case, Kent Beck captured this notion memorably in a tweet-sized aphorism. I was delighted to see that Martin's blog post, which I remember fondly, cites the same tweet!

Ideas from programming are usually instances of more general ideas from the broader world, specialized to a world of bits and computation. Back when I taught our object-oriented programming course every semester, I often referred my students to a web site that offered real-life examples of the various design patterns we were learning. I remember an example of Decorator that showed how we can embellish a painting with a matte or a frame, and its use of the U.S. Constitution's specification of the President to illustrate the idea of a Singleton. I can't find that site on the web just now, but there's almost surely a local copy buried in one of my course websites from way back.

The idea of refactoring is useful outside the world of software, too. Just yesterday, my dean suggested what I consider to be a preparatory refactoring.

A committee on campus is charged with proposing ways that the university can restructure its colleges and departments. With the exception of a merger of two colleges a few years ago, we have had essentially the same academic structure for my entire time here. In those years, disciplines have changed and budgets have changed, so now the administration is thinking that the university might be more efficient or more productive with a different structure. Thinking about the process from this perspective, restructuring is largely a reaction to change that has already happened.

My dean suggested another way to approach the task. Think, he said, of the new academic programs that you'd like to create in the future. We may not have money available right now to create a new major or to organize a new research center, but one day we might. What university structure would make adding this program go more smoothly and work better once in place? Which departments would the new program want to work with? Which administrative structures already in place would minimize unnecessary overhead of the new program? As much as possible, he suggested, let's try to create a new academic structure that suits the future programs we'd like to build. That will reduce friction later, which is good: Administrative friction often grinds new academic ideas to a halt before they get off the ground.

In programming terms, this is quite bit different than the sort of refactoring I prefer. I try to practice YAGNI and refactor only for the specific feature that I want to add right now, not taking into account imagined future features I may never need. In terms of academic structure, though, this sort of ip-front design makes a lot of sense. Academic structures are much harder to change than software; getting a few things right now may make future changes at the program level much easier to implement later.

Thinking about academic restructuring this way has another positive side effect: it might entice faculty to be more engaged, because what we do now matters to the future we would like to build. It's not merely a reaction to past changes.

My dean is suggesting that we build academic structures now that make the changes we want to implement later (when the resources and requisite will exist) easier to implement. Building those structures now may take more work than simply responding to past changes, but it will be worth the effort when we are ready to create new programs. I think Kent and Martin might be proud.

In yesterday's post, I mentioned re-reading Richard Hamming's 1986 talk, You and Your Research. Hamming himself found it useful to manage his own behavior in order to overcome his personal faults, in service of his goal to do great work. I have faults, too, and need occasional reminders to approach my work more intentionally.

I've been at low ebb recently with my own creative work, so there is plenty of low-hanging fruit to be picked after this read. In the short term, I plan to...

• focus my reading and programming time on material that contributes to specific research and teaching problems I'm working on. In particular, as Hamming says, "you need to keep up more to find out what the problems are than ... to find the solutions" -- then get to work actually solving problems.
• 
  
• attend seminars in other departments regularly next semester, especially in our science departments. This action works in the opposite direction as the first bullet, as it broadens my vision beyond my own work. Its benefit is in providing a cross-fertilization of ideas and giving me more chances to converse with smart people outside my area who are solving interesting problems.

I'm also our department head, an administrative role that diverts much of my attention and energy from doing computer science. Hamming doesn't dismiss "management" outright, as so many scientists do. That's heartening, because organizations need good leaders to help create the conditions in which scientists do great work. He even explains why a capable scientist might reasonably choose to become a manager: "The day your vision, what you think needs to be done, is bigger than what you can do single-handedly, then you have to move toward management."

When I became head, I had some ideas about our department that I wanted to help implement from a leadership position. Do I still such ideas that I need to drive forward? If so, then I need to focus my administrative work on those goals. If not, then I need to think about next steps.

In an excerpt from The High Growth Handbook, Elad Gil talks with Sam Altman, the president of Y Combinator, about some of the mistakes CEOs make as their companies grow. At one point, Altman says "The role of the CEO is basically to figure out and decide what the company should do and then make sure it does that." The problem is, most CEOs like one part of that assignment more than the other:

The hard part is that most people want to just do the first part, which is figure out what the company should do. In practice, time-wise, I think the job is 5% that and 95% making sure that it happens. And the annoying thing to many CEOs is that the way you make it happen is incredibly repetitive.

From my own experiences, I see how this could be a problem for young executives. I have been an academic department head for over ten years now. Being the CEO of a startup is surely a more difficult job, if only because of the global stability that a university provides around an academic department. But department heads do have to work with faculty and deans to figure out what the department should be doing right now and then work to make sure the department does it.

As head, I have encountered the annoyance Altman points out: a lot of what a department head has to do to get the work done is repetitive, often boring, and rarely the kind of disciplinary work that attracted one to academia in the first place. For the first few years, a new head can ride the adrenaline that comes from the excitement of new tasks and new people to work with. After that, it can sometimes feel like a slog. It becomes a small challenge each day to keep the department's larger goal in mind and persevere. That, I think, is pretty similar to the challenge for CEOs that Altman is talking about.

Perhaps this problem is simply another form of the gulf between idea and execution that often separates successful entrepreneurs from those who come up short. Figuring out what to do is only valuable if you can make it happen. That happens in the trenches, in mundane activities of the everyday.

When I became head of my department, one of the things that became a near-daily part of my life was enforcing administrative rules and fielding requests for exceptions to those rules. I like writing code a lot more, but these decisions involve a surprising amount of judgment, which can make them occasionally interesting.

A couple of weeks ago, Matt Reed wrote about the challenge of making exceptions to administrative rules. He opens by pointing to someone else's tweet asserting that exceptions to rules will largely flow to a certain group of students: those who grow up believing they have a right to question the rules. Reed acknowledges that this is true but goes on to argue that, even so, exceptions are an essential part of a fair system. I agree with him that there is a lot going here.

One of the few administrative tasks about which I had well-formed ideas before I started as head was applying rules. I'm in the group of students that many people would think of as privileged enough to be comfortable asking for exceptions. But I was also raised as a rule follower and, as a result, almost never asked for exceptions. I went through school following the rules as they were given to me and finding ways to move forward when the rules slowed me down. Occasionally I would learn that a friend had asked for an exception on a lark and ended up with an easier path. At first, I usually felt foolish for not asking myself; later, I would feel bad about myself for being a patsy, or cynical toward the system.

So, when I became an administrator, I wanted to be careful to apply the rules fairly, as they were intended, and not make exceptions just because someone asked for an out. It's tempting to help out a student when he or she asks for a break, but what about those students who didn't ask -- because they didn't know they could, or because they were afraid, or because they assumed the request would be denied? Things get hard sometimes when a faculty member presses for an exception to help a student they like or want to help. The faculty member will often say, "Well, the student wouldn't ask for this, so let's help them out anyway." But my thoughts stay with the students who won't ask and don't have an advocate. What about them?

If we start getting a lot of requests from faculty and students for an exception to a specific rule, I figure it's time for us to consider changing the rule.

However, as Reed argues, with any non-trivial rule, there really are exceptions to the spirit of the rule that we need to take into account. In his words, we need to exercise a little "epistemological humility". Even wise and experienced faculty members can't envision all possible circumstances that may arise when they write a rule. It's even harder to anticipate how a policy will interact with the myriad other policies enacted in the department or by other departments on campus. When those unexpected circumstances or interactions arise, we have to make exceptions if we really want to be fair. This means exercising judgment.

In my time as head, I have worked hard to walk the fine line between enforcing the rule as intended and making exceptions when exceptional circumstances arise. The challenge comes in dealing with groups of people at either end of a spectrum:

• Some faculty want to make exceptions all the time. "It's just a rule," they say. "Why make someone suffer?"
• Some faculty never want to make exceptions. They fear that our (or their) judgment will be called into question, and it's simpler -- and safer -- to never go out on a limb.

I learned early on that I was not omniscient and that the only way to be fair to students and faculty is to make exceptions. But I prefer to exercise judgment carefully. In order to do that, I ask for well-considered justifications.

To be honest, the justifications on most of the student requests I receive boil down to "because I want you to" or "because it would help me". If we enforce a prerequisite, it will push back a student's graduation date. (Sadly, failing a course has consequences...) If we enforce a distribution requirement, the student will have to take a course they don't like, or take a course from a professor they don't like.

In most of these cases, I sympathize with the student's plight, but that doesn't mean I can grant an exception. I try to probe for more details to see if there are grounds for further consideration, but most often I simply have to be the bearer of bad news.

(I've been talking about student requests a lot here, but my years as department head have taught me that faculty are not all that different. Some never ask for exceptions to rules that apply to them, while others ask freely. A surprising number of the requests also boil down to "because I want you to".)

With some effort, it is possible to walk the fine line. As Reed says:

The folks of whom exceptions are being asked need to be able to explain why they said "yes" to student A and "no" to student B. Ideally, they should know not only the rules, but the reasons behind the rules. That's a tall order, but in many cases, it can be done.

My general practice works something like this: Require that each request for an exception come with an actual justification that explains the exceptional circumstance. If the given justification is weak but I think there may be something worth considering, I work with the student (or faculty member) to elicit the deeper rationale behind the request. If the ultimate justification is solid, then I consider making an exception, sometimes in consultation with the faculty. Absent a solid justification, I enforce the rule. In those cases, I try to help the requestors understand why and, if possible, try to help them find other ways to handle the challenge facing them.

In my dozen or so years as head, I've surely made a few mis-steps, granting a request or two that should have been denied and denying a request or two that probably should have been approved. But I've worked hard to make good decisions, to recognize those cases in which I needed to update my thinking, and to recommend that we change rules when they no longer serve the purpose we intended. As with so many other tasks that we teachers and department heads perform, a little epistemological humility comes in awfully handy. Mistakes and struggles remind us to stay humble.

In Leadership as a Performing Art, Ed Batista discusses, among other things, a "naturalness bias" that humans have when evaluating one another. Naturalness is "a preference for abilities and talents that we perceive as innate over those that appear to derive from effort and experience". Even when people express a preference for hard work and experience, they tend to judge more positively people who seem to be operating on natural skill and talent. As Batista notes, this bias affects not only how we evaluate others but also how we evaluate ourselves.

As I read this article, I could not help but think about how students who are new to programming and to computer science often react to their own struggles in an introductory CS course. These thoughts reached a crescendo when I came to these words:

One commonly-held perspective is that our authentic self is something that exists fully formed within us, and we discover its nature through experiences that feel more (or less) natural to us. We equate authenticity with comfort, and so if something makes us feel uncomfortable or self-conscious, then it is de facto inauthentic, which means we need not persist at it (or are relieved of our responsibility to try). But an alternative view is that our authentic self is something that we create over time, and we play an active role in its development through experiences that may feel uncomfortable or unnatural, particularly at first. As INSEAD professor of organizational behavior Herminia Ibarra wrote in The Authenticity Paradox in 2015,

Because going against our natural inclinations can make us feel like impostors, we tend to latch on to authenticity as an excuse for sticking with what's comfortable... By viewing ourselves as works-in-progress and evolving our professional identities through trial and error, we can develop a personal style that feels right to us and suits our organizations' changing needs. That takes courage, because learning, by definition, starts with unnatural and often superficial behaviors that can make us feel calculating instead of genuine and spontaneous. But the only way to avoid being pigeonholed and ultimately become better leaders is to do the things that a rigidly authentic sense of self would keep us from doing.

So many CS students and even computing professionals report suffering from impostor syndrome, sometimes precisely because they compare their internal struggles to learn with what appears to be the natural ability of their colleagues. But, as Ibarra says, learning, by definition, starts with the unnatural. To be uncomfortable is, in one sense, to be in a position to learn.

How might we teachers of computer science help our students overcome the naturalness bias they unwittingly apply when evaluating their own work and progress? We need strategies to help students see that CS is something we do, not something we are. You can feel uncomfortable and still be authentic.

This distinction is at the foundation of Batista's advice to leaders and, I think, at the foundation of good advice to students. When students can distinguish between their behavior and their identity, they are able to manage more effectively the expectations they have of their own work.

I hope to put what I learned in this article to good use both for my students and myself. It might help me be more honest -- and generous -- to myself when evaluating my performance as a teacher and an administrator, and more deliberate in how I try to get better.

In The Melancholy Dean, Matt Reed notes that, while most management books speak at the level of the CEO or a founder, most managers work further down the chain of command.

Most managers are closer to deans than to presidents. They're in the middle. ... it's not unusual that they find themselves tasked with carrying out policies with which they personally disagree. When success in a position relies largely on "soft power", having to carry out positions with which you personally disagree can be a real strain.

Obviously, if the disagreements become too large or frequent, the right move is to step out of the role. But that's the exception. More commonly, there's a vague sense of "I wouldn't have done it that way" that falls well short of a crisis of conscience, but can be enough to sap motivation. That's especially true when budgets are tightening and adverse decisions are made for you.

I have seen this happen to deans, but I also know the feeling myself. Here, department heads are administrators, and formally they depend upon the dean and provost for their positions. As public universities have to face falling state appropriations, increasing regulatory requirements, and increased competition for students, they often find themselves operating with more of a corporate mentality than the hallowed halls of academia we all dream of from yesteryear. Even with good and open leaders making decisions in upper administration (which I have been fortunate to have in my time as an administrator), more agency lives outside the department, more of the department head's time is spent carrying out activities defined elsewhere, and fewer strategic decisions are made by the head and faculty within the department.

It does wear on a person. These days, academic middle managers of all sorts have to cultivate the motivation they need to carry on. The good news is, through it all, we are helping students, and helping faculty help students. Knowing that, and doing at least a little programming every day, helps me relieve whatever strain I might feel. Even so, I could use more closure most days of the week.

My perspective on the way the university works changed after I became department head. This paragraph describes rather well one of the changes:

The other major challenge is coming to terms with all of the constraints within which decisions are made. From the outside, it's often easy to criticize actual decisions when contrasted when imagined ideal outcomes. But when you know why those ideals have to be imaginary, and you have to maneuver within much narrower confines than you might have imagined, you start to understand the "why" behind some patterns. That can be frustrating, but if you treat it as a series of puzzles, it can be fun. Any idiot can get good results with infinite resources and discretion, but how can you improve results with flat funding, contradictory policies, and prickly personalities? That's where the challenge comes in.

Yes, the university could do everything in its power to meet the needs and desires of Computer Science. It turns out, though, that other departments have needs and desires, too. Sometimes, those needs are more critical at this moment than our are.

You would think that CS faculty, who identify and measure trade-offs as a part of their academic discipline, would grok the notion of trade-offs inside the institution more easily. It took me a while to really get. Now, a big part of my job is helping other faculty to see it, too, all the while advocating effectively for my department.

The paragraph quoted above is by Matt Reed, from How to.... This sentence from the same piece expresses one of the biggest challenges to my peace of mind and daily sense of accomplishment after becoming department head:

The victories in administrative roles tend to be vicarious, rather than personal or direct.

The way I help faculty and students most as department head is by helping to reduce or eliminate friction that slows them down and wastes their energy. My biggest wins are usually when our faculty and students accomplish something big.

The other most salient challenge to my professional peace of mind: lack of closure. Almost nothing is ever finished, no battle ever won; it all starts again tomorrow.

Last month, Seth Godin posted a short entry about reputation. It brought back memories of my first couple of years as department head. I was excited and wanted to do a good job, so I took on a lot. Pretty soon I was in a position of having promised more than I could deliver. Some of the shortfall resulted from the heavy load itself; there are only so many hours in a week. Some resulted from promising things I couldn't deliver, because I didn't understand the external constraints I faced.

When you don't deliver, explanations sound like excuses.

If I were giving advice to myself at the time I became head (already an adult who should have known better...), I would tell him to heed Godin's advice and help people learn what they can expect from you. Explicit attention to expectations can pay off in seeding reputation but also by setting parameters for yourself. Then live up to that standard.

If you teach people to expect little, perhaps unintentionally, they will -- even on the occasions when you do better. And after you get better, if you do, it takes a long time to undo the expectations you created early on.

Live the life you've taught people to expect from you -- but first be careful what you teach them to expect.

Dan Luu's blog is usually both entertaining and insightful. We Only Hire The Trendiest is no exception.

I did my undergrad at Wisconsin, which is one of the 25 schools that claims to be a top 10 cs/engineering school...

Even though he comes from one of the best CS schools, Luu recognizes that grads of many other schools are well prepared for careers in industry. Companies that bias their hiring toward the top schools miss out on a lot of "talent". Then again, they miss out on a lot of great talent in many other ways, too. For example:

A typical rejection reason was something like "we process millions of transactions per day here and we really need someone with more relevant experience who can handle these things without ramping up".

The people you don't hire won't have to ramp up. There is only one problem: You didn't hire anyone, so there's no way they can help you handle these things. Maybe you should hire people with strong foundations, a little curiosity, and a little drive. Those people can develop all the relevant experience you need.

As Luu says, "It's much easier to hire people who are underrated, especially if you're not paying market rates." That's where the Moneyball analogy comes in handy. I wonder if any company is doing sabermetric-like analysis of software developers? If so, they could develop a durable competitive advantage in hiring.

Software entrepreneurs and companies in my part of the world, the American Midwest, have always faced stiff challenges when it comes to hiring and retaining tech talent from the coasts. Luu reminds them that they also have an opportunity: find underrated people from non-elite schools who want to stay in the Midwest, and then develop a team of professionals who rival in performance anything you can find on the coasts.

In my town, Banno is a great example of a company that has accepted this challenge. It's not easy, but with patience and strong leadership, it seems to be working.

Jim Garland is a physicist who eventually became president of Miami University of Ohio. In Bad Writing by Administrators, Rachel Toor asked Garland how his writing evolved as he moved up the administrative hierarchy. His response included:

Truthfully, I did my deepest thinking as a beginning assistant professor, writing obscure papers on the quantum-mechanical properties of solids at liquid-helium temperatures. Over the years, I became shallower and broader, and by the time I left academe, I was worrying about the seating arrangement of donors in the president's football box.

I have experienced this even in my short step into the department head's office. Some of the writing I do as head is better than my writing before: clear, succinct, and qualified precisely. It is written for a different audience, though, and within a much different political context. My colleagues compliment me occasionally for having written a simple, straightforward note that says something they've been struggling to articulate.

Other times, my thinking is more muddled, and that shows through in what I write. When I try to fix the writing before I fix my thinking, I produce bad writing.

Some writing by administrators really is bad, but a lot of it is simply broader and shallower than what we write as academics. The broader it becomes, the less interesting the content is to the academics still living inside of us. Yet our target audience often can appreciate the value of that less interesting writing when it serves its purpose.

The Department of Biology operates a greenhouse so that its faculty can cultivate and study a wide range of plants. The greenhouse offers students a chance to see, smell, and touch real, living plants that they may never have encountered before. With the greenhouse as an ecosystem, students get to learn about the relationships among species and a little about how species evolve. The ecological setting in which the plants are grown provides the context needed for faculty to demonstrate realistically how organisms are connected within environments.

Faced with budget cuts, the university has decided that it is no longer cost-effective to have biology staff operate the greenhouse. We already have a grounds and landscaping unit as part of the physical plant, and its staff has expertise for working with a variety plants as a part of managing lawns and gardens. To save money, the administration is centralizing all plant management services in grounds and landscaping. If the folks in Biology needs anything done in or for the greenhouse, they call a designated contact person. They will have to streamline the offerings in the greenhouse, based on university-wide decisions about what kind of plants we can afford to support.

The Department of Art has a number of faculty who specialize in drawing, both pencil and ink, and in painting. All students who major in art take two courses in drawing as part of the foundations sequence, and many studio art majors take painting. Both media help students learn to see and teach them about how their materials interact with their vision and affect the shape of their creative works.

Faced with budget cuts, the university has decided that it is no longer cost-effective to have the art faculty select and buy their own pencils, ink, and paints. We already have a couple of units on campus who purchase and use these materials. Operation and Maintenance does a wide variety of carpentry projects that include painting. All campus staff use pencils and ink pens, so Business Operations has purchasing agreements with several office supplies wholesalers. These agreements ensure that university staff can stock a range of pencils, pens, and paints at the best possible price.

When one of the drawing faculty calls over for a particular set of soft graphic pencils, ranging in hardness from 9B to H, she is told that the university has standardized on a set with a smaller range. Satndardization allows us to buy in bulk and to save management overhead. "At least they aren't all No. 2 pencils," thinks the art prof.

When one of the painting faculty calls over to Facilities for a particular set of acrylic paints, the warehouse manager says, "Sure, just let me know what colors you need and we'll by them. We have a great contract with Sherwin Williams." The prof isn't sure where he'll put all the one-gallon cans, though.

... just kidding. No university would ever do that, right? Biologists run their own greenhouses and labs, and art faculty select, buy, and manage specialty materials in their studios. Yet academic Computer Science departments often work under nearly identical circumstances, because computers are part of university's IT infrastructure.

Every few years at academic institutions, the budget and management pendulum swings toward centralization of IT services, as a way to achieve economies of scale and save money. Then, a few years later, it swings back toward decentralization, as a way to provide better and finer-grained services to individual departments. Too often, the services provided to CS faculty and students are forced to go along for the ride.

My university is going through one of its periodic recentralizations, at the orders of the Board of Regents. Every time we centralize, we have to have the same conversations about how Computer Science fits into the picture, because most non-CS people ultimately see our use of computers and software as fundamentally the same as, say, the English department's or the Psychology department's. However interesting those departments' use of technology is (and in this day, most faculty and students use technology in interesting ways, regardless of discipline), it is not the same thing as what Computer Science does.

Academic computing has never been limited to computer scientists, of course. Many mathematicians and physicists rely on a very different sort of computing than the folks who use it only for library-style research, writing, and presentation. So do faculty in a few other disciplines. Just as Biology and Art need specialized laboratories and materials, so do those departments that are working at the edge of computing require specialized laboratories and materials. Computer Science is simply the discipline that is farthest out along this curve.

The same thing goes for support staff as for equipment. Few administrators would think of "centralizing" the lab technician and supplies manager for Biology or Chemistry into a non-academic unit on campus, or ask academic departments to depend on a non-academic unit to provide discipline-specific services that are critical to the departments' mission. Lab technicians and equipment managers need to be hired by the departments (or the college) that need them and serve the departments directly. So, too, do certain departments need to have system administrators and lab managers who work for them to meet the specialized needs of academic computing, serving the department or college directly.

Hardware and software are a computer scientist's greenhouse and artistic media. They are our our library and our telescopes, our tallgrass prairie preserves and our mass spectrometers. It is essential that university administrations think of -- and provide for -- Computer Science and other computation-laden departments as academic disciplines first, and not just as consumers of generic IT services. Doing so requires, among other things, leaving control of essential hardware, software, and policies for their use within the academic departments.

~~~~~

Disclaimer. The vignettes above were written by me. I am very much neither a biologist nor a studio artist. If any of the details clash with reality, please see them as creative liberties taken by the author to serve a theme.

I agree with Timothy Burke that the evolution of university administration is shaped in part by the unintended consequences of faculty behavior:

I think some of my colleagues across the country are potentially contributing to the creation of the distanced, professionalized, managerial administrations that they say that they despise, and they're doing it in part through half-voiced expectations about what an ideal administrator might be like.

This passage comes from Performing the Role, in which Burke discusses some of the fall-out from a botched faculty hiring at the University of Illinois last year. Even if you don't know much about the Salaita case, you may find Burke's piece worth reading. It captures pretty well how universities seem to be shifting toward a professionalized administrative class and the ways in which this shift clashes -- and meshes -- with faculty expectations and behavior.

This line, in particular, sums up a surprising amount of my experience as a department head for the last decade:

I think we somehow expect that administrative leaders should be unfailingly polite, deferential, patient, and solicitous when we're the ones talking with them and bold, confrontational, and aggressive when they're talking to anyone else.

The next one has affected me less directly, but I see it in the expectations across campus all the time:

We seem to expect administrative leaders to escape structural traps that we cannot imagine a way to escape from.

Burke ends the paragraph containing those sentences with a summary that many administrators can appreciate: "There's a lot of Catch-22 going on here."

Burke is always thoughtful, and thought-provoking, on matters of academia and culture. If those topics interest, his blog is often worth reading.

Exceptions signal something outside the expected bounds of behavior of the code in question. But if you're running some checks on outside input, this is because you expect some messages to fail -- and if a failure is expected behavior, then you shouldn't be using exceptions.

That is a snippet from Replacing Throwing Exceptions with Notification in Validations, a refactoring Martin Fowler published earlier this month. The refactoring is based on an extraordinarily useful piece of software design advice: exceptions should be unexpected. If something is expected, it's not exceptional. Make your software say so. A notification mechanism can carry as much information about system behavior as exceptions and generally provides superior cohesion and division of labor.

Over the last few years, I've come to see that is really a tenet of good system design more generally. A couple of examples from my university experience:

• If your curriculum depends on frequent student requests to enable programs of study that faculty accept as reasonable, then you should probably modify the curriculum to allow what is reasonable. Not only are you gumming up the larger system with unnecessary paperwork, you are likely disadvantaging students who aren't savvy or cheeky enough to disregard the rules.
• 
  
• If the way you pay for instruction and equipment doesn't match the stated budget, then you should change the budget to reflect reality. If you don't control the writing of the budget, then you should find ways to communicate reality to the budget writers whenever possible. Sometimes, you can work around the given budget to accomplish what you really need for a long time. But over time the system will evolve in response to other external forces, and you reach a point where the budget in no way reflects reality. A sudden change in funding can put you in a state of real crisis. Few people will be able to understand why.

People sometimes tell me that I am naive to think complex systems like a university or even a curriculum should reflect reality closely. Programming has taught me that we almost always benefit from keeping our design as clean, as understandable, and as truthful as we can. I am pragmatic enough to understand that there are exceptions even to this tenet, in life and in software. But exceptions should be exceptional.

Yesterday I read:

It's hard for me to figure out people voting against their own self-interests.

I'm not linking to the source, because it wouldn't be fair to single the speaker out, especially when so many other things in the article are spot-on. Besides, I hear many different people express this sentiment from time time, people of various political backgrounds and cultural experiences. It seems a natural human reaction when things don't turn out the way we think they should.

Here is something I've learned from teaching and from working with teams doing research and writing software:

If you find yourself often thinking that people aren't acting in their own self-interests, maybe you don't know what their interests are.

It certainly may be true that people are not acting in what you think is their own self-interest. But it's rather presumptuous to think that you other people's best interest better than they do.

Whenever I find myself in this position, I have some work to do. I need to get to know my students, or my colleagues, or my fellow citizens, better. In cases where it's really true, and I have strong reason to think they aren't acting in their own best interest, I have an opportunity to help them learn. This kind of conversation calls for great care, though, because often we are dealing with people's identities and most deeply-held believes.

... on how the world evolves.

On the evolution of education in the Age of the Web. Tyler Cowen, in Average Is Over, via The Atlantic:

It will become increasingly apparent how much of current education is driven by human weakness, namely the inability of most students to simply sit down and try to learn something on their own.

I'm curious whether we'll ever see a significant change in the number of students who can and do take the reins for themselves.

On the evolution of the Web. Jon Udell, in A Web of Agreements and Disagreements:

The web works as well as it does because we mostly agree on a set of tools and practices. But it evolves when we disagree, try different approaches, and test them against one another in a marketplace of ideas. Citizens of a web-literate planet should appreciate both the agreements and the disagreements.

Some disagreements are easier to appreciate after they fade into history.

On the evolution of software. Nat Pryce on the Twitter, via The Problematic Culture of "Worse is Better":

Eventually a software project becomes a small amount of useful logic hidden among code that copies data between incompatible JSON libraries

Not all citizens of a web-literate planet appreciate disagreements between JSON libraries. Or Ruby gems.

On the evolution of start-ups. Rands, in The Old Guard:

... when [the Old Guard] say, "It feels off..." what they are poorly articulating is, "This process that you're building does not support one (or more) of the key values of the company."

I suspect the presence of incompatible JSON libraries means that our software no longer supports the key values of our company.

If you are an engineer or faculty member thinking about moving into administration, you should read A Disclosure an essay by Rands. It is the best short treatment of "becoming a manager" I've read and is worth more than a stack of similarly-themed books from the business shelf in the bookstore.

I have never been an engineer per se. I was a faculty member: a programmer, teacher, and scientist. I built things in order to learn cool stuff, and then figured out how to teach my students about that same stuff. I came to management nine years ago when we needed a new department, via a blend of two of the paths Rands describes: I decided that I could be a better department head than our acting head, who was helping as a stand-in from another department, and there were no other reasonable choices at the time.

Whether I have been a good enough department head is open for discussion. This is a difficult job, or at least different enough from I used to do that it seems difficult. Re-reading this blog today reminds me that I should re-visit my decision occasionally. There may well be other reasonable choices now, and my decision may have changed.

How do you know that the job is different, that you are living in a different world now? Easy:

This sensation will appear at the end of the day when you ask, "What did I build today?" The answer will be a troubling, "Nothing". The days of fixing ten bugs before noon are gone. You're no longer going to spend the bus ride home working on code; you're going to be thinking hard about how to say something important to someone who doesn't want to hear it. There will be drama. And there be those precious seconds when there is no one in your office wanting... something.

Before I became head, I never knew how many hours I would spend thinking hard about how to say something important to someone in a way that communicates effectively without misleading the person, confusing the person, or hurting the person's feelings. And, yes, sometimes people don't want to hear what I have to say.

The paragraph I quote is typical but not unique. Each week, I live some part of nearly every paragraph in this blog. The constant challenge for the engineer- or faculty member-turned-manager is, "Is this what makes you happiest and most effective?"

Wisdom from the TV:

"Whatever happened to humility, isn't that a virtue or something?"

"One of the highest. People in power are always saying so."

It is worth noting that one of the antonyms of "humble" is "privileged".

This passage apparently occurs in an episode of Orange Is The New Black. I've never seen the show, but the exchange is quoted in this discussion of the show.

I just realized how odd it is to refer to Orange Is The New Black as a TV show. It is Netflix original series, which shows up on your TV only if you route your Internet viewing through that old box. Alas, 30- and 60-minute serialized shows have always been "TV" to me. I'm caught in the slipstream as our dominant entertainment media change forms.

A lot of people I know have been discussing the recent New Yorker article "debunking" Clayton Christensen's theory of disruptive innovation. I'm withholding judgment, because that usually is the right thing for me to do when discussing theories about systems we don't understand well and critiques of such theories. The best way to find out the answer is to wait for more data.

That said, we have seen this before in the space of economics and business management. A few years back, the book Good to Great by James Collins became quite popular on my campus, because our new president, an economist by training, was a proponent of its view of how companies had gone from being merely steady producers to being stars in their markets. He hoped that we could use some of its prescriptions to help transform our university from a decent public comprehensive into a better, stronger institution.

But in recent years we have seen critiques of Collins's theory. The problem: some of the companies that Collins touts in the book have fallen on hard times and been unable to sustain their greatness. (As I said, more data usually settles all scores.) Good to Great's prescriptions weren't enough for companies to sustain greatness; maybe they were not sufficient, or even necessary, for achieving (short-term) market dominance.

This has long been a weakness of the business management literature. When I was an undergrad double majoring in CS and accounting, I read a lot of case studies about successful companies, and my professors tried to help us draw out truths that would help any company succeed. Neither the authors of the case studies nor the professors seemed aware that we were suffering from a base case of survivor bias. Sure, that set of strategies worked for Coca Cola. Did other companies use the same strategies and fail? If so, why? Maybe Coca Cola just got lucky. We didn't really know.

My takeaway from reading most business books of this sort is that they tell great stories. They give us posthoc explanations of complex systems that fit the data at hand, but they don't have much in the way of predictive power. Buying into such theories wholesale as a plan for the future is rarely a good idea.

These books can still be useful to people who read them as inspirational stories and a source of ideas to try. For example, I found Collins's idea of "getting the right people on the bus" to be helpful when I was first starting as department head. I took a broad view of the book and learned some things.

And that said, I have speculated many times here about the future of universities and even mentioned Christensen's idea of disruption a couple of times [ 1 | 2 ]. Have I been acting on a bad theory?

I think the positive reaction to the New Yorker article is really a reaction to the many people who have been using the idea of disruptive innovation as a bludgeon in the university space, especially with regard to MOOCs. Christensen himself has sometimes been guilty of speaking rather confidently about particular ways to disrupt universities. After a period of groupthink in which people know without evidence that MOOCs will topple the existing university model, many of my colleagues are simply happy to have someone speak up on their side of the debate.

The current way that universities do business faces a number of big challenges as the balance of revenue streams and costs shifts. Perhaps universities as we know them now will ultimately be disrupted. This does not mean that any technology we throw at the problem will be the disruptive force that topples them. As Mark Guzdial wrote recently,

Moving education onto MOOCs just to be disruptive isn't valuable.

That's the most important point to take away from the piece in the New Yorker: disruptors ultimately have to provide value in the market. We don't know yet if MOOCs or any other current technology experiment in education can do that. We likely won't know until after it starts to happen. That's one of the important points to take away from so much of the business management literature. Good descriptive theories often don't make good prescriptive theories.

The risk people inside universities run is falling into a groupthink of their own, in which something very like the status quo is the future of higher education. My colleagues tend to speak in more measured tones than some of the revolutionaries espousing on-line courses and MOOCs, but their words carry an unmistakable message: "What we do is essential. The way we do has stood the test of time. No one can replace us." Some of my colleagues admit ruefully that perhaps something can replace the university as it is, but that we will all be worse off as a result.

That's dangerous thinking, too. Over the years, plenty of people who have said, "No one can do what we do as well as we do" have been proven wrong.

With respect for Rands, I've adapted a paragraph from one of his engineering management pieces to my experience:

You're a department chair now. Congratulations. Either you sucked at teaching and research and wanted to try a different avenue of influence, or you're fed up with every other chair you've worked for and now you're going to REALLY GOING TO SHOW US how it's done.

It's much easier to be fed up than to show people how it's really done. Trust me.

This week has been a challenge. I have faced several things that need to be done well. Most of them are, in ways, peripheral to the core mission of the department and university, but they are important to students, faculty, and external stakeholders. If they are handled poorly, the experience people have will undercut everything else we do well.

So these are the things that a department head must do well, in the trenches and with not much fanfare. They consume a lot of emotional energy an introvert like me, and they don't offer a lot of immediate, tangible rewards. But they are worth my attention.

After a number of years in this position, I have found that it's a lot easier for me to imagine knocking the ball out of the park than to make contact. I keep working at it.

In this regard, I have begun to learn to combine empathy with the proper application of a scientific mindset to how people behave. This idea is echoed in a passage from Timothy Burke:

Anything that real people do in the world is by definition interesting. By "interesting", I mean worthy of the kind of investigation that puts curiosity and honesty well before judgment.

Curiosity about individual people and honest communication are generally my best tools in the trenches. Forgetting to turn off the judgment centers in my brain never works well.

Rand's Inbox Reboot didn't do much for me on the process and tool side of things, perhaps other than rousing a sense of familiarity. Been there. The part that stood out for me was when he talked about the ultimate effect of not being in control of the deluge:

As a leader, you define your reputation all the time. You'd like to think that you could choose the moments that define your reputation, but you don't. They are always watching and learning. They are always updating their model regarding who you are and how you lead with each observable action, no matter how large or small.

He was speaking of technical management, so I immediately thought about my time as department head and how true this passage is.

But it is also true -- crucially true -- of the relationship teachers have with their students. There are few individual moments that define how a teacher is seen by his or her students. Students are always watching and learning. They infer things about the discipline and about the teacher from every action, from every interaction. What they learn in all the little moments comes to define you in their minds.

Of course, this is even more true of parents and children. To the extent I have any regrets as a parent, it is that I sometimes overestimated the effect of the Big Moments and underestimated the effect of all those Little Moments, the ones that flow by without pomp or recognition. They probably shaped my daughters, and my daughters' perception of me, more than anything particular action I took.

Start with a good set of values, then create a way of living and working that puts these values at the forefront of everything you do. Your colleagues, your students, and your children are always watching.

I finally got around to reading Atul Gawande's Slow Ideas this morning. It's a New Yorker piece from last summer about how some good ideas seem to resist widespread adoption, despite ample evidence in their favor, and ways that one might help accelerate their spread.

As I read, I couldn't help but think of parallels to teaching students to write programs and helping professionals develop software more reliably. We know that development practices such as version control, short iterations, and pervasive testing lead to better software and more reliable process. Yet they are hard habits for many programmers to develop, especially when they have conflicting habits in place.

Other development practices seem counterintuitive. "Pair programming can't work, right?" In these cases, we have to help people overcome both habits of practice and habits of thought. That's a tall order.

Gawande's article is about medical practice, from surgeons to home practitioners, but his conclusions apply to software development as well. For instance: People have an easier time changing habits when the benefit is personal, immediate, and visceral. When the benefit is not so obvious, a whole new way of thinking is needed. That requires time and education.

The key message to teach surgeons, it turned out, was not how to stop germs but how to think like a laboratory scientist.

This is certainly true for software developers. (If you replace "germs" with "bugs", it's an even better fit!) Much of the time, developers have to think about evidence the ways scientists do.

This lesson is true not just for surgeons and software developers. It is true for most people, in most ways of life. Sometimes, we all have to be able to think and act like a scientist. I can think of no better argument for treating science as important for all students, just as we do reading and writing.

Other lessons from Gawande's article are more down-to-earth:

Many of the changes took practice for her, she said. She had to learn, for instance, how to have all the critical supplies -- blood-pressure cuff, thermometer, soap, clean gloves, baby respiratory mask, medications -- lined up and ready for when she needed them; how to fit the use of them into her routine; how to convince mothers and their relatives that the best thing for a child was to be bundled against the mother's skin. ...

So many good ideas in one paragraph! Many software development teams could improve by putting them in action:

• Construct a work environment with essential tools ready at hand.
• Adjust routine to include new tools.
• Help collaborators see and understand the benefit of new habits.
• Practice, practice, practice.

Finally, the human touch is essential. People who understand must help others to see and understand. But when we order, judge, or hector people, they tend to close down the paths of communication, precisely when we need them to be most open. Gawande's colleagues have been most successful when they built personal relationships:

"It wasn't like talking to someone who was trying to find mistakes," she said. "It was like talking to a friend."

Good teachers know this. Some have to learn it the hard way, in the trenches with their students. But then, that is how Gawande's colleagues learned it, too.

"Slow Hands" is good news for teachers all around. It teaches ways to do our job better. But also, in many ways, it tells us that teaching will continue to matter in an age dominated by technological success:

People talking to people is still how the world's standards change.

Clay Shirky explains the cultural attitudes that underlie Healthcare.gov's problems in his recent essay on the gulf between planning and reality. The danger of this gulf exists in any organization, whether business or government, but especially in large organizations. As the number of levels grows between the most powerful decision makers and the workers in the trenches, there is an increasing risk of developing "a culture that prefers deluding the boss over delivering bad news".

But this is also a story of the danger inherent in so-called Big Design Up Front, especially for a new kind of product. Shirky oversimplifies this as the waterfall method, but the basic idea is the same:

By putting the most serious planning at the beginning, with subsequent work derived from the plan, the waterfall method amounts to a pledge by all parties not to learn anything while doing the actual work.

You may learn something, of course; you just aren't allowed to let it change what you build, or how.

Instead, waterfall insists that the participants will understand best how things should work before accumulating any real-world experience, and that planners will always know more than workers.

If the planners believe this, or they allow the workers to think they believe this, then workers will naturally avoid telling their managers what they have learned. In the best case, they don't want to waste anyone's time if sharing the information will have no effect. In the worst case, they might fear the results of sharing what they have learned. No one likes to admit that they can't get the assigned task done, however unrealistic it is.

As Shirky notes, many people believe that a difficult launch of Healthcare.gov was unavoidable, because political and practical factors prevented developers from testing parts of the project as they went along and adjusting their actions in response. Shirky hits this one out of the park:

That observation illustrates the gulf between planning and reality in political circles. It is hard for policy people to imagine that Healthcare.gov could have had a phased rollout, even while it is having one.

You can learn from feedback earlier, or you can learn from feedback later. Pretending that you can avoid problems you already know exist never works.

One of the things I like about agile approaches to software development is they encourage us not to delude ourselves, or our clients. Or our bosses.

Henry Rollins:

When one beast dumps you, summon the guts to find another. If it tries to kill you, the party has definitely started. Otherwise, life is a slow retirement.

Rollins is talking about why he's not making music anymore, but his observation applies to other professions. We all know programmers who are riding out the long tail of an intellectual challenge that died long ago. College professors, too.

I have to imagine that this is a sad life. It certainly leaves a lot of promise unfulfilled.

If you think you have a handle on the beast, then the beast has probably moved on. Find a new beast with which to do battle.

I recently read The Sketchbook of Susan Kare, "the Artist Who Gave Computing a Human Face", which referred to the Apple legend of the Pirate Flag:

[Kare's] skull-and-crossbones design would come in handy when Jobs issued one of his infamous motivational koans to the Mac team: "It's better to be a pirate than join the Navy."

For some reason, that line brought to mind a favorite saying of one of my friends, Sid Kitchel:

Real men don't accept tenure.

If by some chance they do accept tenure, they should at least never move into administration, even temporarily. It's a bad perch from which to be a pirate.

Alan Kay recently wrote this on the Fundamentals of New Computing mailing list:

My own personal thoughts about what was accomplished [with Smalltalk] are completely intertwined with what our entire group was able to do in a few years at PARC. I would give us credit for a very high level combination of "computer science" and "software engineering" and "human centered design" and "commingled software and hardware", etc. The accomplishment was the group's accomplishment. And this whole (to me at least) was a lot more interesting than just a language idea.

I hasten to redirect personal praise to the group accomplishment whenever it happens.

I think this is also true for the larger ARPA-PARC community, and why it was able to accomplish so much at so many levels.

The "awards to individuals" structure beloved of other fields and of journalists completely misses the nature of this process. Any recognition should be like "World Series" rings -- everybody gets one, and that's it.

When Kay spoke at the 2004 OOPSLA Educators' Symposium as part of his Turing Award festivities, he frequently acknowledged the contributions of his team, in particular Dan Ingalls, and the influence that so many other people had on his team's work. Kay must have particularly appreciated receiving the Charles Stark Draper Prize together with Butler Lampson, Robert Taylor, and Charles Thacker, who helped create the conditions in which his team thrived.

In academia, we talk a lot about teamwork, but we tend to isolate individual performance for recognition. I like Kay's analogy to the rings received by teams that win sports championships. In those venues, the winners are unmistakably teams, even when a Michael Jordan or a Tom Brady stands out. That's how academic research tends to work, too. Perhaps we should make that clear more often in the awards we give.

Computational Thinking Division. From Jon Udell, another lesson that programming and computing teach us which can be useful out in the world:

Focus on understanding why the program is doing what it's doing, rather than why it's not doing what you wanted it to.

This isn't the default approach of everyone. Most of my students have to learn this lesson as a part of learning how to program. But it can be helpful outside of programming, in particular by influencing how we interact with people. As Udell says, it can be helpful to focus on understanding why one's spouse or child or friend is doing what she is doing, rather than on why she isn't doing what you want.

Motivational Division. From the Portland Ballet, of all places, several truths about being a professional dancer that generalize beyond the studio, including:

There's a lot you don't know.
There may not be a tomorrow.
There's a lot you can't control.
You will never feel 100% ready.

So get to work, even if it means reading the book and writing the code for the fourth time. That is where the fun and happiness are. All you can affect, you affect by the work you do.

Mac Chauvinism Division. From Matt Gemmell, this advice on a particular piece of software:

There's even a Windows version, so you can also use it before you've had sufficient success to afford a decent computer.

But with enough work and a little luck, you can afford better next time.

Mitch Daniels, the new president of Purdue University, says this about shared governance in An Open Letter to the People of Purdue, his initial address to the university community:

I subscribe entirely to the concept that major decisions about the university and its future should be made under conditions of maximum practical inclusiveness and consultation. The faculty must have the strongest single voice in these deliberations, but students and staff should also be heard whenever their interests are implicated. I will work hard to see that all viewpoints are fairly heard and considered on big calls, including the prioritization of university budgetary investments, and endeavor to avoid surprises even on minor matters to the extent possible.

Shared governance implies shared accountability. It is neither equitable or workable to demand shared governing power but declare that cost control or substandard performance in any part of Purdue is someone else's problem. We cannot improve low on-time completion rates and maximize student success if no one is willing to modify his schedule, workload, or method of teaching.

Participation in governance also requires the willingness to make choices. "More for everyone" or "Everyone gets the same" are stances of default, inconsistent with the obligations of leadership.

I love the phrase, inconsistent with the obligations of leadership.

Daniels recently left the governor's house in Indiana for the president's house at Purdue. His initial address is balanced, open, and forward-looking. It is respectful of what universities do and forthright about the need to recognize changes in the world around us, and to change in response.

My university is hiring a new president, too. Our Board of Regents will announce its selection tomorrow. It is probably too much to ask that we hire a new president with the kind of vision and leadership that Daniels brings to West Lafayette. I do hope that we find someone up to the task of leading a university in a new century.

My wife has been on a long-term substitute teaching assignment for the last few weeks. Yesterday, I ran across the following rubric used by one of the middle school teachers there to grade "scored discussions". The class reads a book, which they discuss as a group. Students are evaluated by their contribution to the discussion, including their observable behavior.

Productive behavior

• Uses positive body language and eye contact (5)
• Makes a relevant comment (1)
• Offers supporting evidence (2)
• Uses an analogy (3)
• Asks a clarifying question (2)
• Listens actively -- rephrases comment before responding (3)
• Uses good speaking skills -- clear speech, loud enough, not too fast (2)

Nonproductive behavior

• Not paying attention (-2)
• Interrupting (-3)
• Irrelevant comment (-2)
• Monopolizing (-3)

Most adults, including faculty, should be glad that their behavior is not graded according to this standard. I daresay that many of us would leave meetings with a negative score more often that we would like to admit.

I think I'll use this rubric to monitor my own behavior at the next meeting on my calendar.

I recently listened to a short clip from Seth Godin's book "The Dip". In it, he quotes Vince Lombardi as saying, "winners never quit, and quitters never win", and then says something to the effect of:

Winners quit all the time. They just quit the right stuff at the right time.

This reminded of my recent Good Ideas Aren't Always Enough, in which I talk briefly about Ward Cunningham's experience trying to create a universal mark-up language for wiki.

How did Ward know it was the right time to stop pushing for a universal mark-up? Perhaps success was right around the corner. Maybe he just needed a better argument, or a better example, or a better mark-up language.

Inherent in this sort of lesson is a generic variation of the Halting Problem. You can't be sure that an effort will fail until it fails. But the process may never fail explicitly, simply churning on forever. What then?

That's one of the problems with giving advice of the sort my entry gave, or of the sort that Godin gives in his book. The advice itself is empty, because the opposite advice is also true. You only know which advice is right in any given context after the fact -- if ever.

How did Ward know? I'm guessing a combination of:

• knowledge about the problem,
• experience with this problem and others like it,
• relationship with the community of people involved,
• and... a little luck.

And someone may come along some day with a better argument, or a better example, or a better mark-up language, and succeed. We won't know until it happens.

Maybe such advice is nothing more than platitude. Without any context, it isn't all that helpful, except as motivation to persevere in the face of a challenge (if you want to push on) or consolation in the face of a setback (if you want to focus your energy elsewhere). Still, I think it's useful to know that other people -- accomplished people -- have faced the same choice. Both outcomes are possible. Knowing that, we can use our knowledge, experience, and relationships to make choices that make sense in our current circumstances and live with the outcomes.

(I recently finished re-reading Straight Man, the 1997 novel by Richard Russo. This fantasy comes straight out of the book.)

Hank Devereaux, beleaguered chair of the English department, has been called in to meet with Dickie Pope, campus CEO. He arrives at Pope's office just as the CEO is wrapping up a meeting with chief of security Lou Steinmetz and another man. Pope says, "Hank, why don't you go on in and make yourself comfortable. I want to walk these fellas to the door." We join Devereaux's narration:

When I go over to Dickie's high windows to take in the view, I'm in time to see the three men emerge below, where they continue their conversation on the steps.... Lou's campus security cruiser is parked at the curb, and the three men stroll toward it. They're seeing Lou off, I presume, .... But when they get to the cruiser, to my surprise, all three men climb into the front seat and drive off. If this is a joke on me, I can't help but admire it. In fact, I make a mental note to employ a version of it myself, soon. Maybe, if I'm to be fired today, I'll convene some sort of emergency meeting, inviting Gracie, and Paul Rourke, and Finny, and Orshee, and one or two other pebbles from my shoe. I'll call the meeting to order, then step outside on some pretext or other, and simply go home. Get Rachel [my secretary] to time them and report back to me on how long it takes them to figure it out. Maybe even get some sort of pool going.

My relationship with my colleagues is nothing like Devereaux's. Unlike him, I like my colleagues. Unlike his colleagues, mine have always treated me with collegiality and respect. I have no reason to wish them ill will or discomfort.

Still. It is a great joke. And I imagine that there are a lot of deans and department chairs and VPs out there who harbor dark fantasies of this sort all the time, especially during those inevitable stretches of politics that plague universities. Even the most optimistic among us can be worn down by the steady drip-drip-drip of dysfunction. There have certainly been days this year when I've gone home at the end of a long week with a sense of doom and a desire for recompense.

Fortunately, an occasional fantasy is usually all I need to deflate the doom and get back to business. That is the voyeuristic allure of novels like Straight Man for me.

But there may come a day when I can't resist temptation. If you see me walking on campus wearing a Groucho Marx nose and glasses, all bets are off.

Jon Udell recently wrote about the real problem with automating work: most of us don't know how. The problem isn't with using particular tools, which come and go, but with recognizing the power of information networks and putting data into a form from which it can be leveraged.

I want to apply his advice more often than I do. I have found that for me it is not enough simply to learn the principles.

The first challenge is fighting an uphill battle against institutional inertia. The university provides too much of its data in dead-tree form, and what data comes to us in digital form comes unstructured. Despite a desire to increase efficiency and decrease costs, a university is a big, slow organization. It takes a long time for its many bureaucracies to re-make themselves. It also takes a persistent, pervasive effort to change on the parts of many people. Too many administrators and faculty thrive in a papered society, which makes change even harder. This is the broad base of people who need to learn Udell's core principles of information networks.

The second challenge is my own habits. I may not be of my students' generation, but I've been in computer science for a long time, and I think I get the value of data. Even still, it's easy -- especially as department head -- to be sucked into institutional habits. My secretary and I are combating this by trying to convert as much data entering our office as possible into live, structured data. In the process, I am trying to teach her, a non-computer scientist, a bit about the principles of data and structured representation. We aren't worrying yet about networks and pub/sub, simply getting data into a named, structured form that supports computational processing.

Yet I need to change some of my own habits, too. When under time pressure, it's easy for me to, say, whip up assignments of graduate assistants to tasks and lab hours on a legal pad. Once the assignments are made, I can communicate a subset of the information in a couple of e-mail messages. The result is a lot of information and not a byte of structured data. Oh, and a lot of lost opportunities for using code to check consistency, make changes, publish the assignments in multiple forms, or reuse the data in adapted form next semester.

My next big opportunity to practice better what I preach is scheduling courses for spring semester. Instead of using spreadsheets as we have in the past, perhaps I should open up Dr. Racket and use it to record all the data we collect and create about the schedule. Scheme's reliance on the simple list as its primary data structure usually puts me in the mindset of grammars and syntax-driven programming. Sometimes, the best way to break a bad old habit is to create a good new one.

So, yes, we need to teach the principles of data networks in a systematic way to information technologists and everyone else. We also need to practice applying them and look for ways to help individuals and institutions alike change their habits.

Another of the interviews I've read recently was The Rolling Stone's 1994 interview with Steve Jobs, when he was still at NeXT. This interview starts slowly but gets better as it goes on. The best parts are about people, not about technology. Consider this, on the source Jobs' optimism:

Do you still have as much faith in technology today as you did when you started out 20 years ago?

Oh, sure. It's not a faith in technology. It's faith in people.

Explain that.

Technology is nothing. What's important is that you have a faith in people, that they're basically good and smart, and if you give them tools, they'll do wonderful things with them. It's not the tools that you have faith in -- tools are just tools. They work, or they don't work. It's people you have faith in or not.

I think this is a basic attitude held by many CS teachers, about both technology and about the most important set of people we work with: students. Give them tools, and they will do wonderful things with them. Expose them to ideas -- intellectual tools -- and they will do wonderful things. This mentality drives me forward in much the same way as Jobs's optimism does about the people he wants to use Apple's tools.

I also think that this is an essential attitude when you work as part of a software development team. You can have all the cool build, test, development, and debugging tools money can buy, but in the end you are trusting people, not technology.

Then, on people from a different angle:

Are you uncomfortable with your status as a celebrity in Silicon Valley?

I think of it as my well-known twin brother. It's not me. Because otherwise, you go crazy. You read some negative article some idiot writes about you -- you just can't take it too personally. But then that teaches you not to take the really great ones too personally either. People like symbols, and they write about symbols.

I don't have to deal with celebrity status in Silicon Valley or anywhere else. I do get to read reviews of my work, though. Every three years, the faculty of my department evaluate my performance as part of the dean's review of my work and his decision to consider for me another term. I went through my second such review last winter. And, of course, frequent readers here have seen my comments on student assessments, which we do at the end of each semester. I wrote about assessments of my spring Intelligent Systems course back in May. Despite my twice annual therapy sessions in the form of blog entries, I have a pretty good handle on these reviews, both intellectually and emotionally. Yet there is something visceral about reading even one negative comment that never quite goes away. Guys like Jobs probably do there best not to read newspaper articles and unsolicited third-party evals.

I'll have to try the twin brother gambit next semester. My favorite lesson from Jobs's answer, though, is the second part: While you learn to steel yourself against bad reviews, you learn not to take the really great ones too personally, either. Outliers is outliers. As Kipling said, all people should count with you, but none too much. The key in these evaluations to gather information and use it to improve your performance. And that most always comes out of the middle of the curve. Treating raves and rants alike with equanimity keeps you humble and sane.

Ultimately, I think one's stance toward what others say comes back to the critical element in the first passage from Jobs: trust. If you trust people, then you can train yourself to accept reviews as a source of valuable information. If you don't, then the best you can do is ignore the feedback you receive; the worst is that you'll damage your psyche every time you read them. I'm fortunate to work in a department where I can trust. And, like Jobs, I have a surprising faith in my students' fairness and honesty. It took a few years to develop that trust and, once I did, teaching came to feel much safer.

Last week, I wrote an entry on managers and communication motivated by some of the comments John Lilly, formerly of Mozilla, made in an interview with Fast Company. In the same interview, Lilly mentioned teaching in a couple of ways that made me think about that part of my job.

... what's the difference between leadership and management?

For me, leadership is imagining the world that you want and figuring out how to go make it that way and how to get other people to help you. That happens sort of all up and down the spectrum of people. Teachers do that every day.

There is certainly an element of leadership in how our best teachers reach students. The K-12 education world talks a lot about this sort of thing, but that discussion often seems to lack much connection to the content of the discipline being taught. University educators work at the intersection of instruction and leadership in a way that other teachers don't. To me, this makes college teaching more interesting and sometimes more challenging. As with so many other things, simply recognizing this is a great first step toward doing a better job. In what ways am I as an instructor of, say, programming languages a leader to my students?

One part of the answer surfaces later in the article (emphasis added):

I've been interviewing a lot people for jobs ... lately. I've been struck by how strongly their first job imprints them. People who went to Google out of school have a certain way of talking and thinking about the world, people who went to Amazon, have a different way thinking about it, Facebook a different way. ...

... You just start to see patterns. You say, "Oh, that's an Amazon construct," or "that's totally a Googley way to look at the world." ...

From an organizational leadership point of view, you should think hard about what your organization is imprinting on people. Your company, hopefully, will be huge. But what you imprint on people and the diaspora that comes out of your company later may or may not be an important and lasting legacy.

Most companies probably think about what they do as about themselves; they are creating an organization. The tech start-up world has reminded us just how much cross-pollination there can be in an industry. People start their careers at a new company, learn and grow with the company, and then move on to join other companies or to start new ones. The most successful companies create something of a diaspora.

Universities are all about diaspora. Our whole purpose is to prepare students to move on to careers elsewhere. Our whole purpose is to imprint a way of thinking on students.

At one level, most academics don't really think in this way. I teach computer science. I'm not "imprinting" them; I am helping them learn a set of ideas, skills, and practices. It's all about the content, right?

Of course, it's not quite so simple. We want our graduates to know some things and be able to do some things. The world of CS is large, and in a four-year undergrad program we can expose our students to only a subset of that world. That choice is a part of the imprint we make. And the most important thing we can leave with our students is an approach to thinking and learning that allows them to grow over the course of a long career in a discipline that never sits still. That is a big part of the imprint we make on our students, too.

As members of a computer science faculty, we could think about imprinting as an organization in much the way Lilly discusses. Can someone say, "That's a totally UNI Computer Science way of thinking"? If so, what is that way of thinking? What would we like for it mean? Are our alumni and their employers served well by how we imprint our students?

As a department head, I have a chance to talk to alumni and employers frequently. I usually hear good things, but that's not so surprising. Our department might be able to improve the job we do by thinking explicitly up front about our imprint we hope to have on students, a form of starting at the end and working backwards.

As a teacher, I often think about how students approach problems after they have studied with me. Thinking about the idea of my "imprint" on them is curious. Can someone say, "That's a totally Professor Wallingford way of thinking"? If so, would that be good thing? How so? If so, what does "totally Wallingford way of thinking" mean to my students now? What would I like for it mean?

This line of thinking could be useful to me as I begin to prepare my fall course on programming languages. Without thinking very long, I know that I want to imprint on my students a love for all kinds of languages and an attitude of openness and curiosity toward learning and creating languages. What more?

Everybody's so different / I haven't changed. -- Joe Walsh

A couple of weeks ago, lots of people were commenting on an interview with John Lilly, the former CEO of Mozilla. Lilly talks about how he had to learn to be a manager, having started his career as an engineer and developer. As a computer scientist who has been working as a department head for six years, I have first-hand experience with the task he faced. I also recognize some of the specific lessons he learned.

For example, when you become a manager, even a technical lead on a team of developers, your relationship with your co-workers changes. I blogged about my first encounters with this change within weeks of becoming head. Later, I began to notice that faculty interpreted things I said differently than I intended them. Lilly had a similar experience:

When the founder says, "Why don't you make button a little more orange?" it somehow has more meaning than an individual contributor saying that. Now, that's not how I meant it. I meant it as an individual contributor.

As you get more and more responsible for the organization and people, you can start projects with throwaway comments.

Several years ago, I experienced this effect in a slightly different form. I asked several faculty members to meet with me about some department issue. I suggested a specific time for the meeting and asked if anyone had conflicts with that time. Someone wrote to say that he had another committee meeting that overlapped the beginning of my proposed meeting. His committee meeting sounded like one of those standing meetings that we all have to attend but don't enjoy, so I asked if he'd be willing to leave it early and come to ours.

He never got back to me but later cc:ed me on a note to the committee in which he told them he would not be able to make that meeting. I saw from the quoted text in the note that the committee discussion could be important to our department. I went down to his office and told him that he should go to his committee meeting, that we could schedule our meeting at a different time. He said that he had interpreted my question as a suggestion to skip the other meeting.

Certainly, I was inartful in asking if he could leave the other meeting early. My inexperience showed through. Even so, I was surprised when he said that he had interpreted my question as an instruction or hint. I remember vividly thinking to myself:

Sometimes, a question is a question.

From that experience, I learned that I needed to be more careful. Sometimes, a question really is just a question, but the listener may not know that. There are all kinds of cases in everyday communication where this is true, harmless and standard speech acts that differ from the words actually used. The risk of a misinterpretation goes up whenever there is an imbalance of power between the participants, whether real or perceived. For better or worse, when I became head, such a gap became part of many conversations I have with my colleagues. I may not have changed, but the circumstances have.

Something similar exists between instructors and students, of course. But as instructor I've always been more aware of the potential problem. That seems easier, because everyone expects there to be an imbalance of power between instructors and students. I wasn't prepared for this to happen to me and the people I had been working with as equals, some for more than a decade. This was tough on me emotionally for a while.

Once I recognized what was going on, I found ways to reduce the risk of misunderstanding. Sometimes, it's as simple as making the intention of a statement or question explicit. Other times, I have to hold a message back and re-think what I intend and how to achieve that goal. In this sense, being an administrator for a few years has probably helped me to communicate more effectively. (I wonder if my wife thinks this, too!)

Lilly learned similar lessons:

Over time, I discovered a couple of things--both aimed at reducing these effects. Number one, I went out of my way to explain the context in which I was making the comment. I'd say, "Look, I'm going to say some things, but this is not the CEO talking or not the founder talking. This is a guy who likes design or this is a guy who uses products. Please understand it in that context."

The second thing is I started noticing my interactions in the hallway. I'm an engineer by background and a bit of an introvert naturally. When I walk between meetings, I think about things. A lot times I'll be looking down my phone or looking down at the floor while I think things through. It's sort of a natural engineer behavior, but it's pretty off-putting if your CEO walks by you and doesn't look up and notice you.

Once we start noticing our interactions and thinking about them from both sides, we can start to better. Software developers are pretty good at analyzing and solving problems. What comes naturally to us isn't always the most effective way to behave when our role changes. But we can study the world more closely and choose to act differently. Changing habits is always a challenge, but with conscious effort and perseverance, we can do it. If if you want to have a larger effect on the world than writing code can do alone, sometimes you must.

Sometimes I find it hard to tell someone 'no',
but I rarely regret it.

I have been thinking a lot lately about the Hell Yeah! or No mindset. This has been the sort of year that makes me want to live this way more readily. It would be helpful when confronting requests that come in day to day, the small stuff that so quickly clutters a day. It would also be useful when facing big choices, such as "Would you like another term as department head?"

Of course, like most maxims that wrap up the entire universe in a few words, living this philosophy is not as simple as we might like it to be.

The most salient example of this challenge for me right now has to do with granularity. Some "Hell Yeah!"s commit me to other yesses later, whether I feel passionate about them or not. If I accept another term as head, I implicitly accept certain obligations to serve the department, of course, and also the dean. As a department head, I am a player on the dean's team, which includes serving on certain committees across the college and participating in college-level discussions of strategy and tactics. The 'yes' to being head is, in fact, a bundle of yesses, more like a project in Getting Things Done than a next action.

Another thought came to mind while ruminating on this philosophy, having to do with opportunities. If I do not find myself with the chance to say "Hell Yeah!" very often, then I need to make a change. Perhaps I need to change my attitude about life, to accept the reality of where and who I am. More likely, though, I need to change my environment. I need to put myself in more challenging and interesting situations, and hang out with people who are more likely to ask the questions that provoke me to say "Hell Yeah!"

A cautionary note from John Ruskin, in The Stones of Venice:

We are to take care how we check, by severe requirement or narrow caution, efforts which might otherwise lead to a noble issue; and, still more, how we withhold our admiration from great excellencies, because they are mingled with rough faults.

Ruskin was a permission giver.

I found this passage in The Seduction, an essay by Paula Marantz Cohen. Earlier in the piece, she related that many of her students were "delighted" by Ruskin's idea that "the best things shall be seldomest seen in their best form". The students...

... felt they were expected to be perfect in whatever it was they undertook seriously (which might be why they resisted undertaking much seriously).

In the agile software development world, we recognize that fear even short of perfectionism can paralyze developers, and we take steps to overcome the danger (small steps, tests first, pair programming). We teachers need to remember that our high school and college students feel the same way -- and that their feelings are often made even more formidable by the severe requirement and narrow caution by which we check their efforts.

Marantz closes her essay by anticipating that other professors might not like her new approach to teaching, because it "dumbs things down" with shorter reading assignments, shorter writing assignments, and classroom discussion that allows personal feelings. It seems to me, though, that getting students to connect with literature, philosophy, and ideas bigger than themselves is an important win. One advantage of shorter writing assignments was that she was able to give feedback more frequently and thus focused more directly on specific issues of structure and style. This is a positive trade-off.

In the end she noted that, despite working from a much squishier syllabus and with a changing reading list, students did not complain about grades. Her conclusion:

I suspect that students focus on grades when they believe that this is all they can get out of a course. When they feel they have learned something, the grade becomes less important.

I have felt this, both as student and as teacher. When most of the students in one of my classes are absorbed in their grade, it usually means that I am doing something wrong with the class.

Go forth this week and show admiration for the great excellencies in your students, your children, and your colleagues, not only despite the excellencies being mingled with rough faults, but because they are so.

It is easy for me to get sucked into a mindset in which I equate myself with what I do. In Five Lies I No Longer Believe, Todd Henry writes:

I am not my work, and I am especially not defined by how my work is received. That is not an excuse for laziness; it's permission to engage fully and freely and to bless everyone I encounter without worrying about what they think of me. This is hard medicine to swallow in a culture that celebrates title and the little spaces we carve for ourselves in the marketplace. Not me, not any longer.

"I am what and whom and how I teach."

"I am the programs I create, the papers I write, the grants I receive."

"I am the head of the department."

It is dangerous to think this way when I fail in any one of these arenas. It undervalues who I am and what I can offer. It closes my eyes to other parts of my life.

It is also dangerous to think this way when I succeed. Even in success, this view diminishes me. And it creates an endless cycle of having to succeed again in order to be.

When we think we are what we do, we often constrain our actions based on what other people will think of us. That makes it hard to teach the hard truths, to make tough decisions, to lead people. It makes it hard to create things that matter.

Even if we tune out what other people think, we find that we are always judging ourselves. This is as restrictive and as counterproductive as worrying about other peoples' idea of us.

Having different roles in life and doing different kinds of things can help us avoid this trap. Activity, success, and failure in one arena are only a part of who we are. We have to be careful, though, not to equate ourselves with our the sum of our activities, successes, and failures in all these areas. Whatever that sum is, we are more.

All those things for which
we have no words are lost.
-- Annie Dillard, "Total Eclipse"

My family and I spent eight days on the road last week, with a couple of days in the Jamestown/Williamsburg area of Virginia and then a few days in Washington, D.C. I'd never spent more than a couple of hours in my nation's capital and enjoyed seeing the classic buildings in which our leaders work and the many monuments to past leaders and conflicts.

The Korean War Veterans Memorial caught me by surprise. No one ever talks about this memorial, much like the war itself. I had no idea what it looked liked, no expectations. When we came upon it from the rear, I became curious. Standing amid the soldiers trudging through a field, I was unnerved. They look over their shoulders, or they make eye contact with one another, or they stare ahead, blankly. This is no sterile monument of while limestone. It is alive, even as it reminds us of men who no longer are. When we reached the front of the memorial, we saw a wreath with a note of thanks from the Korean people. It brought tears to my eyes, and to my daughter's.

As touched as I was by the National Mall, most of my memories of the trip are of artwork we saw in the several galleries and gardens. I came to remember how much I like the paintings of Monet. This time, it was his "The Seine at Giverny" that gave me the most joy. I learned how much I enjoy the work of Camille Pissarro, another of the French impressionists who redefined what a painting could be and say in the 1800s. I even saw a few abstract pieces by Josef Albers, whom I quoted not long ago. That quote came back to me as I walked amid the creations of men, oblivious to computer programming and the debits and credits of department budgets. What happens happens mostly without me. Indeed.

I left Washington with a new inspiration, Hiroshi Sugimoto. My daughter and I entered one of the gallery rooms to find a bunch of canvasses filled with blacks, grays, and whites. "More modern nothingness," I thought at first. As we absorbed the images, though, one of us said out loud, "These look like pictures of the ocean. See here...?" We looked closer and saw different times of day, different clouds and fog, horizons crisp and horizons that were no more than imperceptible points on a continuum from dark ocean to light sky. Only upon leaving the room did we learn that these images were in fact seascapes. "This is modern art that works for me," said my daughter. I nodded agreement.

Sugimoto's seascapes are only one element of his work. I have many more of his images to discover.

I did not get through my eight days away without any thoughts of computer science. In the National Gallery of Art, we ran across this piece by Edward Ruscha, featured here:

I vaguely recall seeing this image many years ago in a blog post at Lemonodor, but this time it grabbed me. My inner programmer was probably feeling the itch of a few days away from the keyboard. Perhaps Ruscha has an his own inner programmer. When I did a Google Image search to find the link above, I found that he had also created works from the words 'self' and 'ruby'. We programmers can make our own art using Lisp, Self, and Ruby. Our art, like that of Monet, Pissarro, Sugimoto, and Ruscha, sustains us.

Recently I shared my fixation with a tweet from Kevin Rutherford about replacing unnecessary weekly meetings with ad-hoc stand-up meetings and a status wall. I have been imagining how I might do something similar with faculty meetings. Most CS faculty prefer to work on the courses, their research, and their outreach activities than to go to business meetings. Perhaps there is a better way.

Not all meetings are created equal. What sort of meetings are there, and which could be replaced with other mechanisms? I like Keith Ray's taxonomy from a message to the XP list nearly a year ago (June 15, 2009):

• meetings to make decisions
• meetings to gather and disperse information
• meeting with no decisions, not much information, and no collaboration

The first two types are the kind of meetings worth holding. Sure, some decisions can be made by e-mail or some other technology, with a little straightforward discussion followed by the sending of votes. We can also share a lot of information, using e-mail, wikis, and various collaboration tools. Whenever I can, I ask the faculty to make decisions via e-mail. This works well for decisions with a narrow range of well-understood alternatives, where the decision does not require the group to find any new common ground. I also try to disseminate as much information from outside the department as I can via e-mail, mostly where the new information isn't likely to lead to a wider discussion that we might want or need to have. Finally, I try to collect as much information from the faculty as I can without holding meetings. Sometimes this data can be assembled and either used by me or passed on to outside agents without need for us to meet.

But even agile software developers recognize the need for meetings to make decisions and to gather or disperse information. We hold collaborative meetings for tasks such as release planning and iteration planning, in which we make decisions about the work we want and need to do in the short term. We hold short daily stand-ups meetings and conduct periodic retrospectives of our work, in which we share information about our progress and gather communal information that helps us to improve how we work individually and as a team.

All of these meetings are valuable, even necessary, and sometimes enjoyable. The key distinction between these meetings and the meetings that people usually complain about is that they are collaborative, with everyone participating in the conversation, with decisions actually being made (not just handed down from above), and with everyone's learning being fed back into the system to make it work better.

I do my best to limit most of the meetings I call to these two categories, and try never to call a meeting with no decisions, no information to share that requires discussion, and no collaboration. I am pretty confident that our meetings aren't legacies that originally had a purpose but now only fill a time slot. In fact, we don't meet weekly any more because we all could see that there was not enough business to keep us busy every week. Of course, if we all got excited about long-term planning, we could meet and talk every week but that is not the nature of our faculty.

All that said, I still wonder whether we could be more productive and happier with something like what Rutherford describes. Focus whenever possible on small, frequent releases, and track progress in as visible and obvious a way as possible. Meet briefly and collaboratively when maximum value comes from meeting, not not meeting.

There are limits to how far one can take this approach in a large bureaucracy like a university. Mandates come from above that require collective discussion and decision, even when we in the department have little interest in the issue, perhaps even an active disinterest. But that should not distract us from doing the best we can with what we do control. As legendary teacher and coach John Wooden used to say, there is no point in worrying about what you don't control; that only steals energy and time from accomplishing as much as you can with what you do control. So, we should try to be as agile as we can!

Early this morning, @kevinrutherford tweeted:

Permanently replaced a 10-person 1-hour weekly meeting with an ad-hoc stand-up and a status wall #win

I couldn't get this message out of my mind all day. On a very small scale, daily stand-up meetings did just what they needed to do in my recent agile development course: keep team members apprised of what everyone was accomplishing and, occasionally, what stood in peoples' way. A story board and a somewhat lame burndown chart put the daily reports in context. I can see how this approach works so well with agile teams, especially ones with open, steady communication channels and a lot of trust.

Many people like to group meetings into categories, but my experience as university department head says that, when it comes to meetings, there are also two kinds of people: those who like them and get things done via them, and those who don't. My snarkiest faculty colleagues and software developer friends will label these groups "those who waste time" and "those who get real work done", but that's not fair. I've had to participate in a lot of meetings on campus over the last five years, with faculty, staff, and administrators at various levels of the organization chart. I've had to chair my my fair share as well. I bump into many of the same people over and over again on different committees, and it's clear that many of those people have found ways to make such meetings productive, even helpful checkpoints in the doing of real work. Some even enjoy the meetings.

How can this be? Are my snarky colleagues right, and the people who enjoy meetings are simply killing time that could be spent better elsewhere? I don't think so. Different people in the organization are assigned different tasks. When the task requires the synthesis of an understanding or a plan that will be held in common across a large organization, it requires collaboration. When it requires compromise among strongly-held competing viewpoints of the world, it requires conversation -- and sometimes lots of it. I have found that it is a good thing that different people in the organization have different working styles, because without them a lot of this sort of work would never get done. In the end, this comes down to more than different working styles. Different people have different values, and different ways they hope to contribute to the group's success.

Paul Graham commented in one of his essays that meetings are easy work compared to the challenge of making things. As a creator of programs and a writer of blog entries, I know what he means. I rarely exercise my intellect in a meeting the way I exercise it while trying to figure out if the accounts in my bookkeeping software should be composite objects, or if composite debit/credit values will suffice. But sometimes a meeting can prepare me to tackle a tough writing task, such as drafting a report to the president that conveys a strong plan for moving his IT operation forward. When a task falls inside the bounds of a group's common values and beliefs, meetings often are not necessary. When they fall outside the intersection, people need to talk to one another. The conversation is itself part of the work that needs to be done.

The reason Rutherford's tweet won't leave me alone is that I keep fantasizing what it would be like to replace all or even some of my department's faculty meetings with something more agile. Our nine-person faculty usually meets bi-weekly for an hour or so. Most everyone grumbles at having to meet, even when we have decisions to make. If we could replace even half our meetings with an occasional ad-hoc stand-up meeting and a status wall that kept us all on track doing what we needed to do, what a glorious #win that be!

Now, to figure out which meetings to replace, and how...

My mailbox this morning contained a long complaint from a student about a grade, a request to meet with a faculty member about an issue he didn't handle well this spring, a request for space for summer undergrad research, news that a student hold has been cleared so that a summer course can be created, a spreadsheet of my department's fiscal year-to-date spending for end-of-year planning, calls from upper administration for work on student outcomes assessment, merit pay evaluations, and year-end faculty evaluation letters, and several dozen miscellaneous messages. That doesn't count mailing-list mail, both professional and personal, which is procmailed into separate boxes. Such is the life of a department head.

I also received from a student a link to a negative review of git. I am considering using distributed VCS in my agile course, with git and Mercurial at the top of the list. Do you have a suggestion? Mercurial has been around longer, I think, and there are some good tutorials on it. My students need to get up to speed relatively quickly with the basic use cases of whatever tool we use, for a team of ten doing XP-style development.

After two days of class, I feel pretty good about the prospects of this group of ten students. They seem willing to collaborate and eager to learn. We are taking to heart the agile value "Responding to change over following a plan", with a change to Ruby as our working language and (git | Mercurial) as our VCS. This means I get to be agile, too, as I prepare some new course materials built around Ruby, Test::Unit, and so on. I'll be looking into RubyMine as an IDE with refactoring support. Do you have any experience using it? Let me know.

[A transcript of the SIGCSE 2010 conference: Table of Contents]

Some more miscellaneous thoughts from a few days at the conference...

Deja Vu All Over Again

Though it didn't reach the level of buzz, concurrency and its role in the CS curriculum made several appearances at SIGCSE this year. At a birds-of-a-feather session on concurrency in the curriculum, several faculty talked about the need to teach concurrent programming and thinking right away in CS1. Otherwise, we teach students a sequential paradigm that shapes how they view problems. We need to make a "paradigm shift" so that we don't "poison students' minds" with sequential thinking.

I closed my eyes and felt like I was back in 1996, when people were talking about object-oriented programming: objects first, early, and late, and poisoning students' minds with procedural thinking. Some things never change.

Professors on Parade

How many professors throw busy slides full of words and bullet points up on the projector, apologize for doing so, and then plow ahead anyway? Judging from SIGCSE, too many.

How many professors go on and on about importance of active learning, then give straight lectures for 15, 45, or even 90 minutes? Judging from SIGCSE, too many.

Mismatches like these are signals that it's time to change what we say, or what we do. Old habits die hard, if at all.

Finally, anyone who thinks professors are that much different than students, take note. In several sessions, including Aho's talk on teaching compilers, I saw multiple faculty members in the audience using their cell phones to read e-mail, surf the web, and play games. Come on... We sometimes say, "So-and-so wrote the book on that", as a way to emphasize the person's contribution. Aho really did write the book on compilers. And you'd rather read e-mail?

I wonder how these faculty members didn't pay attention before we invented cell phones.

An Evening of Local Cuisine

Some people may not be all that excited by Milwaukee as a conference destination, but it is a sturdy Midwestern industrial town with deep cultural roots in its German and Polish communities. I'm not much of a beer guy, but the thought of going to a traditional old German restaurant appealed to me.

My last night in town, I had dinner at Mader's Restaurant, which dates to 1902 and features a fine collection of art, antiques, and suits of medieval armour "dating back to the 14th century". Over the years they have served political dignitaries such as the Kennedys and Ronald Reagan and entertainers such as Oliver Hardy (who, if the report is correct, ate enough pork shanks on his visit to maintain his already prodigious body weight).

I dined with Jim Leisy and Rick Mercer. We started the evening with a couple of appetizers, including herring on crostinis. For dinner, I went with the Ritter schnitzel, which came with German mashed potatoes and Julienne vegetables, plus a side order of spaetzele. I closed with a light creme brulee for dessert. After these delightful but calorie-laden dishes, I really should have run on Saturday morning!

Thanks to Jim and Rick for great company and a great meal.

Time to blog has been scarce, with the beginning of an unusual semester. I am teaching two courses instead of one, and administrative surprises seem to be arriving daily, both inside the department and out. Teaching gives me energy, but most days I leave for home feeling a little humbler than I started -- or a little less satisfied with state of affairs.

Perhaps this is why a particular passage from an entry on urban planning policy at The Urbanophile keeps coming to mind. It offers a lesson for urban policy based on the author's reading of Dietrich Dörner's The Logic of Failure (a new addition to my must-read list):

The first [lesson] is simply to approach urban policy and urban planning with humility and rich understanding of the limits of what we can accomplish. This I think is desperately needed. There are so many policies out there that are promoted with almost messianic zeal by their advocates.

One person's messianic zeal, unfettered from reality, is a dangerous force. It can wear out even a resolute team; when coupled with normal human frailty, the results can destroy opportunities for progress.

Another passage from the same blog has had a more personal hold on me of late:

People with talent, with big dreams and ambitions, want to live in a place where the civic aspiration matches their personal aspirations.

Sense of place and sense of self are hard to separate. This is true for cities -- the great ones capitalize on the coalescence of individual and communal aspiration -- and for academic departments.

Last spring, a colleague commented that he didn't think our department spent enough time trying to be great. This made me sad, but it struck me as true. At the time, I wasn't sure how to respond.

All groups have their internal politics. Some political situations are short-lived; others are persistent, endemic. We are no different, and maybe even above average. (Someone has to be!) Political struggles take time and energy. They steal focus.

I think everyone in our group desires to be great. Unfortunately, that's the easy part. For a group to achieve greatness, individuals must work together in a common direction. In our group, it is hard to build consensus on a shared vision. I don't pretend that once we share a vision that greatness will come easily, but it's hard to get anywhere unless everyone is trying to go to the same place -- or at least is using the same criteria for progress.

As for me, in my role as department head, I have not always found -- or created -- the will, the energy, or the tools I need to help us move confidently in the direction of greatness. So, at times, we seem to settle, working locally but not globally.

This train of thought reminds me of a couple of comments James Shore made about stumbling through mediocrity in the context of agile software development:

The emphasis [in the software world] has shifted from "be great" to "be Agile." And that's too bad. As much as I like it, there's really no point in Agile for the sake of Agile.

The point is to be great, or perhaps more accurately, to do great things. Agile approaches are a path, not a destination.

I want to work with people who want to be great. People who aren't satisfied just fitting in. People who are willing to take risks, rock the boat, and change their environment to maximize their productivity, throughput, and value.

One of the things that has surprised me so much about group dynamics since I joined a faculty and perhaps more so since I've been in the position of head is the enormous role that fear plays in how individuals work and interact with one another. It takes courage to take risks, to rock the boat, and to change the environment in which we live and work. It takes courage to be honest. It takes courage to take an action that may make a colleague or supervisor unhappy.

Without courage, especially at key moments, opportunities pass, sometimes before they are even recognized.

I have experienced this in how I interact with others, and occasionally I observe it how colleagues interact with me and others. I never thought that this would be a major obstacle on my path to greatness, or my department's.

(For what it's worth, Shore's second passage also describes the kind of students I like to work with, too. If it is hard for experienced adults to have this sort of gumption, imagine how much tougher an expectation it is to have of young people who are just learning how to step out into the world. Fortunately, as teachers, we have an opportunity to help students grow in this way.)

Today brought high contrast to my daily duties.

I spent my morning preparing a talk on computer science, careers, and job prospects for an audience of high school counselors from around the state. Then I gave the talk and lunched with them. Both prep and presentation were a lot of fun! I get to take some element of computer science and use it as a way to communicate how much fun CS and why these counselors should encourage their students to consider CS as a major. Many of the adults in my audience were likely prepared for the worst, to be bored by a hard topic they don't understand. Seeing the looks in their eyes when they saw how an image could be disassembled and reassembled to hide information -- I hope the look in my eyes reflected it.

Early afternoon found me working on next semester's schedule of courses and responding to requests for consultations on curricular changes being made by another department. The former is in most ways paperwork, seemingly for paperwork's sake. The latter requires delicate language and, all too frequently, politics. Every minute seems a grind. This is an experience of getting caught up in stupid details, administration style.

I ended the day by visiting with a local company about a software project that one of our senior project courses might work on. I learned a little about pumps and viscosity and flow, and we discussed the challenges they face in deploying an application that meets all their needs. Working on real problems with real clients is still one of the great things about building software.

Being head of our department has brought me more opportunities like the ones that bookended my day, but it has also thrust me into far too many battles with paperwork and academic process and politics like the ones that filled the in-between time. After four-plus years, I have not come to enjoy that part of the job, even when I appreciate the value it can bring to our department and university when I do it well. I know it's a problem when I have to struggle to maintain my focus on the task at hand just to make progress. Such tasks offer nothing like the flow that comes from preparing and giving a talk, writing code, or working on a hard problem.

A few months ago I read about a tool called Freedom, which "frees you from the distractions of the internet, allowing you time to code, write, or create." (It does this by disabling one's otherwise functional networking for up to eight hours.") I don't use Freedom or any tool like it, but there are moments when I fear I might need one to keep doing my work. Funny, but none of those moments involve preparing and giving a talk, writing code, or working on a hard problem.

Tim Bray said it well:

If you need extra mental discipline or tool support to get the focus you need to do what you have to do, there's nothing wrong with that, I suppose. But if none of your work is pulling you into The Zone, quite possibly you have a job problem not an Internet problem.

Fortunately, some of my work pulls me into The Zone. Days like today remind me how much different it feels. When I am mired in a some tarpit outside of the zone, it's most definitely not an Internet problem.

Via Jason Yip, this dandy story from a hospital president who favors process improvement Lean-style. It features Hideshi Yokoi, who is president of a Toyota production system support center in Kentucky:

... At one point, we pointed out a new information system that we were thinking of putting into place to monitor and control the flow of certain inventory. Mr. Yokoi's wise response, suggesting otherwise, was:

"When you put problem in computer, box hide answer. Problem must be visible!"

I have had many experiences, both personal and professional, in which putting something in a computer hides the problem from view and complicates finding the answer. Too often, when I decide to improve my process by putting data into my computer, I get so caught up in the rest of my tasks that I forget all about the problem. Tasks to do get lost in an ever-growing text file. Concerns about how we allocate merit pay get lost behind complex formulas in a spreadsheet that implement our current method. Scheduling and budget issues are lost in the last-minute details of readying this semester's spreadsheet for the next step in a university we don't control.

When you lose sight of a problem, it's hard to solve it. Moving things out of the daily clutter too easily becomes moving them out of our attention altogether.

I agree with Mr. Yokoi. A problem must be visible! But that cannot mean not using technology to automate and improve a process. Instead it means that we have to find ways to make the problem visible. JUnit was, for me, a great model. We needed to improve how we tested our programs, so we make the tests code. Rather than leave that code sitting lonely on disk, no better than textual documentation, we use a tool that runs the tests for us and tells what passes and what fails. Rather than leave that tool sitting lonely on disk, gathering dust because we forget to run the tests, we build running the tool into our development tools, where the tests can be run every time we save our changes or build our program. Make things visible.

We can avoid much of Mr. Yokoi's valid concern by changing our tools and our practices to ensure that problems don't disappear when we automate processes. That allows us to use computers to make us better.

I have been reading David Ogilvy's Confessions of an Advertising Man. I have found it to be quite enjoyable. It is a slim volume, written charmingly in a style we don't see much anymore. It is about not only advertising but also leading a team, creating and guiding an organization, and running a business. There are elements of all these is my job as department head, and even as a faculty member. Many of Ogilvy's essons won't surprise you; he recommends the old-fashioned virtues. Hard work. Quality. Fairness. Honesty. Integrity. High standards. Candor.

Ogilvy describes how to build and run a great agency, but at heart he is a great believer in the individual, especially when it comes to creative acts:

Some agencies pander to the craze for for doing everything in committee. They boast about "teamwork" and decry the role of the individual. But no team can write an advertisement, and I doubt whether there is a single agency of any consequence which is not the lengthened shadow of one man.

I sometimes wonder whether greatness can be achieved by a group of competent or even above-average individuals, or if an outstanding individual is an essential ingredient. In an advertising agency, there are the somewhat distinct acts of creating campaigns and running the agency. Perhaps the latter is more amenable to being led by a team. But even when it comes to great works, I am aware that teams have produced excellent software. How much of that success can be attributed to the vision and leadership of one individual on the team, I don't know.

As I mentioned at the top of a recent entry, a university task force I chaired submitted its final report at the beginning of July. After working so long with this group, I am feeling a little seller's remorse. Did we do a good enough job? If acted upon, will our recommendations effect valuable change? Can they be acted upon effectively at a time of budget uncertainties? The report we wrote does not advocate revolutionary change, at least not on the surface. It is more about creating structures and practices that will support building trust and communication. In a community that has drifted in recent years and not always had visionary leadership, these are prerequisites to revolutionary changes. Still, I am left wondering what we might have done more or differently.

The report is most definitely the product of a committee. I suspect that several of the individuals in the group might well have been able to produce something as good or better by working solo, certainly something with sharper edges and sharper potential -- at higher risk. Others on the group could not have done so, but that was not the nature of their roles. In the end, the committee rounded off the sharp edges, searched for and found common ground. The result is not a least common denominator, but it is no longer revolutionary. If that sort of result is what you need, a committee is not your best agent.

Part of my own remorse comes back to Ogilvy's claim. Could I have led the group better? Could I have provided a higher vision and led the group to produce a more remarkable set of recommendations? Did I cast a long enough shadow?

~~~~

The shadows of summer are lengthening. One of the reasons that I have always liked living in the American Midwest is the changing of the seasons. Here we have not four seasons but eight, really, as the blending of summer to autumn, or winter to spring, each has its own character. Academia, too, has its seasons, and they are part of what attracted me to professional life at a university. From the outside looking in, working in industry looked like it could become monotonous. But the university offers two semesters and a summer, each with a brand new start, a natural life, and a glorious end. Whatever monotony we experience happens at a much larger time scale, as these seasons come and go over the years.

Like the weather, academia has more than the obvious seasons we name. We have the break between semesters over Christmas and New Year's Day, a short period of change. When school ends in May, it is like the end of the year, and we have a period of changing over to a summer of activity that is for many of us much different than the academic year. And finally, we have the transition between summer and the new academic year. For me, that season begins about now, on the first day of August, as thoughts turn more and more to the upcoming year, the preparation of classes, and the return of students. This is a change that injects a lot of energy into our world and saves us from any monotony we might begin to feel.

So, as the long shadows of summer begin to fall, we prepare for the light of a new year. What sort of shadow will I cast?

As I mentioned last time, this week I am getting back to some regular work after mostly wrapping up a big project, including cleaning off my desk. It is cluttered with a lot of loose paper that the Digital Age had promised to eliminate. Some is my own fault, paper copies of notes and agendas I should probably find a way to not to print. Old habits dies hard.

But I also have a lot paper sent to me as department head. Print-outs; old-style print-outs from a mainframe. The only thing missing from a 1980s flashback is the green bar paper.

Some of these print-outs are actually quite interesting. One set is of grade distribution reports produced by the registrar's office, which show how many students earned As, Bs, and so on in each course we offered this spring and for each instructor who taught a course in our department. This sort of data can be used to understand enrollment figures and maybe even performance in later courses. Some upper administrators have suggested using this data in anonymous form as a subtle form of peer pressure, so that profs who are outliers within a course might self-correct their own distributions. I'm ready to think about going there yet, but the raw data seems useful, and interesting in its own right.

I might want to do more with the data. This is the first time I recall receiving this, but in the fall it would be interesting to cross-reference the grade distributions by course and instructor. Do the students who start intro CS in the fall tend to earn different grades than those who start in the spring? Are there trends we can see over falls, springs, or whole years? My colleagues and I have sometimes wondered aloud about such things, but having a concrete example of the data in hand has opened new possibilities in my mind. (A typical user am I...)

As a programmer, I have the ability to do such analyses with relatively straightforward scripts, but I can't. The data is closed. I don't receive actual data from the registrar's office; I receive a print-out of one view of the data, determined by people in that office. Sadly, this data is mostly closed even to them, because they are working with an ancient mainframe database system for which there is no support and a diminishing amount of corporate memory here on campus. The university is in the process of implementing a new student information system, which should help solve some of these problems. I don't imagine that people across campus will have much access to this data, though. That's not the usual M.O. for universities.

Course enrollment and grade data aren't the only ones we could benefit from opening up a bit. As a part of the big project I just wrapped up, the task force I was on collected a massive amount of data about expenditures on campus. This data is accessible to many administrators on campus, but only through a web interface that constrains interaction pretty tightly. Now that we have collected the data, processed almost all of it by hand (the roughness of the data made automated processing an unattractive alternative), and tabulated it for analysis, we are starting to receive requests for our spreadsheets from others on campus. These folks all have access to the data, just not in the cleaned-up, organized format into which we massaged it. I expressed frustration with our financial system in a mini-rant a few years ago, and other users feel similar limitations.

For me, having enrollment and grade data would be so cool. We could convert data into information that we could then us to inform scheduling, teaching assignments, and the like. Universities are inherently an information-based institutions, but we don't always put our own understanding of the world into practice very well. Constrained resources and intellectual inertia slow us down or stop us all together.

Hence my wistful hope while reading Tim Bray's "Hello-World" for Open Data. Vancouver has a great idea:

• Publish the data in a usable form.
• License it in a way that turns people loose to do whatever they want, but doesn't create unreasonable liability risk for the city.
• See what happens. ...

Would anyone on campus take advantage? Maybe, maybe not. I can imagine some interesting mash-ups using only university data, let alone linking to external data. But this isn't likely to happen. GPA data and instructor data are closely guarded by departments and instructors, and throwing light on it would upset enough people that any benefits would probably be shouted down. But perhaps some subset of the data the university maintains, suitably anonymized, could be opened up. If nothing else, transparency sometimes helps to promote trust.

I should probably do this myself, at the department level, with data related to schedule, budget, and so on. I occasionally share the spreadsheets I build with the faculty, so they can see the information I use to make decisions. This spring, we even discussed opening up the historic formula used in the department to allocate our version of merit pay.

(What a system that is -- so complicated that that I've feared making more than small editorial changes to it in my time as head. I keep hoping to find the time and energy to build something meaningful from scratch, but that never happens. And it turns out that most faculty are happy with what we have now, perhaps for "the devil you know" reasons.)

I doubt even the CS faculty in my department would care to have open data of this form. We are a small crew, and they are busy with the business of teaching and research. It is my job to serve them by taking as much of this thinking out of our way. Then again, who knows for sure until we try? If the cost of sharing can be made low enough, I'll have no reason not to share. But whether anyone uses the data that might not even be the real point. Habits change when we change them, when we take the time to create new ones to replace the old ones. This would a good habit for me to have.

Brian Marick tweeted about his mini-blog post Pay me until you're done, which got me to thinking. The idea is something like this: Many agile consultants work in an agile way, attacking the highest-value issue they can in a given situation. If the value of the issues to work on decreases with time, there will come a point at which the consultant's weekly stipend exceeds the value of the work he is doing. Maybe the client should stop buying services at that point.

My first thought was, "Yes, but." (I am far too prone to that!)

First, the "yes": In the general case of consulting, as opposed to contract work, the consultant's run will end as his marginal effect on the company approaches 0. Marick is being honest about his value. At some point, the value of his marginal contribution will fall below the price he is charging that week. Why not have the client end the arrangement at that point, or at least have the option to? This is a nice twist on our usual thinking.

Now for the "but". As I tweeted back this feels a bit like Zeno's Paradox. Marick the consultant covers not half the distance from start to finish each week, but the most valuable piece of ground remaining. With each week, he covers increasingly less valuable distance. So our consultant, cast in the role of Achilles, concedes the race and says, okay, so stop paying me.

This sounds noble, but remember: Achilles would win the race. We unwind Zeno's Paradox when we realize that the sum of an infinite series can be a finite number -- and that number may be just small enough for Achilles to catch the tortoise. This works only for infinite series that behave in a particular way.

Crazy, I know, but this is how the qualification of the "yes" arose in my mind. Maybe, the consultant helps to create a change in his client that changes the nature of the series of tasks he is working on. New ideas might create new or qualitatively different tasks to do. The change created may change the value of an existing task, or reorder the priorities of the remaining tasks. If the nature of the series changes, it may cause the value of the series to change, too. If so, then the client may well want to keep the consultant around, but doing something different than the original set of issues would have called for.

Another thought: Assume that the conditions that Marick described do hold. Should the compensation model be revised? He seems to be assuming that the consultant charges the same amount for each week of work, with the value of the tasks performed early being greater than that amount and the value of the tasks performed later being less than that amount. If that is true,then early on the consultant is bringing in substantially more value than he costs. If the client pulls the plug as soon as the value proposition turns in its favor, then the consultant ends up receiving less than the original contract called for yet providing more than average value for the time period. If the consultant thinks that is fair, great. What if not? Perhaps the consultant should charge more in the early weeks, when he is providing more value, than in later week? Or maybe the client could pay a fee to "buy out" the rest of the contract? (I'm not a professional consultant, so take that into account when evaluating my ideas about consultant compensation...)

And another thought: Does this apply to what happens when a professor teaches a class? In a way, I think it does. When I introduce a new area to students, it may well be the case that the biggest return on the time we spend (and the biggest bang for the students' tuition dollars) happens in the first weeks. If the course is successful, then most students will become increasingly self-sufficient in the area as the semester goes on. This is more likely the case for upper-division courses than for freshmen. What would it be like for a student to decide to opt out of the course at the point where she feels like she has stopped receiving fair value for the time being spent? Learning isn't the same as a business transaction, but this does have an appealing feel to it.

The university model for courses doesn't support Marick's opt-out well. The best students in a course often reach a point where they are self-sufficient or nearly so, and they are "stuck". The "but" in our teaching model is that we teach an audience larger than one, and the students can be at quite different levels in background and understanding. Only the best students reach a point where opting out would make sense; the rest need more (and a few need a lot more -- more than one semester can offer!).

The good news is that the unevenness imposed by our course model doesn't hurt most of those best students. They are usually the ones who are able to make value out of their time in the class and with the professor regardless of what is happening in the classroom. They not only survive the latency, but thrive by veering off in their own direction, asking good questions and doing their own programming, reading, thinking outside of class. This way of thinking about the learning "transaction" of a course may help to explain another class of students. We all know students who are quite bright but end up struggling through academic courses and programs. Perhaps these students, despite their intelligence and aptitude for the discipline, don't have the skills or aptitude to make value out of the latency between the point they stop receiving net value and the end of the course. This inability creates a problem for them (among them, boredom and low grades). Some instructors are better able to recognize this situation and address it through one-on-one engagement. Some would like to help but are in a context that limits them. It's hard to find time for a lot of one-on-one instruction when you teach three large sections and are trying to do research and are expected to meet all of the other expectations of a university prof.

Sorry for the digression from Marick's thought experiment, which is intriguing in its own setting. But I have learned a lot from applying agile development ideas to my running. I have found places where the new twist helps me and others where the analogy fails. I'm can't shake the urge to do the same on occasion with how we teach.

I am coming to a newfound respect for Robert's Rules of Order these days. I've usually shied away from that level of formality whenever chairing a committee, but I've experienced the forces that can drive a group in that direction.

For the last year, I have been chairing a campus-wide task force. Our topic is one on which there are many views on campus and for which there is not currently a shared vision. As a result, we all realized that our first priority was communication: discussing key issues, sharing ideas, and learning what others thought. I'll also say that I have learned a lot about what I think from these discussions. I've learned a lot about the world that lies outside of my corner of campus.

With sharing ideas and building trust as our first goals, I kept our meetings as unstructured as possible, even allowing conversations to drift off topic at times. That turned out well sometimes, when we came to a new question or a new answer unexpectedly.

We are nearing the end of our work, trying to reach closure on our descriptions and recommendations. This is when I see forces pushing us toward more structure. It is easy to keep talking, to talk around a decision so much that we find ourselves doubting a well-considered result, or even contradicting the it. At this point, we are usually cover well-trod ground. A little formality -- motion, second, discussion, vote, repeat -- may help. At least I now have some first hand experience of what might have led Mr. Robert to define his formal set of rules.

It occurs to me that Robert's Rules are a little like the heavyweight methodologies we often see in the software development world. We agile types are sometimes prone to look down on big formal methodologies as obviously wrong: too rigid, too limiting, too unrealistic. But, like the Big Ball of Mud, these methodologies came into being for a reason. Most large organizations would like to ensure some level of consistency and repeatability in their development process over time. That's hard to do when you have a 100 or a 1000 architects, designers, programmers, and testers. A natural tendency is to formalize the process in order more closely to control it. If you think you value safety more than discovery, or if you think you can control the rate of change in requirements, then a big process looks pretty attractive.

Robert's Rules looks like a solution to a similar problem. In a large group, the growth in communication overhead can outpace the value gained by lots of free-form discussion. As a group grows larger, the likelihood of contention grows as well, and that can derail any value the group might gain from free-form discussion. As a group reaches the end of its time together, free-form discussion can diverge from consensus. Robert's Rules seek to ensure that everyone has a chance to talk, but that the discussion more reliably reach a closing point. They opt for safety and lowering the risk of unpredictability, in lieu of discovery.

Smaller teams can manage communication overhead better than large ones. This is one of the key ideas behind agile approaches to software development: keep teams small so that they can learn at the same time they are making steady process toward a goal. Agile approaches can work in large organizations, too, but developers need to take into account the forces at play in larger and perhaps more risk-averse groups. That's where the sort of expertise we find in Jutta Eckstein's Agile Software Development in the Large comes in so handy.

While I sense the value of running a more structured meeting now, I don't intend to run any of my task force or faculty meetings using Robert's Rules any time soon. But I will keep in mind the motivation behind them and try to act in the spirit of a more directed discussion when necessary. I would rather still value people and communication over rules and formalisms, to the greatest extent possible.

Yesterday, I mentioned writing reports for a campus-wide Academic Program Assessment. While the process of gathering data and writing it up was laborious and, at times, stultifying, I did learn some things about our programs and department. Data can be illuminating. Feedback is good. Reflection is a worthwhile activity.

But collecting data, studying it, and crafting a story of feedback are time-consuming, and many people in my department and university think that doing so spends time that could be contributing to our substantive goals.

Of course getting feedback can and should contribute to the substantive goal of doing our jobs, and doing them better. The problem is pushing the working of collecting data and studying it out of the daily workflow and then making it an onerous and extended interruption of the workflow. Kent and Ward got something right when they talked about finding a way to work feedback -- rapid, automated, and as inexpensive as possible -- into the daily act of making something.

This post is a rerun of a previous post, or maybe two! But every once in a while I feel myself in a rerun mode, a rerun mood. Bureaucracy on one side of the process and cynicism on the other get in the way of changing how and when to gather and use organizational feedback more effectively. How can we get better? How do I get better?

Last week, I read this passage from Liz Keogh and took comfort from it:

Whatever we do with the story, in order to get feedback, it has to show something that the business can understand and on which they can give us feedback. If you can't get feedback, nobody cares. If nobody cares, it's not a story.

(If you're having problems getting feedback from your business, try delivering something.)

Perhaps one way to combat cynicism from people who have reason to be cynical is to craft a better story. Maybe I don't get feedback because the story I ask them to work on is not a story to them. Maybe I could get better or more feedback by delivering something.

When things don't go as well as I might hope, it is not always my fault. And when I share responsibility, it is not always only my fault. (I know -- I need to make a move away from the language of blame and find a way to think about making things better. Another of Liz's posts reminded me of that, too!)

But... All I can fix is myself, and what I do. Generally, trying to fix others does not work well, and even when it does, it doesn't make for an effective long-term strategy to move the team or the department forward. So, how can I do better?

... so many meetings and budget discussion. A week in which I do no computer science is as bad as a week in which I do not run.

I did play hooky while attending a budget meeting yesterday. I took one of our department laptops so that I could upgrade Ruby, install Bluecloth, and play with a new toy. But that's bit-pushing, not computer science.

Why all the budget talk? Working at a public university offers some shelter from changing economic winds and tends to level changes out over time. But when the entire economy goes down, so do state revenues. My university is looking at a 9% cut in its base budget for next year. That magnitude of change means making some hard choices. Such change creates uneasy times among the faculty, and more work planning for changes and contingencies among department heads.

There is some consolation in being on the front line, knowing that I can shield the faculty from much of the indecision. I also have opportunities to argue against short-sighted responses to the budget cuts and to suggest responses that will help the university in the long term. There is nothing like a sudden lack of revenue to help you focus on what really matters!

Still, I'd rather be writing a program or working on a tough CS problem.

In my last entry, I talked about Pierre Bayard's How to Talk About Books You Haven't Read, which I have, indeed, read. Bayard started with the notion that no one should feel shame about not having read a book, even when we are called upon to talk abut it. He eventually reached a much more important idea, that by freeing ourselves from this and other fears we have about books and learning we open ourselves to create art of our own. This entry looks at the bigger idea.

The issues that Bayard discusses throughout the book touch me in several personal and professional ways. I am a university professor, and as a teacher I am occasionally asked by students to talk about books and papers. I've read many of these, but not all; when I have read a work, though, I may well have forgotten a lot of it. In either case, I can find myself expected to talk intelligently about a work I don't know well. Not surprisingly, students show considerable deference to their teachers, in part because they expect a level of authority. That's pressure. Personally, I sometimes hang with an interesting, literate, well-read crowd. They've all read a lot of cool stuff; why haven't I? They don't ask me that, of course, but I ask myself.

Bayard assures us "don't worry!", explains why not, and tells us how to handle several common situations in which we will find ourselves. That's the idea -- partly humorous, partly serious -- behind the book.

But there is more to the book, both humor and truth, that connected with me. Consider:

Reading is not just acquainting ourselves with a text or acquiring knowledge; it is also, from its first moments, an inevitable process of forgetting.

Until I started writing this blog, I did not have a good sense of how bad my memory is for what I have read. I've never had a high level of reading comprehension. Those standardized tests we all took in grade school showed me to be a slow reader with only moderate comprehension, especially when compared to performance in school. One of the best outcomes for me of writing this blog has been to preserve some of what I read, especially the part that seems noteworthy at the time, before I start to forget it.

The chapter that contains the sentence quoted above begins with this subtitle:

Montaigne writes with fear about his forgetfulness, the loss any memory of having read a book. Does that still count? In one sense, yes. I've held Ringworld in my hands and taken in the words on each page. But in most ways I am today indistinguishable from a person who has never read the book, because I don't remember much more than the picture on the cover. Bayard explores this and other ways in which the idea of "to read" is ambiguous and bases his advice on the results.

How about any of the many, many technical computer science books I've read? The same fate. There is one solace to be had when we consider books that teach us how to do something. The knowledge we gain from reading technical material can become part of our active skill base, so that even after we have forgotten "knowledge that" the content of a compiler text is true, we can still have "knowledge how" to do something.

But reading is not the end of forgetting. Montaigne was an essayist. What about writing? Montaigne expects his loss to extend to his own work:

It is no great wonder if my book follows the fate of other books, and if my memory lets go of what I write as of what I read, and of what I give as of what I receive.

Forgetting what I have written is a sensation I share with Montaigne. Occasionally, I go back and re-read an old entry in this blog, or a month of entries, and am amazed. Some times, I am amazed that I wrote such drivel. Other times, I am amazed that I had such a good idea and managed to express it well. And, yes, I am often amazed to be reminded I have read something I've forgotten all about. In the best of these cases, the entry includes a quotation or, even better, a link to the work. This allows me to read it again, if I desire. I usually do.

That is good news. We can hold at bay the forgetting of what we read by re-reading. But there is another risk in forgetting: writing the same thing again. Bayard reports Montaigne's fear:

Incapable of remembering what he has written, Montaigne finds himself confronted with the fear of all those losing their memory: repeating yourself without realizing it....

Loss of memory creates an ambiguity in the writer's mind. It's common for me when writing a blog entry to have a sense of deja vu that I've written the same thing before. Sometimes my mind is playing tricks on me, due to the rich set of links in my brain, but sometimes I am and have forgotten. The fear in forgetting what we have written is heightened by the fear that what we write is unremarkable. We may remember the idea that stands out, but how are we to remember the nondescript? I often feel as Montaigne did:

Now I am bringing in here nothing newly learned. These are common ideas; having perhaps thought of them a hundred times, I am afraid I have already set them down.

I feel this almost no matter what I write. Surely my thoughts are common; what value is there in writing them down for others to read? That's why it was good for me to realize at the very beginning that I had to think that I was writing for myself. Only then would I find the courage to write at all and maybe benefit someone else. When confronted by a sense that I am writing the same ideas again, I just have to be careful. And when I do repeat myself, I must hope that I do it better the second time, or at least differently enough, to add something that makes the new piece worth a reader's time.

The danger in forgetting what I have written is not only in writing again. What about when a reader asks me about something I have written? Montaigne faced this fear, too, as Bayard writes:

But fear of repeating himself is not the only embarrassing consequence of forgetting his own books. Another is that Montaigne does not even recognize his own texts when they are quoted in his presence, leaving him to speak about texts he hasn't read even though he has written them.

That is at least two layers of not reading more than most of us expect to encounter in any situation! But the circumstance is quite real. When someone sends me e-mail asking about something I've forgotten I wrote, I have the luxury of time to re-read (there it is again!) before I respond. My correspondent is likely none the wiser. But what if they ask me in person? I am right where Bayard says I will be, left to respond in many of the ways he describes.

By writing about what I read and think about, there is a great risk that people will expect me to be changed by the experience! I did not do myself any favors when I chose a name for my blog, because I create an expectation about both knowing and doing. I certainly hope that I am changed by my experience reading and writing, but I know that often I have not changed, at least sufficiently. I still give lame assignments. I'm not that much better as a teacher at helping students learn more effectively. My shortcoming is all the more obvious when students and former students read my blog and are able to compare their experiences in my classes with my aspirations.

This is actually more a source of guilt for me than being thought not to have read a book. I know I am not as good as all the things I've read might lead one to believe, or even as good as what I've written (which sets a much lower bar!). If I am not growing, what is the point?

Of course, I probably am changing, in small increments beneath the scale of my perception. At least I hope so. Bayard doesn't say this in so many words, but I think it is implicit in how he approaches reading and not reading. For him, there is no distinction between the two:

We do not retain in memory complete books identical to the books rememeberd by everyone else, but rather fragments surviving from partial readings, frequently fused together and recast by our private fantasies.

This is a central theme for Bayard, and for me as well. He talks at length about the different ways our inner conception of books and libraries affects the act of reading any book. I often wonder how much of what I report about a book or paper I read is a product of me imposing my own view on what the writer has said -- not what is there, not what the author has intended, what distorts the writer's meaning? How much of what I am writing about Bayard's book reflects accurately the book he wrote?

Bayard would be unconcerned. On his view, I could no more not impose my inner book on the outer one than to be Bayard himself. No one can avoid distortion (in an objectivist sense) or imposition of self (in a subjectivist sense). What distinguishes the master is how forcefully and creatively one does so. Private fantasy, indeed!

To conceive of reading as loss ... rather than as gain is a psychological resource essential to anyone seeking effective strategies for surviving awkward literary confrontations.

Can I admit that I have forgotten something I've read or written? Certainly; I do it frequently. The key is to talk about the work as who I am in the present. I don't even need to explicitly acknowledge the loss, because the loss is a given. But I must talk without embarrassment and without any pretension that I remember exactly what I said or thought then. The human mind works in a certain way, and I must accept that state of affairs and get down to the business of learning -- and creating -- today.

Last week, I read Patrick Lencioni's The Five Dysfunctions of a Team. It's another one of those "parable" books, wherein the author teaches his method, stance, or idea by telling a story of the theme in action. The book has been in my to-read pile for several months, after seeing a couple of positive references to it on the XP mailing list a while back. But I put off reading it in favor of other things for a long time. Indeed, my experience mirrors the one reported here: I couldn't seem to get started for the longest time, despite my wife's good recommendation, and then I read it quickly and found it to be a "very good little book". I recommend it.

Lencioni describes a pyramid of dysfunctions that sabotage a team's effectiveness. This model can also be viewed as a sequence of patterns of effective teams: trust, conflict, commitment, accountability, and collective results. I have experienced elements of all five layers in my current "team". I would not say that we are as self-destructive as the team in his story, but even small chinks in the foundation can weaken the structure above. I hope that in my time as head we have taken steps in the right direction from dysfunction to function. Certainly, trust has been one of my focal points. I have been less successful in encouraging healthy conflict as I had hoped, which indicates weakness in trust. This is an area in which I can grow more able as a leader. Lencioni's model gives me a standard against which to evaluate myself.

Of course, as Seth Godin says, Obviously, knowing what to do is very, very different than actually doing it. That is one of the underlying themes of this blog and its name.

Speaking of Godin, I am reminded of a misgiving I've had about the parable books that dominate the popular business press. I've enjoyed many of them, but these days I am less eager to read another. I even told my wife that I was planning to skip past the story in Lencioni's book straight to the appendix that explains his model in about 30 pages. Typical academic that I am, I hungered for the meat of the book, not the appetizer.

Almost every one of the popular business books could be boiled down to a single chapter that states the main idea and tells me how to implement it. That doesn't make for much of a book, though, and wouldn't attract many readers. But why should a busy guy like me waste time reading the fully dressed version? Am I missing something? I didn't think so, but... There is a big gap between knowing and doing.

I was lucky to read Godin's blog entry How to read a business book within a day of finishing Five Dysfunctions, and he set my mind at ease. My understanding of these books is spot-on, yet the parable itself really is important. It is where the author hopes to cultivate in us the motivation to act. Godin says as much about his own books:

... if three weeks go by and you haven't taken action on what you've written down, you wasted your time.

Three weeks is probably too tight for me, with the onset of summer vacation and the end to regular interactions among the whole faculty until fall. I either need to re-read the book in August or find a way to act on what I've learned during the summer.

In closing, I see Godin's prescription as something like a unit test for my reading about teams and leadership:

Effective managers hand books to their team. Not so they can be reminded of high school, but so that next week she can say to them, "are we there yet?"

Kent Beck would be proud.

... 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 university. At a time when our discipline is changing, such majors represent a reasonable effort to broaden and focus our reach at the same time.

In order to create a new major at one of Iowa's three public universities, you must have it approved by the system-wide Board of Regents. Before a proposal reaches the Board level, though, it first must receive approval from the provosts at the three institutions. This is a reasonable mechanism which generally ensures that all of the universities know what the others are doing, helps identify opportunities for collaboration, and prevents unnecessary duplication in programs.

Our bioinformatics and NaSA proposals were approved in the initial proposal cycle, but software engineering was not. One of our sister institutions raised objections to all three proposals, but the other gave us its blessing. As part of a compromise to overcome the objections, our administration withdrew the Software Engineering proposal from the table. This succeeded because, while the objecting school would have preferred that we not offer any of the new majors, its greatest objection was to the Software Engineering proposal. This objection ultimately came down to our use of the word 'engineering' in the title of a degree program. The other schools have Colleges of Engineering, but we do not.

Engineers take use of the word 'engineering' quite seriously as a matter of professional honor. To them, engineering means something specific, and engineering education requires a specific set of courses in mathematics and the physical sciences, as well as specific experiences rooted in how professional engineers craft their trade. My university does not offer a traditional engineering program, so our engineering colleagues do not consider us capable of offering an engineering major.

So we passed on our Software Engineering proposal and put our energies into launching the other two new majors. They've now been on the books for a year and have begun to attract majors. We've also experimented with professional marketing techniques to introducing bioinformatics to our target audiences.

By the time I became department head, we had a new dean and a new provost, and our faculty really wanted to re-propose the Software Engineering major. The faculty did not feel that the original proposal had been dismissed on its merits, but rather for political reasons, and they wanted the chance to make their case that we be allowed to offer this new major, which so closely aligns with the professional goals of many of our students.

So we set out to educate our new administration on the discipline and why our university should be offering degrees in software engineering. Once they were convinced, we took our case back to the council of provosts. Not too surprisingly, we encountered the same objection.

Actually, we encountered several objections. Since the time of our initial proposal, the objecting school had proposed its own Software Engineering degree program. So now there were concerns about duplication of effort and resources. Those of you on university faculties surely know that duplication among state schools is a big issue these days. State funding isn't as plentiful as it used to be, and so unnecessary duplication is viewed as an unacceptable financial luxury.

Another objection involved the fact that we did not intend to seek accreditation of our program by ABET, the standard accrediting agency for engineering programs. As a matter of professional standards, nearly all traditional engineering programs are accredited by ABET. Software engineering programs are a relatively recent phenomenon, as is their accreditation. Programs started within colleges of engineering do tend to seek accreditation, but not all do. A considerable number of undergraduate software engineering programs -- about a quarter of the thirty programs currently being offered in the U.S. -- lie outside of an engineering college and are much less likely ever to seek accreditation.

This might be a concern for the established engineering disciplines, but I think it is less of an issue for software engineering. I'm not sure we know how to "engineer" large software all that reliably yet, and I'm not sure that we have a good sense of what all software engineers should know or be able to do. Projects such as SWEBOK are valuable efforts to catalog our current understanding, but what we really need is many more years building big systems and examining our practices along the way.

This brings us back to the semantic issue that lies at the heart of the objections to our program proposal. Our engineering colleagues consider software engineering to be an engineering discipline like mechanical or electrical or civil engineering, and as such they think it should be treated like the traditional engineering programs. Whatever the professional assessment of engineering colleges regarding the use of the word "engineering", the term "software engineering" is widely used throughout the U.S. and the world in a broad sense, to describe the disciplined construction of software systems. Courses in software engineering are offered by many different academic institutions, including the majority of Computer Science departments these days. Graduates of computer science and information systems programs move immediately into positions with the title "software engineer" in many different kinds of companies. For our students, these employers ranges from traditional engineering companies to financial services companies such as insurance companies and banks. Many small, independent software developers consider themselves to be software engineers, though they would never consider becoming a licensed professional engineer. Standard use of the term "software engineering" does not indicate "engineering" in the sense understood by the engineering profession.

Perhaps it should. Our colleges of engineering would prefer to define the term prescriptively, setting standards and ensuring that anyone who bears the title of engineer meet a set of common standards first. This is a noble aspiration. But my definition of the term is descriptive, in the sense of describing how it is used by people out in the world. In this descriptive sense, I think it is perfectly reasonable for my university to offer a Software Engineering degree.

Alas, I am not the one to make this decision. Our sister institutions persisted in their objections to our proposal, and so again it failed. Had we changed the name of our program to Software Development or almost anything else without the word 'engineering' in it, we would probably have succeeded in having our program approved. Our faculty decided that to change the name of our program to something non-standard would defeat the purpose of offering a specialized degree in the discipline; it wouldn't match up with the expectations of students or the companies that hire them. Besides, the non-standard name feels distinctly sub-standard, as if we aren't capable of offering a degree in the discipline that folks have come to regard as standard in industry.

Sadly, I fear that there may have been an element of this thinking in our sister institution's objection to our proposal. They think us worthy of offering an "applied computer science" program in something called software development, but not worthy of awarding degrees in Software Engineering.

I work at a so-called teaching university. While most of our faculty is engaged in research and other scholarly activity, basic research is not our mission; producing well-educated citizens is. A computer science program at a school such as mine blends a solid core of empirical CS with what amounts to professional education, not all that different from the pre-professional programs we offer students interested in pursuing law degrees and medical degrees. For most of our CS students, computer science is a professional degree, and software engineering is one of their professions of choice. One of our goals is to produce broadly educated practitioners in a discipline that changes rapidly, while at the same time changing the world in which the practitioners practice.

Ultimately, I think that our position on who should be teaching software engineering will be proven right by history. While I am not a big fan of the metaphor, software engineering as a discipline is much bigger than colleges of engineering conceive it, and more and more schools will teach it. In the meantime, we will continue on with what we have -- a B.S. program in Computer Science, with a Software Engineering emphasis -- and prepare students to enter the world ready to develop software, including the largest of systems, whatever that activity may be like in the future.

I sit hear now wondering what software engineering programs in colleges of engineering and think about agile approaches to software development. Maybe we are lucky not to be constrained by the straightjacket of expectations that accompany the programs in established engineering disciplines. We are still learning how to build software, and we can fold our learning into our courses and curricula much faster when we don't have to worry about a set of restrictions based in other engineering disciplines.

Anyway, for those of you who think that "office politics" in the "real world" make life worse than it is in the ivory tower, this little story only scratches the surface of what university politics are like. That's a whole other story...

That was my standard answer to a particular family of questions for many years. The prototypical question in this family was, "Do you think you'll ever want to be a department head?" And I always said, "July 27 at 2:00 PM".

If you are a faculty member or even a graduate student, you probably know just what I meant. Summer is a great time to be a faculty member. We get to read, write code, play with new ideas -- all without having to worry about preparing for and meeting classes, attending department meetings, or otherwise doing much with the day-to-day business of the university. Even better, we can read, write, and play most anywhere we want, most anytime we want. We can become absorbed in a program and work all day, and never have to worry about a meeting or a class interrupting the flow. We can work from home or from the road, but we don't have to work at our offices unless we want to. No one expects us to be there much.

Department heads, though, are administrators. The daily business of the university goes on, and the heads have to keep tabs on it. There are salary letters to be written, budgets to be closed, memos to write for the dean and provost, and inquiries to be answered. The university pays their salary during the summer, and the university expects a return on its investment.

So, there we are, 2:00 PM on a beautiful Thursday, July 27th. As a faculty member, I could be almost anywhere, doing almost anything, learning something new. As a department head, I would be in the office, dressed well enough to meet the public if necessary, "working".

"July 27 at 2:00 PM" meant "I don't think so, and here's why...".

The great irony is that I am now finishing up my first year as department head now, and it is nearly 2:00 PM on Thursday, July 27. It's overcast outside, not sunny, and frightfully muggy. Where am I? In my home study. What am I doing? Reading from the stack of papers that has built up over the last few months, and writing a quick entry for this blog. Not much different than any other summer in the past 15 years.

However, I stand by metaphorical answer. All other things being equal, summer life as a faculty member is freer and open to more possibilities than summer life as a department head. It requires some adjustment.

My reading today has been from an old-fashioned pile of stuff, the papers and journal articles that I run into during busy days and set aside for later. I don't know about you, but my eyes are always bigger than my stomach when it comes to the list of things I want to read. So I print them out and wait for a free moment. Eventually the pile of papers exceeds any realistic amount of time I have to read and the amount of space I have to store them. Today, I made a few free moments to do triage, tossing papers that I know I'll never get to and, every so often, stopping to read something that sounds good right now. A very few papers earn a spot in the new, streamlined pile of stuff, in an almost certainly fantastic hope that some day I'll get to them.

Here are two passages I read today that made the effort worthwhile. First, a quote from Uncle Bob Martin, from a 2004 message to the extreme programming mailing list, in the thread "Designing before doing":

>  "But how can you do anything without designing it first?!" ...

You can't. You always have to design something before you build it.

The question is: "How much do I have to design before I build?"

The answer is: "Just enough so that what I build gives me better insight into the design of the next step."

Seen this way, the act of building is *part* of the act of design, and the original question inverts itself: "How can you design something without verifying your design decisions by implementing them?"

Well said. Thank you, Uncle Bob.

Finally, a bit of humor from Eric Raymond's classic FAQ, How to Become a Hacker:

Q:

I'm having problems with my Windows software. Will you help me?

A:

Yes. Go to a DOS prompt and type "format c:". Any problems you are experiencing will cease within a few minutes.

Enjoy your July 27!

I am coming to the end of my first year as department head, which officially began on August 1 last year. In that time, I have written less about management than I had expected. Why? One ingredient is that I blog using my public identity. I don't often mention UNI or the University of Northern Iowa in my entries, but the blog is located in my departmental web space, and I provide plenty of links off to other UNI pages.

For much of what I've thought to write in the last year, I would have had a hard time writing in an anonymous way; too often, it would have been obvious that my comments were about particular individuals -- folks that some of my readers know, or could know, and folks who themselves might stumble upon my blog. In a couple of CS curriculum entries such as this one, I have referred to a nameless colleague who would surely recognize himself (and our current and former students can probably identify him, too) -- but those were posts about CS content, not discussions of my role as head.

Why would that be a problem? I think that I am more prone to write these days on negative experiences that occur as an administrator, manager, or dare I say leader than I am to write on positive events. This is the same sort of motivation I have for writing software patterns, negative experiences that happen when programming and designing. But in those cases I also have a solution that resolves the forces. As an administrator, I am mostly still looking for solutions, feeling my way through the job and trying to learn general lessons. And that gets us to the real reason I haven't written much on this topic: I'm not there yet. I don't think I've learned enough to speak with any amount of authority here, and I don't have the confidence to ruminate yet.

As I wrote back in May, I thought I might have more time to write in the summer, at least more regularly. But instead of fewer distractions, I think I've experienced more. I've actually had less concentrated time to write. In that same entry, I related a quote from Henri Nouwen that "... the interruptions were my real work." The idea behind this quote is that we must come to peace with the distractions and view them as opportunities to serve. In a rational sense, I understand this, but I am not there yet. Sometimes, interruptions just seem like interruptions. I can go home at the end of a day of interruptions feel like I did something useful, but I also usually feel unfulfilled at not having accomplished my other goals for the day.

Sometimes, the interruption really does turn out to be my real task, one that displaces other plans in a meaningful way. The best example of that this summer has been a long-tabled proposal for our department to offer a B.S. in Software Engineering. I definitely have plenty to write about this in the next couple of weeks, but it won't be my colleagues here who might be unhappy with what I say; it will be colleagues at our sister state institutions.

This week has been filled with nothing but distractions of the former type. For most of the week, I have felt like a preemptible processor thrashing on a steady flow of interrupts. On the other hand, I did manage to tie up some loose ends from old projects, which should make August a more enjoyable month.

In that May entry, I also quoted Chad Fowler's vignette about "fighting the traffic". I have come to realize that, unlike Fowler's cabbie, I don't love to fight the traffic. At least not as my primary job. I know that it is an essential part of this job, so I am looking for middle ground. That's a meta-goal of mine for the coming year. I'd also like to refine how I respond to interrupts and how I schedule and manage my time. This year will tell me a lot about whether I should consider this as a long-term professional opportunity.

But now I am ready for a little vacation. I haven't take any break other than at Christmas since long weekends in May and July of 2005. While I am not despairing for my job, I am reminded of a quote I used when starting as head last August 1:

Oft expectation fails, and most oft there
Where most it promises; and oft it hits
Where hope is coldest, and despair most fits.

-- William Shakespeare
All's Well That Ends Well (II, i, 145-147)

Earlier this summer, I had a fantasy of a running vacation: Drive somewhere mostly isolated, and find a home base in a little motel. Get up every morning and run from 5:30 until 9:00 or so, anywhere from 12 to 15 miles. Come back, shower, eat, and nap until noon. Then spend the day reading, writing, and goofing off. Mmmm.

But I also have a strong desire to spend some time with my wife and daughters, and so that's what I'll do: hang around home. I'll do some "home"work, relax and read. I'll probably also spend a little relaxed time corralling my work to-do list, to prepare for returning to the office. That will actually feel good. I'll even do some disciplined reading of work e-mail -- but I don't want to be this guy:

If I have to go an extreme, I'd rather be Delbert T. Quimby, a guy from an editorial cartoon by Ed Stein back in 1995. I can't find this on-line and don't have a scanned version of the cartoon, so you'll have to settle for my description. The scene is a cozy den, with a wall full of books. In the soft spotlight at the middle of the room is our protagonist, comfortably dressed, book in lap, glass of wine on the side table. The caption reads, "Eccentric Internet holdout Delbert T. Quimby passes yet another day non-digitally."

Back in 1995, such a maneuver was likely viewed as an act of rebellion; today, it would be viewed by many as just plain nuts. But, you know, it sounds really good right now. So who knows?

(My students probably consider me to be a Delbert T. Quimby already, not for the wardrobe and dumpy physique but for this neo-Luddite fact: I still have only a dial-up Internet connection at home!)

Oh, and I will definitely run a lot of miles next week -- 52 or so -- and blog a bit.

Today I've been cleaning out an old-fashioned sort of current stuff folder: a box of papers that had gathered on my desk last year and made the move en masse when we moved the department office to its new building. It is truly amazing in this day of digital technology and on-line communication that so much paper still flows among the various units of a large organization. Most of the paper in the box I attacked today has hit either the recycle bin or the shredder; the rest, mostly related to enrollment and budget, has been safely filed away, though I'm not sure how often it will be used.

Occasional pages contain highlighted quotes that struck me as worthy of keeping at some point last year. Not all seem as worthy today, but a couple ring as true now -- or truer -- than they did then.

One is "Midlife in Academe", an essay by Jeffrey Nesteruk in the July 8, 2005, issue of the Chronicle of Higher Education. Nesteruk recounts the enlightenment that came over him as he reached middle age, a tenured full prof who has reached most of his external professional goals. But this passage expresses a feeling I have after a year as department head:

... I have to be careful how I handle the loss of my professional innocence. I know the personalities in my academic world. I know the political divides, I know the battles that can be won and those that can't. But there's a risk in knowing too well your world's limits. I don't want that knowledge to constrain my imagination.

Like teaching and writing, administering a department and trying to lead it require imagination. It's important not to get boxed in by the geography you've observed so far.

Then again, maybe I should be running for the hills away from this job. From the International Association for Pattern Recognition's IAPR Newsletter, date unknown:

Administration is abhorred by all right-thinking academics and best to be avoided whenever possible. When done badly it causes grief; when done well it attracts even more to be done.

I've already lived both sides of that equation, and I expect the coming year to be more of the same.

One of the enjoyable outreach activities I've been involved with as department head this year has been the state of Iowa's Information Technology Council. A few years back, the Iowa Department of Economic Development commissioned the Battelle corporation to study the prospects for growing the state's economy in the 21st century. They focused on three areas: bioscience, advanced manufacturing, and information technology. The first probably sounds reasonable to most people, given Iowa's reputation as an agriculture state, but what of the other two? It turns out that Iowa is much more of a manufacturing state than many people realize. Part of this relates back to agriculture. While John Deere is headquartered in Moline, Illinois, most of its factories are in Iowa. We also have manufacturers such as Rockwell Collins and Maytag (though that company has been purchased by Whirlpool and will close most or all of its Iowa locations soon).

But information technology? Des Moines is home to several major financial services companies or their regional centers, such as Principal Financial Group and Wells Fargo. Cedar Rapids has a few such firms as well, as well as other companies with a computing focus such as NCR Pearson and ACT.

IDED created the IT Council to guide the state in implementing the Information Technology Strategic Roadmap developed by Battelle as a result of its studies. (You can see the report at this IDED web page.) The council consists of representatives from most of Iowa's big IT firms and many of the medium-sized and small IT firms that have grown up throughout the state. Each of the three state universities has a representative on the council, as does the community college system and the consortium of Iowa's many, many private colleges and universities. I am UNI's representative.

The council has been meeting for only one year, and we have spent most of our time really understanding the report and mapping out some ideas to act on in the coming year. One of the big issues is, of course, how Iowa can encourage IT professionals to make the state their home, to work at existing companies and to create innovative start-ups that will fuel economic growth in the sector. Another part of the challenge is to encourage Iowa students to study computer science, math, and other science and engineering disciplines -- and then to stay in Iowa, rather than taking attractive job offers from the Twin Cities, Chicago, Kansas City, and many other places with already-burgeoning IT sectors.

To hear Paul Graham tell it, we are running a fool's errand. Iowa doesn't seem to be a place where nerds and the exceedingly rich want to live. Indeed, Iowa is one of those red states that he dismisses out of hand:

Conversely, a town that gets praised for being "solid" or representing "traditional values" may be a fine place to live, but it's never going to succeed as a startup hub. The 2004 presidential election ... conveniently supplied us with a county-by-county map of such places. [6]

Actually, as I look at this map, Iowa is much more people than red, so maybe we have a chance! I do think that a resourceful people that is willing to look forward can guide its destiny. And the homes of our three state universities -- Iowa City, Ames, and Cedar Falls -- bear the hallmark of most university towns: attracting and accepting more odd ideas than the surrounding environment tends to accept. But Iowans are definitely stolid Midwestern US stock, and it's not a state with grand variation in geography or history or culture. We have to bank on solidity as a strength and hope that some nerds might like to raise their families in a place with nice bike trails and parks, a place where you can let your kids play in the neighborhood with fearing the worst.

We also don't have a truly great university, certainly not of the caliber Graham expects. Iowa and Iowa State are solid universities, with very strong programs in some areas. UNI is routinely praised for its efficiency and for its ability to deliver a solid education to its students. (Solid -- there's that word again!) But none of the schools has a top-ten CS program, and UNI has not historically been a center of research.

I've sometimes wondered why Urbana-Champaign in Illinois hasn't developed a higher-profile tech center. UIUC has a top-notch CS program and produces a lot of Ph.D., M.S., and B.S. graduates every year. Eric Sink has blogged for a few years about the joys of starting an independent software company amid the farmland of eastern Illinois. But then there is that solid, traditional-values, boring reputation to overcome. Chicago is only a few hours' drive away, but Chicago just isn't a place nerds want to be near.

So Iowa is fighting an uphill battle, at least by most people's reckoning. I think that's okay, because I think the battle is still winnable -- perhaps not on the level of the original Silicon Valley but at least on the scale needed to invigorate Iowa's economy. And while reputation can be an obstacle, it also means that competitors may not be paying enough attention. The first step is to produce more tech-savvy graduates, especially ones with an entrepreneurial bent, and then convince them to stay home. Those are steps we can take.

One thing that has surprised me about my work with the IT Council is that Iowa is much better off on another of Graham's measures than I ever realized, or than most people in this state know. We have a fair amount of venture capital and angel funding waiting for the right projects to fund. This is a mixture of old money derived from stodgy old companies like Deere and new money from the 1990s. We need to find a way to connect this money to entrepreneurs who are ready to launch start-ups, and to educate folks with commercializable ideas on how to make their ideas attractive to the folks with the money.

Here at UNI, we are blessed to have an existence proof that it is possible to grow a tech start-up right here in my own backyard: TEAM Technologies, which among its many endeavors operates the premier data center in the middle part of the USA. A boring, solid location with few people, little crime, and no coastal weather turns out to be a good thing when you want to store and serve data safely! TEAM is headed up by a UNI alumnus -- another great strength for our department as we look for ways to expand our role in the economic development of the state.

Three quotes for what amounts in most American workplaces the middle of a long holiday weekend. The first two remind me to approach my teaching and administrative duties with humility. The third reminds me of we in America celebrate this holiday weekend at all.

... from Gerald Weinberg:

When I write a book or essay, or teach a course, I have one fundamental measure of failure, which I call Weinberg's Target:

After exposure to my work, does the audience care less about the subject than they did before?

If the answer is Yes, I've failed. If the answer is No, I've succeeded, and I'm happy for it. Perhaps you consider my goal too modest. Perhaps you aspire to something greater, like making the student learn something, or even love the subject. Oh, I'm not dismayed by such fine outcomes, but I don't think it's a reasonable goal to expect them.

We can do much worse than communicate some information without dampening our audience's natural enthusiasm.

... from Steve Yegge:

If you don't know whether you're a bad manager, then you're a bad manager. It's the default state, the start-state, for managers everywhere. So just assume you're bad, and start working to get better at it. ... Look for things you're doing wrong. Look for ways to improve. If you're not looking, you're probably not going to find them.

Steve's essay doesn't have much in the way of concrete suggestions for how to be a good manager, but this advice is enough to keep most of us busy for a while.

... finally, from the dome of the Jefferson Memorial, via Uncertain Principles:

I have sworn upon the altar of God eternal hostility against every form of tyranny over the mind of man.

A mixture of humility and boldness befitting revolution, of thought and government.

Short answer: Because sometimes I am too cocky for my own good.

If you read the recent entry on my latest half marathon, you may have noticed that my mile 3 time stands out as slower than the rest. What happened? After running two comfortable miles at exactly 7:32, about a half minute faster than planned, I started daydreaming about what a great race I would soon have run. "Let's see, that's 91... plus six-and-a half, which is... Wow!" While patting myself on the back in advance, I forgot to keep running. Too cocky.

Last summer, when I took on the responsibilities of department head, I managed to convince myself that I was the best person for the job. Maybe even the only person. With this attitude, it is all too easy to fall into habits of thought and action where I forget that I have to do the hard work of the job. Why aren't things coming more easily? Too cocky.

So it is with programming. It's quite easy to attack a problem before we fully understand our customer's needs, to start pumping out code before we know where we are going. Get cocky, and pretty soon the problem and the program step up to humble me. Unfortunately, by then, I too often have a big mess on my hands.

I work better when I'm a little nervous, when I'm a bit unsure of whether I can do what I'm trying to do. Maybe that's a trait peculiar to me, but I think not. I've had good friends who thrived on an element of tension, where just enough uncertainty heightens their senses. I am more aware then. When I get cocky, I stop paying attention.

One reason that I like agile approaches to software development is that they encourage me not to get cocky. They tell me to take small steps, so I can't run ahead of my understanding. They tell me to find simple solutions, so that I have a better chance of succeeding (and, when I don't, I won't have erred too badly). They tell me to seek continuous feedback, so that I can't fool myself into thinking that all is going smoothly. The red bar cannot be denied! They tell me to integrate my work continuously, so that I can't fool myself about the system at large. They tell me to interact with other developers and with my customer as frequently as I can, so that others can help me, and keep me honest. The whole culture is one of humility and honesty.

In this era of rising costs, heightened competition, and falling public support for education, universities are becoming more and more driven by public relations. I encountered a perfect example at a meeting this morning.

One of the offices on campus was demoing a beta version of a new on-line tool that will help the university interact with students and community colleges. They plan to go 'live' with with the tool later this summer. Right now, they are introducing the tool to faculty on campus, both to get feedback to improve the program but also to build awareness of the tool among potential stakeholders.

Further, before going live, these folks plan to visit community colleges around the state to teach them about the tool, to build awareness among another key group of stakeholders. Then they'll present the tool to students here at the university and elsewhere.

One of their reasons for the concerted effort to spread the word so broadly was very pragmatic: After university public relations sends out press releases on this new tool, they expect the press to immediately ask community college folks what they think of about the tool's effect on them and their students. And the university wants these folks to be able to respond to press queries in an informed -- and, hopefully, positive -- way. Good words in the press make for good public relations.

The fact that the university is making an effort to educate potential users and stakeholders is not unusual; I'd expect the same for any new tool. What struck me was the deliberate effort to move the education stage so early in the process, as a part of the PR initiative. And the campaign of enlightenment won't be limited to people directly affected by the tool and its use; the university also plans to demo the tool to key legislators in the state and in the districts served by the community colleges. University/community college relations are a hot political issue these days, and the university wants fair attention given to its efforts to meet the desires of the folks who hold the purse strings, and the folks who elect those folks.

The PR campaign goes farther than just educating stakeholders. The unit responsible for this tool is already working on trademarking the name and logo of the software, to solidify their use in PR and to prevent unscrupulous competitors from swooping in after the launch and stealing intellectual property. (That flowery prose is mine, not the universities.)

I can't say that I blame the university for working so hard to shape its image before the legislature and the public at large. Perception is important. With so many entities competing for state appropriations, the university needs to sell itself better. Some might say that public agencies aren't competing, but they are. Within any given political culture, public funding is limited, so choices have to be made.

So long as the university doesn't subvert its purpose, or do things it wouldn't otherwise do for the sake of publicity, playing the PR game seems an unavoidable reality these days.

I've already about my department's effort to market a new program in bioinformatics. I view our efforts as a reasonable attempt to make information available to the people who need it in order to make informed choices about careers and educational opportunities. We will be moving forward this summer to let more students and teachers know about our program. For now, you can see a couple of pieces of literature developed by the university's PR department to help us, an 11"x17" poster (right) and an 8-1/2"x8-1/2" bifold brochure (PDF).

Several of my friends and colleagues have commented on the end of the academic year, which is different in some ways for me now that I am doing administrative duties as well as teaching. I've been known to do dance of joy at the end of a tough three-course teaching semester. Now my duties spread into the summer, but it's still nice to have a different rhythm to my days and weeks.

I am reminded of this little story by Chad Fowler, called Fight The Traffic:

I got in a cab last night heading from Washington D.C. to the Dulles airport. I was a block from the White House and traffic was stopped behind a crowd that was pushing its way in to see the President.

The old Ethiopian cab driver suddenly kicked the taxi into gear and zipped around a line of cars, edging us five cars closer to freedom.

"I hate traffic", he grumbled.

"You picked the wrong job, then, didn't you?"

"No! I love my job. My job is to fight the traffic."

In some ways, department heads are like cabbies. If you don't like to fight the traffic, then you probably won't like the job.

I spent a lot of time this year multitasking. There is a meeting this afternoon that I simply must attend? Grab the laptop and try to get a little light work done in the back. When in the office, I'd be working on some task with frequent context switches out for whatever phone call or walk-in visitor arrived. Soon I learned the myth of multitasking, illustrated by this photo from 43 Folders:

It's a mirage, tempting as it may be. Context switching has a measurable deleterious effect on my performance.

Perhaps one day I can reach a state of Zen mind in which I can live this recommendation from Ron Rolheiser:

Henri Nouwen once wrote "I used to get upset about all the interruptions to my work until one day I realized that the interruptions were my real work."

Pure earthily accidents often do make us responsible for what is divine and they conscript us to our real work.

I do realize that at least part of my job is to fight the traffic, to make the lives of the faculty and students better in the process. But on too many days it all just feels like an unending distraction. Part of my task now is to learn how to manage this flow of needs and wants better, and another part is to learn what part of this flow really is my real work.

So my answer to all my friends and colleagues is, I'm still doing the dance of joy at semester's end, but for a different reason. I'm looking forward to a couple of months in which to collect my thoughts, work at a steadier pace, internalize a few lessons from the year, figure out how to get better -- and to hack a little Ruby or Scheme or Java, when the mood strikes me!

It's been so long since I wrote regularly here that I am starting to feel a sense of withdrawal. Rather than try to tackle a larger essay today, I'm going to ease my way back in with one small lesson I have learned this year while trying to be an effective department head.

When I was a teenager, I read a science-fiction story about a man from Earth who traveled to a distant planet populated by folks who were mostly like us. They differed in one substantial way: they took on the emotions of those around them. When the Earth traveler was happy, so were the alien folks with whom he lived. When he was in a foul mood, they were, too. When he was sad, they, too became sad. The protagonist fell in love but ultimately had to leave the planet, because he could not bear to inflict his own moodiness and depressions on his lover, who seemed to suffer so much more than he did.

No, I haven't developed supernatural empathic abilities, but I did learn the value of not being too sensitive. It's not good for my health, and surprisingly not good for those around me.

The part about my health is pretty straightforward. In an administrative position, there are lots of people who depend on one's performance and who can become unhappy with results. Teachers always face this, through their students, but students are a remarkably resilient bunch. They are perhaps more used to not being in control of their worlds and so are less likely to cause a fuss when things don't go perfectly.

Faculty and other administrators aren't always so happy-go-lucky. Don't get me wrong; it's not that faculty and administrators are more likely to complain. It's just that they depend on other folks in order to get their own work done and so are more sensitive to conditions that differ from expected. And they are more likely to be direct in their comments.

Over a decade of participating in the software patterns community and its writers' workshop format, I've increasingly come to appreciate the value of providing positive and constructive feedback in a supportive way. I've been fortunate this year to have several colleagues who were willing to give me feedback about my performance that I need in order to get better. But a blunt listing of "here are things that haven't gone as well as we had hoped" can be quite a downer. It's easy to tell oneself not to be too sensitive; it's a much taller order not to be too sensitive. The ethos of writers' workshops is one of shared commitment to growth and so creates as supportive framework as possible in which to deliver suggestions.

Luckily, I think I've avoided being defensive in the face of criticisms -- most of which are accurate, and the rest of which are at least understandable from the perspective of the speaker -- but that doesn't make the sound of them any less of a drag on the psyche.

How does oversensitivity affect others? First of all, folks who are feeling down are less likely to do really good work for the team. Until my mood bounces back, I feel like a substandard performer. Second, oversensitivity creates a reluctance to open up so easily, which makes the person a less effective collaborator. I think I've been lucky to avoid this pitfall so far this year, but it requires conscious effort.

I hope that I am able to fold this lesson back into how I give feedback to my colleagues and in the classroom. Constructive suggestions are more likely to help the hearer if they arrive in a supportive package.

P.S. If you have any idea of the name or author of the story I described above, please drop me a note.)

I haven't had a chance to write in over a week, but a busy week it has been. My last post foreshadowed the move of my department office to a new home, in an old building on campus that has been renovated into an "innovative teaching and technology center". That name actually sets a higher standard than the building can live up to, but it will be a good home for us.

Last week, we began moving the department office to its new home, to make space for a computer lab. I suppose that we didn't technically have to move the department head's office yet, because the old office isn't need for something else yet. but anyone who has ever been at a university knows that heads, deans, and the like depend on their administrative staff too much to be separated from them. In this era of continuous electronic communication, I could probably survive better than most administrators from the past, but it would make an already challenging job all the more difficult to be two buildings away from the department secretary. So I moved, too, if only the working set of my office for now.

Not that I didn't have good reason to want to move. The university's provost, after taking a tour of the new building during construction, made a point of telling me that my office may have the best view on campus. Here is a digital snapshot looking out my window toward the southwest on a recent sunny day:

Here's a lower-quality picture of the view toward the northwest. The campanille serves as nice reference point:

I don't have the highest-quality digital camera, but I've done the best I can to reproduce my view. The glare off my windows makes it tough to get good shots from all angles. But, quoting Sidra from Seinfeld, I can say that these images "are real, and they are spectacular". Either karma is looking out for me, or I have simply lucked into one of the best offices on campus. I should probably be nervous that my provost, my dean, and nearly every other administrator on campus know about my office and view, but I've been too busy withe the business of the department to worry.

Of course, the construction in the rest of the building is still being completed, and there are warts to fix. For example: When I came into the office last Friday morning, the temperature in my office was 63 degrees Fahrenheit; this morning, it was 83 degrees Fahrenheit. After over eleven hours with the windows open and the door open to permit circulation through the department office, I have the temp down to 78 degrees. But I'm sure that this is the sort of kink we can work out over the next few months. (Let's hope so. With windows and western exposure, the summer could proved quite warm otherwise!)

Computer science happens for me these days only in fits and spurts, mostly short ones when I decide to find time to read by downgrading some other task's priority. This summer is my next real chance to do real computing. I've been learning a lot this year, but I hope to put that learning to good use in the future by managing times and tasks more carefully.

There's a title I never had planned for a blog entry.

This isn't really a running post, but if I were not a runner, then it would never have happened. Then again, if there had never been a 09/11, it probably wouldn't have happened, either.

When I go to conferences, I pack for running. For the past couple of years, I have taken powered Gatorade and an empty water bottle with me. Just add water, I have the liquid I need to recover from longer runs. The Gatorade turns out to be a nice drink even on mornings when I don't run -- conferences often don't serve anything but coffee in the morning, and sports drink is low-calorie and high vitamins and minerals.

I pack the powder in a plastic container that seals tight, to keep the powder in and the moisture out. On my trip to Houston, I took tropical punch-flavored powder.

Well, my friends at the TSA must have conducted a thorough search of my bags on the way bag from Houston. When I got home, there was little red powder everywhere, but especially in my running shoes and clothes. I found the plastic container, whose lid had not been put back on tightly. It was in a large ziploc baggy that wasn't zipped 100% either. So the search may have been thorough, but it was not all that careful.

I grumbled a bit about the misfortune, shook my clothes and shoes out carefully, and forgot about it.

Until this morning. When I finished my run, I was changing in the locker room when I noticed that my socks were pink at the ankles. When I got the shoes off, I saw that the socks were mottled pink all over, especially the soles. I must not have gotten all of the powder out of my shoes after all. Now a pair of good running socks is stained irreversibly with red dye #2.

I suppose that I should have done something more to be sure that my shoes were powder-free, but it just didn't occur to me.

Thanks, TSA. Thanks, Al Qaeda.

SIGCSE begins tomorrow, but I arrived early for a pre-conference workshop. Back when I was appointed department head, my dean offered to send me to a workshop for new department chairs. I looked at the three-day schedule, the timing of it, and the cost, and decided that I could use the college's money and my time better in other ways. But then I learned about a workshop for heads at SIGCSE, which I was planning to attend anyway. This workshop lasted only one day and was organized by CS professors, which sounded better to me than three days talking about administration with folks in departments from all over campus. The dean was game to cover part of my expenses, so it worked out for everyone.

The day started with a cautionary tone. Time spent as a department head carries professional risk. Department heads don't do as much research as a regular faculty member, and they don't develop as many courses. The result is that they create little or no "portable wealth" in the academic marketplace. The result can be limited mobility and reduced opportunity for professional development at the home university.

It's worse yet. Department heads have precious few rights, less power than some people think, and lots of tasks that pull them away from research and teaching, which are the reasons most of us became CS academics.

Why would anyone take the job?

Like many of my colleagues at the workshop, I became head as part of a larger set of circumstances than just that I wanted to be head. But after a semester and a half, I know that my reasons for thinking that the job was worth my doing for a few years were right on mark. So I was not discouraged by the gallows humor with which we opened the day.

I won't give you a long, blow-by-blow summary of the day. We talked about all of the big issues that heads seem to face, wherever and whenever they are head: dealing with faculty, dealing with students, finding and allocating resources, managing lab facilities, monitoring legal issues, and "the leadership thing". We wrote down all of the items that would be part of an honest job description (something many of us don't explicitly have!), and it filled many pages of flipchart paper.

Here are some of the nuggets that will stay with me, and some of the things that I want to work on soon as a result of the discussion today:

• Many administrators are prone to put out fires at expense of the longer-range tasks. But managing long-range issues properly can make for fewer fires. Schedule sprints to handle those little things, rather than reacting to every one as it comes in or letting them accumulate into a spirit-sapping mountain of to-dos.
• The department head is responsible for making sure that faculty and staff know the boundaries of behavior defined by law and university policy. Do not assume that faculty, especially junior faculty but also senior personnel.
• If you don't have time to do something, say 'no'.
• If you are asked to do something you know is wrong, say 'no- -- emphatically.
• Always hire people who are better than you.
• Praise excellence.
• Problems don't go away; they only get worse.
• If someone is irreplaceable, then replace them.
• If you think you are irreplaceable, quit.
• Truth is important, whether you are working with students, faculty, or other administrators. Tell people when they need to improve, and help them. Tell people when they are doing well.
• New faculty are more important than the department head. [ To which I add: Old faculty are more important than the department head. ]
• The head succeeds when others get the credit for accomplishments, even for those achieved with the head's ideas.
• Remember that your decisions affect the future of the department for many years. [ To which I add: My decisions as head affect people in many ways, for years to come. ]
• One of the essential tasks of the department head is to fight for equity for faculty and students.

That last hint gives rise to a new item on my will-do-soon list. I plan to conduct a survey of teaching assignments across the departments of my college to see what the real load on other professors really is. I suspect that many math professors engaged in research don't really teach six sections a year, and that many biology and chemistry professors have loads laden with lab courses that do not equate to a CS professor teaching a regular course -- one that likely needs to be updated regularly in order to be of real use to our students. This is something we've talked about in our department for many years, but now that I am head I do not have to settle for talk. Besides, the CS faculty deserve an equitable work load, and it's my job to ensure that they get one.

One thing I learned today is that, compared to many heads, I have a pretty good life. The other heads in my college have always been helpful to me in learning my job and offering advice. My dean is a good person, supportive of our department, and he helps me when he can. My colleagues in CS are, despite everything else, good people who want to do a good job. And they all seem genuinely interested in me doing a job, and they help me when they can. It's worth getting out in the world every once in a while if only to be reminded how good my life really is.

One day was perfect for this kind of workshop. It was long enough to make my mind race with ideas and possibilities, to give me a little burst of energy, but not so long as to become boring or indulgent.

Next up: SIGCSE proper, with some sessions on the future of computing and others on CS topics of particular interest, like compilers. Oh, and a reception at Minute Maid Park. Too bad the Astros are still at spring training!

As a runner, I sometimes fall into the trap of expecting to see progress in my abilities. When I expect to experience a breakthrough every day, or every weekly. I am sure to be disappointed. First of all, breakthroughs don't happen all that often. In fact, they don't happen often at all, and when they do they seem to come in bunches -- PRs on several different routes at several different distances in the span of a couple of weeks. These spurts often tempt me into thinking that I'll just keep getting better and better!

But when these breakthroughs occur, whether alone or in spurts, they aren't really the point. What you did that day, or in the previous week, isn't often directly responsible for the breakthrough. The big gains happen outside conscious sight. After years as a casual runner, I saw my first big improvements in speed and stamina only after many, many months of slow increases of in my daily and weekly mileage. I hadn't done anything spectacular over those months, just routine miles, day after day. This is what the gurus call 'building my aerobic base'. Deeper things were are happening under the surface.

I think that this sort of thing happens when we learn, too. Can I memorize facts and be a whole smarter tomorrow than today? Maybe, but perhaps only for a short time. While cramming doesn't work very well for running, it may help you pass a fact-based final exam. But the gain is usually short term and, more important if you care about your professional competence, it doesn't result in a deep understanding of the area. That comes only after time, many days and weeks and months of reading and thinking and writing. Those months of routine study are the equivalent of 'building your mental base'. Eventually, you come to understand the rich network of concepts of the area. Sometimes, this understanding seems to come in a flash, but most of the time you just wake up one day and realize that you get it. You see, deeper things are happening under the surface.

I think this is true when mastering programming or a new programming style or language, too. Most of us can really grok a language if we live with it for a while, playing with it and pushing it and having it talk back to us through the errors we make and the joy and pain we feel writing new code and changing old code. Students don't always realize this. They try to program a couple of days a week, only to be disappointed when these episodes don't take them closer to being a Master. They could, if they became part of our routine, if we gave time and contact a chance to do their magic. Deeper things can happen under the surface, but only if we allow them to.

"Deeper things under the surface" is a catchphrase I borrow from an article of that name by Ron Rolheiser which talks about this phenomenon in human relationships. After a few months in my department's headship, I can see quite clearly how Rolheiser's argument applies to the relationship between a manager and the people for whom he works. We can all probably see how it applies to our relationships with friends, family, children, spouses, and significant others. I have to work over the long term to build relationships through contact. "Quality time" is a fine idea, and important, but when it becomes a substitute for sufficient quantity over sufficient time, it becomes a meaningless slogan.

But I think this applies to how we develop our skills. Just as in relationships, routine contact over time matters. In this case, absence may make the heart grow fonder, but it doesn't make the heart stronger. The cliche that better captures reality is "out of sight, out of mind".

A lot of techie students aren't comfortable with the sentiment I'm expressing here, but consider this quote from Rolheiser's article:

What's really important will be what's growing under the surface, namely, a bond and an intimacy that's based upon a familiarity that can only develop and sustain itself by regular contact, by actually sharing life on a day-to-day basis.

It may be sappy, but that's pretty much how I have always felt about the programming languages and topics and research problems that I mastered -- and most enjoyed, too.

Two quotes have been running through my mind the last few days, as I have worked on letters of evaluation for faculty on the tenure track or up for promotion:

[Leaders] provide a measure of grace as the antidote to the behavior of people who poison our society with disgrace.

And:

Steeling oneself to become what one is not requires hope. Leaders can give it.

Anyone who thinks that being a manager or a department chair doesn't come with a lot of moral responsibility misunderstands the task.

(Both quotes are from Leadership Jazz, by Max De Pree, a book I'll write more about later.)

My department is doing something new, at least for departments here at UNI: marketing our new programs. The modern university is tricked out with a full-featured marketing and public relations department, much like a commercial firm's own marketing division. I am guessing that universities have long had people who do this sort of thing, if only informally, but over time these offices have evolved into something more. In a cultural and political environment where dollars and (good) students are increasingly scarce resources, universities have begun to market themselves actively. This has typically happened at the institution level, "selling the university" to potential students, to potential donors, and legislative bodies. Sometimes, this marketing extended to major new initiatives, such as an interdisciplinary graduate program or a new push to offer programs by distance education. But individual departments have, as near as I can tell, mostly ridden the coattails of university-wide promotion.

But my department has two new majors, bioinformatics and "networking and system administration", that we would like to promote. One of the goals faculty expressed to me when I became department head was to promote these programs and build up their enrollments and financial support. Department-wide enrollment is down quite a bit over the last few years, as it is at most schools, and these programs are seen as opportunities to reverse the trend by reaching new audiences. By promoting the new majors, we would also increase the visibility of our department -- and the visibility of computer science more generally as an academic discipline. In times of tight resources, this seems almost essential. And, because we are not a "research-intensive" university, or a private college with an elite reputation, we sometimes have to try harder to let people know about us.

(How different that is from when I was an undergraduate student of computer science during the first half of the '80s, or even from the mid-'90s, when almost any school with a CS program or something like it was busting at the seams with students!)

I suppose that we could do the same old things that departments always do when they create new programs, but I think it will be difficult or impossible to broaden our base of potential students with just word of mouth, a new brochure, and a good web site. And considering that the CS faculty and I are not experts at marketing or public relations, we probably would not get fair value for our efforts doing amateurish things on our own.

So, our new bioinformatics professor and I met with one of the principals in University Marketing and Public Relations to talk about how we could do better. In response to our conversation, he and his colleagues developed a full-blown marketing plan, like they would for rolling out a new car or brand of toothpaste. They helped us distinguish between features, which tend to be things that we like about our program, and benefits, which are the things that people in the target market -- whether students, parents, alumni, or industry -- care about. They've designed some new promotional materials and helped us to identify ways to reach our target markets, via e-mail, press releases, outreach events, media liaisons, and so on. Some of the things that they propose are things that we can do for ourselves; others are things that they can do. Some are things that they do for free, like write and issue press releases, and others they do for a fee, like design and print materials. As a department, we are left to decide where best to spend our efforts and our scarce discretionary dollars. For a new department head, it's a challenge, but one that I hope the faculty can help me meet.

Marketing? PR? That sounds awfully unacademic... Some faculty ask, "Are we selling something?" The reality is, yes, we are selling something. Students choose to come to UNI, or not. They choose to major in our department, or not.

I am approaching this endeavor in the most idealistic sense of marketing. Students cannot come here to major in bioinformatics if they don't know that the program exists, or what bioinformatics is, or why this would be a good career or academic choice. Their parents, high school counselors, and science teachers cannot suggest our program, or recommend that students consider careers in computational science, if they don't know about them. Iowa's biotechnology companies won't come to recruit our students if they don't know we exist; nor can they help us educate students with their intellectual and financial resources.

Public information is an essential good in a free market, even an intellectual marketplace. This is especially true for computer science in an era when the popular press feeds folks a steady diet of stories about off-shoring, outsourcing, lay-offs, and the dot-com bust. How can students know that this is the best time ever to be a CS student if we don't share the thrill?

These days, the idea of marketing higher education brings to many people's minds the tactics of for-profit institutions. The worst of these schools mislead potential students, but most just play on the fears and insecurities of unhappy people. That is not the sort of marketing a school like UNI does, and not the sort of thing we want to do.

We will not distort information to attract students or focus on style over substance. Computer science is an academic discipline. We are about ideas -- marvelous, exciting, dynamic ideas! We can't tell students and parents that a major in bioinformatics is easy, a soft road to a risk-free career. It won't "exciting" every moment. Misleading claims of this sort don't do the students, our department, or our university any good. It also doesn't advance the state of our discipline, or improve the world. We can be honest about the challenges of majoring in computer science or bioinformatics while being honest about the good features (er, benefits), too. The key is to get the ideas out there so people can make well-informed decisions.

I don't mind students not choosing to major in CS because it doesn't interest them or fit their goals. But I hate the idea of missing out on students who would enjoy computer science and be good at it because of ignorance or bad information.

If you ever see me hawking our programs on a late-night infomercial, you'll know that I've gone over to the dark other side. But I think we can do this right and do something of value for everyone involved. At least we are trying to make something happen, rather than stand at the whim of the prevailing trends. I'm hopeful that we can doing something really good.

The university's PR folks and administration are excited, too. They haven't done this sort of thing for a new program before, so we are a test case. They like to see departments taking charge of their fates, and in an era of budget cuts and stiff competition with other schools for the best students they see this as a potential avenue to broaden the reach of the university.

Oh, on our department's web site... I know that it is not very good. It has always been designed, implemented, maintained in house by CS professors, and the folks who have volunteered their time to do it have generally been focused more on content than presentation. We are in the process of designing a brand new site from scratch. I've asked one of our grad students with considerable design experience to help me create the new site. My goal for now is simple and effective. I think we are well on our way, which the rest of the world will get to see soon.

I'm approaching the end of my first semester as head of my department. And a busy end to the semester it's been! As I have some time reflect on the last few months, I will have a few things to say about heading a department, the state of computer science and CS education, and the effect of moving to the Big Office Downstairs on my own computer science. For now, I have noticed a couple of things that surprised me a bit

First, no matter how much I planned ahead about management style, I have found myself developing my style as I go.

For example, I find myself regularly sending out long-ish e-mail "memos" to the faculty, and occasionally even to students. Often, these messages aim to jump start a discussion that will continue over time and perhaps culminate in faculty meetings. Other times, I write just to share what I've learned in the various meetings I attend.

I am not alone in this style. Last week, I went to a final public lecture by one of our retiring professors of mathematics, in which he reminisced on 42 years on the faculty here. This gentleman was department head in Mathematics through important years: he was head when the department developed its computer science curriculum and then its first majors, and he was head when Math made plans to spin us off into the the new Department of Computer Science I joined in 1992. In his talk, he told of his habit of writing memos of many pages for his colleagues, typing them up, duplicating them with an old-style mimeograph machine, and placing them in faculty mailboxes. I send my memos to faculty mailboxes, too, but of the electronic variety. And the only duplication I have to do is accomplished when I press the Send button to a faculty mailing list. How much more laborious it was to communicate this way back in the 1970s! Yet David went to the effort, because he, too, felt the worth in sharing information and ideas. In such communication, he empowered his faculty and made them an integral part of the department's progress.

I produce my messages on a more modern contraption. The only real cost I must pay is the time it takes me to write. But, as with this blog, the writing is valuable to me before anyone else even reads the result. I am usually writing to learn, to remember what I've heard and assimilate it into my working knowledge. These messages also serve as a written record, for me and for others, of what has happened. Let's just say this: If I'm ever nominated for the Supreme Court, there will be one heckuva paper trail for my opponents to follow!

Second, it is hard to overestimate the importance of communication.

As I have become involved in matters of evaluating faculty, handling student complaints, and negotiating with other departments on campus for space, money, and other resources, I have found myself spending a lot of energy on speaking and writing clearly and directly. I would have thought that I already had good habits in this regard, from all my years in the classroom. But the effects of ambiguity and miscommunication are more immediately obvious in supervisory activity with faculty and interactions with higher-level administrators. Within a few weeks I noticed that I was stopping and thinking before speaking, in an effort not to say something I would immediately have to explain or undo.

How can I speak the truth in the department's best interest, both short- and long-term? Making clear points with as little ambiguity as possible is essential. This seems to work best as part of a rich relationship among people, so that honesty can be trusted as fair. When communication happens in an unconstrained context, there is simply to much room for confusion.

(On a more technical note... I've noticed this concern for clarity and directness bleeding over into my programming. As I wrote code for my programming languages course this semester, I kept asking myself, "Does this code say what I want it to say?" The result was that I rewrote a lot of old code and crafted new code with greater care. I even occasionally used a comment -- gasp! -- when I used an idiom with which my students weren't familiar. I'm pleased with the results.)

In addition to speaking clearly and directly, I have learned that I want to speak fairly. Consider the task of personnel evaluation. An evaluation of an employee's performance is a deeply personal event for the employee. Without some care, it is easy to write the evaluation in a way that focuses on negatives. And to the person being evaluated, even a balanced letter can feel more negative than it is -- the negative comments appear to be much bigger than they are in comparison to the positives. Our minds trick us with an inverted perspective.

I've found that writing evaluations is a deeply personal event for me. "Personnel" are people. In my case, these folks are my friends and colleagues of many years. I want to write evaluations that clearly and fairly express the person's contribution to our department and the ways in which he or she might improve. Again, this works best in the rich context of a relationship. Maintaining good relationships is an essential element of the new administrator's success.

Some have suggested that I should be more irascible, as a way to command attention, but that's not my style. I'd rather think of even the more contentious interactions as part of a long-term relationship. I realize that there will likely soon come a time when I have to be a hard guy and make a fast stand, but I'd rather save that approach for when it's really needed. By then, my usual demeanor will be what people expect, and my making stand is more likely to attract attention to the seriousness of the issue.

Being fair is in everyone's best interest. I sometimes try to be a mediating force, to help folks see that they don't have to be mean to make their point -- indeed, that the best way to have one's point heard and taken seriously is to be direct but fair. This is not always easy, but I think it is worth the effort. It helps us to build strong relationships, and it pays off by letting the people I work with be partners in moving the department forward.

My friend Kris Anderson sent e-mail in response to my entry on I = k|P|. Here's part of what he said:

So then, I got to thinking about the variable "|P|" in your equation. Absolute value? As I thought about it, Aerosmith's "Dream On" started playing in my head... "Live and learn from fools and from sages..." 'Fools' represent negative values and 'Sages' represent positive values. And since the lesson one can learn from either is of equal value, that's why 'P' must be '|P|'. Very cool.

As I told him, Now that is cool. When I wrote my message, by |P| I meant the cardinality of the set P. Kris took P to mean not a set but the value of some interaction, either positive or negative. The ambiguous |P| then can indicate that we learn something of value from both positive influences and negative influences, like positive and negative examples in induction. I think that I'll stick with my original intention and leave credit for this re-interpretation to Kris.

And who knew that anyone would read my entry and make a connection to Aerosmith? Different people, different familiar ideas, different connections. That reminds of something Ward Cunningham said at OOPSLA 2005.

I learn so much from other folks reading what I write -- yet another example of the point of the article.

It occurred to me today that my intelligence on any given day is roughly proportional to the number of people I talk to that day:

This is true when I do department head stuff. The more people I get information from, the more people I share ideas with and get feedback from... the more I know, and the better I can do my job.

It is true when I teach. When I talk to other instructors, I learn from them, both by hearing their ideas and by expressing my ideas verbally to them. When I talk to students about our classes, whether they are in my class or not, I learn a little bit about what works, what doesn't, and what makes students tick.

It is true when I program. The agile software methods institutionalized this in the form of high degree of interaction among developers. XP raises it to the level of Standard Practice in the form of pair programming. Programmers who refuse to try pairing rarely understand what they are missing.

The value of k depends on a lot of factors, some of which are within my daily control and some of which are in my control only over longer time horizons. On a daily basis, I can seek out the best folks possible on campus and in my circle of professional colleagues available only by e-mail. Over longer time periods, I can choose the conferences I should attend, the academic communities I can participate in, and even where I want to be employed.

We all know the adages about hiring the smartest employees one can, about being the least accomplished person on the team, and so on. This is why: it increases the value of your k!

From my bedside reading this week:

In an age where there is much talk of "being yourself" I reserve to myself the right to forget about being myself, since in any case there is very little chance of my being anybody else. Rather it seems to me that when one is intent on "being himself" he runs the risk of impersonating a shadow.

-- Thomas Merton, The True Solitude

Over the life of this blog, I have used running as a metaphor for software development, for example, in this entry about pace and expectations. But I recently came across running as a metaphor for another part of my professional life: teaching versus administration. This writer compares teaching to sprinting, and administration to marathoning. On first glance, the analogy is attractive.

A teacher spends hours upon hours preparing for a scant few hours in front of the class, and those hours are high intensity and quite draining. I've rarely in other situations been as tired as I am at the end of a day in which I teach three 75-minute courses.

An administrator has to save up energy for use throughout a week. A meeting here, a phone call from a parent there, encounters with deans and faculty and university staff and students... Administrators have to pace themselves for a longer haul, as they have to be up and ready to go more frequently over most or all of their time on duty.

The real test of an analogy's value is in the questions it helps us ask about what we do. So I'll have to think more about this "sprinting versus marathoning" analogy to before I know whether it is a really good one.

I do know one thing, though. If my administrative duties ever make me feel like this, I will return to my full-time faculty gig faster than my dean can say, "Are you sure?"

In my dual roles of head of my department and chair of my university's graduate faculty, I find myself thinking about planning a lot. The dean of the Graduate College is initiating a year-long strategic planning cycle for graduate education university-wide. The dean of the College of Natural Sciences is initiating a year-long strategic planning cycle for our college. As a new head, I am drawn to developing a long-term plan to guide my department as we make decisions in times that challenge us with threats and opportunities alike.

Administrators think a lot about planning, I think -- at least the ones who want to accomplish something do. The cynical take is that strategic planning is what you do when you want to fill up the time in which you should be doing real work. But I think that unfairly characterizes what many good leaders are trying to do.

Now that I am a department head, I see that I have a lot of choices to make every day. Do I approve this course substitution? Do I spend several hundred dollars on a piece of equipment requested by one of the faculty? Do I schedule this experimental course or that? As important, or more so, are the decisions I make about how to spend my time. Do I make plans to recruit students at a local high school? Do I meet with someone in student services about mock interviews for graduating seniors? Do I write an article, study the budget, network with other administrators on campus, work on my own research?

My job is to serve the faculty and students in my department. I serve them by spending my time and intellectual energy to their benefit. Without a shared vision of where we want to go, how do I know how to do that as well as possible? When it comes to making the sort of decisions that the faculty want me to handle precisely because they are routine or should be -- without a shared vision, how do I do this as well as possible?

The same, of course, applies to faculty. As faculty, we want to make choices with their time and energy that both develop our scholarly interests and help the department improve. Without a plan, we are left to divine good choices from among what is usually a large number of compatible choices.

So we as a department need a plan. But not the sort of strategic plan that one often sees in organizations. The bad plans I've seen usually come in two forms. In the first, the plan is essentially defined from above and pushed down through the organization. Without "ownership" and commitment, such a plan is just paper to file away, to haul out for show when someone wants to see The Plan. In the second, the people build a plan bottom-up, but it is full of vague generalities, platitudes with which no one is likely to disagree -- because it says nothing. Often, such plans are long on vision and values but short on objectives and actions that will achieve them.

I do not have much experience with strategic planning, and certainly none of the sort I want to have before doing it with my department. But I am thinking about strategic planning a lot, about how I can help my department do it in a way that is worth our effort and that helps us move in the right direction.

I've begun to observe a skilled facilitator lead the strategic planning cycle for graduate education here, and I've already learned a bit. She is leading a large group of stakeholders in something that operates like a distributed writers workshop from the PLoP conferences: we will work in groups to identify strengths in the current system, weaknesses in the current system, opportunities to improve the system, and threats to the system. Then we will combine our suggestions toward identifying commonly-held views upon which to build. I hope to learn more from this process as we proceed.

As for my department, I am hoping to proceed in a more agile way, as in the planning game. Our mission will play the role of system metaphor in XP. I want to do just enough thinking about the future that we can identify goals whose success can be measured concretely and the metric for which we identify before taking the actions. As much as we can we will work and make decisions as a whole team, with frequent evaluation of our progress and adjustment of our course as necessary.

I know that others have explicitly tried this sort of approach in a non-programming context, but there is nothing quite like doing something yourself to really learn it. The sooner we get to "code", the sooner we can collect feedback and improve.

One of my favorite early episodes of the American sitcom Friends has a subplot focusing on Chandler as supervisor at work. When Phoebe comes to work part-time as his secretary, he learns that he is no longer "one of the guys". His charges talk about him as boss, imitate his idiosyncratic speaking inflections, and generally don't like him anymore. At first, his feelings are hurt, and then he just feels separated and a little lonely. Of course, Phoebe falls in with the gang and even takes to calling Chandler "Boss Man Bing".

Could it be any more obvious where I'm going with this?

There are moments when I know just how Chandler felt. Moving into a supervisory position creates a separation that can hardly be avoided. The Big Office Downstairs is, well, downstairs, out of the regular action that is a usual day among the faculty. Especially in these early days, while we become accustomed to our new roles relative to one another, it's almost unavoidable that some awkwardness will intrude on what used to be comfortable or even close relationships. And where relationships were already a little tense, tension becomes even more palpable.

That said, I am in a pretty good situation, at least compared to Chandler. I work with a pretty good group of people, and we all seem to be adjusting pretty well to the new situation. One of the things that made this job worth applying for -- in the presence of whatever problems the department may face -- is that, at bottom, we are a group of good people who have our sights on goals that we can all aspire to. We socialize well together and even play well together, as yesterday's department picnic and post-dinner volleyball game showed.

Besides, as far as I can tell, no one has developed a good Boss Man Wallingford impression yet. (Actually, I am the most likely mimic in the department, and you should hear me do me!)

However, in moments of dispiritedness -- brought on by the bad breaks of a day, by the fatigue of long hours and a deluge of new tasks to learn and do, or by my sagging biorhythms -- it's easy to feel left out. Sometimes the best thing to do is to seek out a friend and colleague just to chat. It doesn't matter about what, though talking about our latest classes or the minutiae of daily academic life bridges the gap quite nicely.

Academic departments have an advantage over many business environments in this regard. A department head is more "first among equals" than supervisor or manager, which means that in the long run it seems possible to drive the gap to epsilon, for a very low value of epsilon. There will always be certain decisions that the head has to make, but strong relationships and an understanding on the part of all that such decisions must be made can minimize the separation that these decisions bring to mind.

All of this requires some effort, though. Not the frantic denial that Chandler wants to execute on Friends, but simply working together, building trust in communication and decision making, sharing ideas, information, and -- whenever possible -- control over the department's course. But then I already knew that.

I can only determine how I behave and contribute to these relationships. That what I hope to do.

Ultimately, Chandler came to embrace the new relationship with his former compatriots, even playing along by giving them imitable material. I hope in my situation to create an environment in which we all feel like contributors, with me doing what I can to help the faculty take the department in the most productive direction possible.

Okay, somebody's gonna be working... this weekend.

When I was a in school, I was a pretty good student. The first class I ever remember not "getting it" immediately was Assembler 2, at the beginning of my sophomore year in college. The feeling was a bit scary.

Our first assembler course was the "traditional" assembler course, in which we learned basic computer organization and the magic of MOV, JNE, and LD commands. But this was the early 1980s, and my school required a second course in this area. In the second quarter, we did more assembly language programming, but we also learned JCL and how to control an IBM 360/370 at a fine level of granularity from the moment execution began. Our card decks and key punches and assembly language programming became a bit more complicated.

For whatever reason, the different levels of abstraction in the 360/370, when combined with the massive gulf between the problems we were programming and assembly language, left my head spinning. I didn't get it. Good student that I was, I kept plugging away, doing what we were taught in class, getting mostly correct answers -- but not really understanding why. And when I did understand something, it did not feel natural. and scored well. But I was worried, because I didn't get it. I didn't feel like I was in control.

Then one morning, everything changed. There was no great epiphany, no flash of light. I was simply standing in the shower when I realized, ever so naturally, that it all made sense. I walked to class, and all was again right with the world.

Since that time, I have had this sort of experience a few more times. The learning process moves slowly for a while, with the effort exerted exceeding the gains in understanding. Then, there seems to be an acceleration in understanding, like compound interest on the effort exerted earlier in the process. Once I got used to the idea that this would happen, it wasn't so threatening to me, and I was able to proceed with relative confidence deep into new ideas that I wasn't getting -- yet. But there is always a nagging thought at the back of my mind that this is it -- I've finally reached a point I won't be able to get.

Runners have an idea that bears some resemblance to this upside-down learning process, called negative splits. The simplest form of negative splits is when the first half of a run is slower than the second half, but the idea generalizes to any number of splits. For the mathematically inclined among you, think of a monotonically decreasing sequence of split times.

In running, negative splits are generally considered a good thing. They are wise as a training strategy, as they ensure that you do not use up all of your energy too soon. Plus, they cause you to run faster at the end of the workout, which trains your body in the feeling of working hard when it is tired. They are often a wise racing strategy, too, for many of the same reasons. Many racing greats have set records running negative splits.

As I have learned over time, there is a corresponding danger -- going too slow in the beginning. If I am trying to get better, I need to be careful not to create negative splits by virtue of not working hard enough early on. In a race, this can waste the opportunity to reach a goal. But for endurance training, it's hard to go too wrong with negative splits. The goal is to do the miles, and negative splits maximizes the chance of completing the miles successfully.

Recently I wrote about my happiness with some long distance workouts. You will now notice that both my 20-miler and my 22-miler were characterized by negative splits. Much of my happiness comes not so much from running fast as from running faster as those long runs progressed -- in some cases, with eight or more miles increasingly faster than the previous.

I've come to realize that negative splits in learning, of the sort I experienced in that second assembler course, are also often a good thing. Learning requires our minds to change, and that change often takes time. Changing habits, practices, and expectations is hard, because our minds are well-suited to remembering and employing patterns of thought as a strength. Some of us even have a harder time than others changing mental habits. I am one of those people.

Runners use negative splits as an explicit strategy, but for the learner change often forces us to accept negative splits. They are simply cognitive and psychological reality. Coming to accept that, and treating negative splits as the way we sometimes must learn, can free us from a lot of fear and uncertainty. And surrendering that fear and uncertainty can help us learn even better.

Students should keep this in mind. (And remember, we are all students.) Teachers should keep this in mind, too. We need to take negative splits into account for many or all of our students, especially with the most challenging or abstract material. This is one of the elements of teaching that calls for a little cheerleading, a little reassurance to students that they should hang in there with the tough stuff, with the promise of it all coming together sometime soon.

Leaders of every sort -- even department heads -- need to keep this principle in mind, too. Introducing change to an organization has all the hallmarks of trying to learn new habits and practices. People feel fear and uncertainty. This is complicated by the fact that sometimes the change must come to personal interactions, which carry a lot of extra psychological baggage with them. Negative splits may be a wise strategy for the leader, introducing small, easier-to-master changes first and only accelerating when people gain confidence and realize their own strength.

That old assembler course... I had one of my favorite CS professors ever in that course, one who taught me so much about systems, software, and professionalism. I still have the textbook on my bookshelf, too: System 360/370: Job Control Language and the Access Methods by Reino Hannula. Early in that semester, the name "Hannula" raised fear in students' hearts, was veritable poison to the ears. When we all got it, it became a beloved totem of our collective experience. And the greatest lesson we learned in the course probably wasn't IBM JCL -- as cool as it was -- but the idea of negative splits.

After a couple of weeks in the Big Office Downstairs, I've been reminded how important some elements of human psychology are to group dynamics:

• People want to be valued and respected for what they do and know.
• When a person interprets any disagreement as a sign of disrespect, communication becomes difficult, if not impossible. (When two such people come into contact -- watch out.)

A close friend of mine is police chief of a small town back in my home state. When I was visiting him a couple of weeks ago, he shared some of his experience as an administrator. He jokingly said that his job consists in three roles: manager of budgets and schedules, leader among his staff and community, and daycare provider. We both knew what he meant. Neither of us really thinks of our administrative jobs in such a condescending way, but it is clear that working with people is at least as important as the "paper pushing" elements of the job, and in some situations can dominate.

That said, the paper-pushing side of things creates challenges, too. I am already finding the constant flow of information -- new things to do, new items for the calendar, new ideas to try out -- to be overpowering. In response, Remind and VoodooPad have become my friends. (As has the Remind widget.)

Remind is a plain text Unix calendar tool. I considered using iCal for a while, but my preference for plain text data and low-frills interfaces pushed me toward Remind. After only a week, I was quite happy. I can add new entries to my databases with any editor, and I can script other applications to add them for me. The one thing I'd like is a better way to view weekly or monthly calendars. By default, Remind prints out days in fixed-width columns that result in the squashing and breaking of words. Of course, that's the beauty of a plain-text tool: If I want a different interface to my data, it is straightforward to write one. (I feel a student project coming on...)

VoodooPad is just way cool. I tried OmniOutliner for a few months after first accepting my new position, when I was busily creating list of ideas and to-dos. I liked it all right, but it never felt natural to me. VoodooPad makes it easy to create links to new pages, using either CamelCase or command-L on any text selection, so I get the effect of collapsible sub-lists in wiki form. The program is also integrated with other OS X apps and services, such as Address Book and Mail, so I get free linking to my other on-line data and can launch an e-mail message with a single click. In one tool, I have a note taker, a wiki, a to-do list manager, and a decent text editor. There's a reason that VoodooPad is one of MacZealot's top 10 shareware apps of 2005.

Using great tools means that I can eventually focus my energy on the Big Picture. I say "eventually" because, right now, mastering some details is the Big Picture.

My term as department head began on Monday. I feel a bit overwhelmed with all I'd like to do right: plan for the long term, plan for the short term, learn more about our budget, create a list of faculty committees to assemble, meet individually with more faculty members about their goals and interests for the year, sift through all the notes I took in various meetings this summer, .... I have a natural desire to do it all at once, to be up to speed and at full capacity right away.

I also feel a nagging, almost subconscious apprehension that I won't do as well as I have imagined I might. In my application and interview for the position, I made some strong claims about openness, transparency, respect, fairness, and leadership. Now the promises made in the safety of no responsibility meet the reality of responsibility.

Oft expectation fails, and most oft there
Where most it promises; and oft it hits
Where hope is coldest, and despair most fits.

-- William Shakespeare
All's Well That Ends Well (II, i, 145-147)

I think that my best course of action in the face of seemingly overwhelming possibilities and a fear of failure is familiar to many of you: approach the task in an agile fashion. Take small, measurable steps. Communicate with my team, and let them contribute their many ideas and talents. Get feedback wherever possible, and use it to improve both the process and content of my work.

I've been think about how I might adapt ideas from Scrum and XP as explicit practices in the administrative side of my job. My thoughts are ill-formed at this point, so they are read neither for implementation nor description just yet. But I think a big visible chart is in the offing.

The key is to keep moving, to be making progress in concrete ways.

When George Hellmeier of Bellcore received the Founders Award from the National Academy of Engineering, he related the tale of his first discovery in liquid crystal technology. When he told Vladimir Zworykin that he had "stumbled upon" his discovery, Zworykin replied "... to stumble, one must be moving."

Sadly, the moving that is most occupying my mind and time these days is moving my office. In 13 years here and another 10 before that as a student of CS, I have collected a lot of book. And a lot of papers. And a lot of software -- on 5-¼" floppy, 3-½" floppy, zip disks, and CDs. In the depths of a filing cabinet, I found shrink-wrapped copies of Microsoft Windows 95 and Office and Visual Studio. And cables for 1992 Mac Quadras. On top of most all of this was a layer of dust that betrays my lack of cleaning over the last few years. I hope to have things set up in my new office by the end of the week so that I can get down to the real business of leading my department.

After being informed repeatedly that I will need either a Windows box or Office for the Mac in order to be a department head, due to the sheer volume of Word and Excel documents that flow through the university hierarchy, I found hope this piece of news. If Norway can do it, why not the State of Iowa or my university?

I once read a letter to the editor of our local paper calling for the state to adopt an open-formats-only policy, as a matter of fairness to competing businesses and to citizens. Alas, the benefits of standardization far outweigh the long-term economic effects for most people. Philosophical issues rarely enter the discussion at all. I suspect that it's easier for this sort of edict to originate at the top of a heap, because then groups lower in the hierarchy face a consideration that trumps standardization.

In any case, I think that I will get by just fine, at least for now. I could use OpenOffice, if I feel like running X-windows. But my preferred tool these days is NeoOffice/J, which is getting more solid with every release. (It's finally out of beta.) While it's not a native OS X app -- it looks and feels like a Windows port -- it does all I need right now for handling files in Office formats.

I have spent many, many years of gently encouraging department heads not to send me Word files, offering alternatives that were as effortless as possible. I'm not sure if I'm ready to take on higher levels of university administration. But I do feel some obligation to lead by teaching on the issue of open standards in computing.

Update (08/22/08): Situational Leadership ® is a registered trademark of the Center for Leadership Studies, Inc. This accounts for use of the ® symbol and the capitalization of the phrase throughout the entry.

The more I think, read, and learn about management and leadership, the more I believe that managers will succeed best if they invert the traditional pyramid that has the president of a company at the top, managers in the middle, and employees on the bottom. I wrote about my credo of leader-as-servant in a recent essay. Now consider this quote:

... managers should work for their people, ... and not the reverse. ... If you think that your people are responsible and that your job is to be responsive, you really work hard to provide them with the resources and working conditions they need to accomplish the goals you've agreed to. You realize your job is not to do all the work yourself or sit back and wait to 'catch them doing something wrong', but to roll up your sleeves and help them win. If they win, you win.

This is from Page 18 of "Leadership and the One-Minute Manager", by Kenneth Blanchard, Patricia Zigarmi, and Drea Zigarmi. I've not read Blanchard's "One-Minute Manager" yet, but I ran across this thin volume in the stacks while checking out some other books on leadership and figured it would be worth a read. I've read some of Blanchard's stuff, and I find his staged storytelling approach an enjoyable way to learn material that might otherwise be pretty dry.

This book extends the principles of the one-minute manager to "situational leadership", the idea that managers should adapt how they work with employees according to the context, specifically the task to be done and the employee's level of competence and confidence with the task. This approach emphasizes communication between manager and the employee, which allows the two to agree on a leadership style most suitable for the situation.

On this approach, leadership style is "how a manager behaves, over time, when trying to influence the performance of others". The authors are careful to remind me that my style is not what I say my style is, or how I mean to behave, but how others say I behave. This reminds of a basic principle of object-oriented programming: a message is interpreted in the context of the receiver, not the sender. The same principle applies to human communication.

In order to be a good situational leader, a manager must have three skills:

• diagnosis, the ability to determine the needs of employees according to their development level with the task at hand
• flexibility, the ability to apply one of four different styles, depending on the diagnosis, and
• contracting, the ability to work with employee to set the parameters of their interaction

Diagnosis

An employee's development level and performance are a product of two variables, which Blanchard call 'competence' and 'commitment'. I tend to think of these variables in terms of skill and confidence. Whatever the terms, managers would do well to think about these variables when facing inadequate performance in the workplace. Performance problems are usually competence problems, commitment problems, or both.

Blanchard asserts that most people follow a typical path through this two-dimensional space on the way from being a novice to being an expert:

• Level 1, low competence and high commitment
• Level 2, some competence and low commitment
• Level 3, high competence and variable commitment
• Level 4, high competence and high commitment

The odd change in commitment level follows the psychology of learners. Novices begin with a high level of commitment, eager to learn and willing to be instructed. But, "as people's skills grow, their confidence and motivation drop". Why? It's easy to become discouraged when you realize just how much you have left to learn, how much work it will take to become skilled. After commitment bottoms out, it can recover as the learner attains a higher level of competence and begins to see the proverbial light at the end of the tunnel. Blanchard's whole approach to Situational Leadership ® is for the leader to adapt her style to the changes of the developing learner in a way that maximizes the chance that the learner's commitment level recovers and grows stronger over time. That is essential if the manager hopes for the learner to stick with the task long enough to achieve a high level of competence.

I accept this model as useful because I have observed the same progression in my students, especially when it comes to problem solving and programming. They begin a course eager to do almost anything I ask. As they learn enough skills to challenge harder problems, they begin to realize how much more they have to learn in order to be able to do a really good job. Without the right sort of guidance, university students can lose heart, give up, change their majors. With the right sort of guidance, they can reverse emotional course and become powerful problem solvers and programmers. How can instructor provide the right sort of guidance?

As an aside, I have a feeling I'll be approaching Development Level 2 soon with my new administrative tasks. At times, I have a glimpse of how hard it will be to manage all the information coming at me and to balance the number of different activities and egos and goals that I encounter. Maybe a little self-awareness will help me combat any sudden desire to cry out as Job. :-)

Flexibility

The way a manager or instructor can provide the right sort of guidance to a particular employee at a particular point in time is to choose a leadership style that fits the context. There are four basic styles of leadership available to the situational leader:

• directing
• coaching
• supporting
• delegating

Like development levels, the leadership styles are a combination of two variables: directive behavior, by which the manager carefully structures the environment and closely supervises the employee, and supportive behavior, by which the manager praises, listens, and helps the employee. The idea is to choose the right combination to meet the needs of the employee on a particular task at a particular moment in time. As the authors say, "Leaders need to do what the people they supervise can't do for themselves at the present moment."

We can think of the four leadership styles as occupying quadrants in a 2x2 grid:

To match the unusual path that most people follow through the levels of development, a situational leader needs to follow a particular path through the two-dimensional space of leadership styles, in the order listed above: directing for Level 1, coaching for Level 2, supporting for Level 3, and delegating for Level 4. While the actual progression will depend on the specific employee, one can imagine the stereotypical path to be a bell-like curve from the lower left of the grid, up through the top quadrants, down through the lower right of the grid:

• As the employee's competence increases, the leader slowly reduces the degree of directive behavior, eventually to 0.
• As the employee's confidence wanes, the leader slowly ratchets up the degree of support provided. This helps the employee get through periods of doubt and eventually regain a confidence born out of competence. When that confidence arrives, the leader slowly reduces the degree of support provides until the employee is managing himself.

This progression can help students, too. They usually need a level of coaching and support that increases throughout the first year, because they can become discouraged when their skills don't develop as quickly as they had hoped. At the same time, the instructor continues to structure the course carefully and direct their actions, though as the year progresses the students can begin to shoulder more of the burden for deciding what to do when.

Communication remains important. Managers have to tell employees what they are doing, or they are likely to misinterpret the intention behind the leadership style. An employee who is being directing will often interpret the manager's constant attention as "I don't trust you", while an employee who is being delegated to may interpret the manager's lack of attention as "I don't care about you". When people lack information, they will fill in the blanks for themselves.

Contracting

That's where contracting comes in. The situational leader communicates with the people he supervises throughout the entire process of diagnosis and style selection. The person being supervised should be in agreement with the supervisor on the development level and thus the leadership style. When they disagree on development level, the supervisor should generally defer to the employee, on the notion that the employee knows himself best. The manager may then contract for a bit closer supervision over the short-term in order to confirm the diagnosis. When they disagree on leadership style, the employee should generally defer to the manager, who has developed experience in working with employees flexibly. Again, though, the manager may then agree to revisit the choice in a short time and make adjustments based on the employee's performance and comfort.

Communication. Feedback. Adaptation. This all sounds 'agile' to me.

....

Blanchard relates the Situational Leadership ® approach to "teaching to the exam":

Once your people are clear on their goals..., it's your job to do everything you can to help them accomplish those goals ... so that when it comes to performance evaluation ..., they get high ratings....

For Blanchard, teaching to the exam is a good idea, the right path to organizational and personal success. I tend to agree, as long as the leader's ultimate goal is to help people to develop into high competence, high commitment performers. The goal isn't to pass the exam; the goal is to learn. The leader's job is to help the learner succeed.

Like the agile methods, this process is a low ceremony but high in individual discipline, on the part of both the leader and the learner.

What should the situational leader do when a novice's performance is way out of bounds?

You go back to goal setting. You say, 'I made a mistake. I must have given you something to do that you didn't understand. Let's backtrack and start again.'

Trainers have to be able to praise, and they have to be able to admit to mistakes. We teachers should keep this in mind -- we aren't often inclined to admitting that we are the reason students aren't succeeding. Instructors do face a harder task that Blanchard's managers in this regard, though. Situational Leadership ® is based on one-on-one interactions, but an instructor may have a class of 15 or 30 or 100, with students at various levels of development and performance and confidence. In an ideal world, all teacher-student interactions might be one-on-one or in small groups, but that's not the world we live in right now.

As I read books like this one, I have to keep in mind that my context as teacher and future department head is somewhat different from the authors'. A department head is not in the same relationship to the faculty as a manager is to employees. The relationship is more "first among equals" (my next leadership book to read...). Still, I find a lot of value in learning about how to be more self-aware and flexible in my interactions with others.

One thing I have noticed in my last few weeks preparing to move into the Big Office Downstairs: I view the actions of the administrators around me in a different light. Where I might have reacted immediately to some behavior, often negatively, I now am a bit more circumspect. What could make that seem the right thing to do? If nothing else, I am aware that I will soon be in the position of having to make such decisions, and it probably looks easier to do than it is. Kind of like playing Jeopardy! from the comfort of your own home... even Ken Jennings is an easy mark when you're sitting on your sofa.

Swapping roles is a great way to develop empathy for others. This is certainly true for students and teachers. I do't know how many students who, after having to teach a short course at work or having to lecture in place of a traveling advisor, have told me, "I never knew how hard your job was!" Those students tend to treat their own instructors differently thereafter.

Playing many different roles on a software team can serve a similar purpose. Developers who have tested or documented software often appreciate the difficulties of those jobs more than "pure" developers. Of course, playing different roles can help software people do more than develop empathy for their teammates; it can help them build skills that help them do all the jobs better. Writing and testing code come to my mind first in this regard.

Empathy is a good trait to have. I hope to have more of it -- and put it to good use -- as a result of my new experience.

UPDATE 08/03/06: Near the end of this entry, I had originally used a cartoon image for comic effect, with a link to the author's web site. However, I had not obtained legal permission to use the image. The author asked me to remove the cartoon from the entry. I have replaced it with a description of the gag.

++++

Before I applied to be department head, I was discussing the idea with some colleagues over dinner at the spring planning meeting for OOPSLA 2005. During that conversation, Brian Marick asked me, "What kind of leadership can a department head provide?"

The question shouldn't have caught me off-guard, but it did. I'd been so busy thinking about the details of administration, the politics of my own department, and the mechanics of applying that I hadn't spent enough time thinking about the big picture, about the universe of what a head can and should accomplish.

I gave some mumble-mumble answer to Brian at the time, but afterward that question consumed a lot of my energy over the next week or so, as I wrote up application materials. How might I answer the question now? Here are some of my thoughts. As always, I'd love to hear yours.

What kind of leadership can a department head provide?

Within the department itself, the head's primary jobs are to remove friction and facilitate discussion. Removing friction means making sure that the department runs in such a way that faculty can do their jobs without interference. The head must take care of paperwork, routine interactions with students and university, and any other issue that distracts the faculty. The head should facilitate discussion so that the faculty can set the course for the department. In order to accomplish this, the head must work to create an environment in which all feel comfortable participating in and contributing to the department's welfare. In this regard, the head's job is to help the faculty do its job, only better.

At the boundary of the department and the world, the head's job is one of agency. First, the head advocates for the department at the college, university, and regents levels, ensuring that the faculty's concerns are heard and arguing its case for the resources it needs to achieve its goals. Second, the head represents the department to students, parents, the university community, the civic community, and the computer science community. (As I wrote recently, I realize now that a non-trivial component of this representative role can be thought of in terms of the department head as teacher.) To be an effective advocate and representative, the head must care deeply for the department and its purpose. I do.

Finally, I believe that a department head can provide a form of personal leadership, by setting an example of open communication, transparent decision making, and respect for others. A good head does not settle for a passive stewardship of duties but instead seeks actively to help the faculty define and achieve its goals.

----

As I thought about applying for the position, and then went through the process, I sometimes wondered if I were putting myself in the same position as the narrator a classic comic I once saw. Two cavemen have set a trap for a saber-toothed tiger: a box sitting over a hunk of meat and propped up by a stick. When the tiger comes to partake in the treat, the cavemen will pull a rope tied to the stick and drop the box down on top of the unsuspecting diner. The visual punch line: the cavemen are standing under the box, too.

What was I getting myself into? But ultimately I acted with confidence, because deep down I believe that leading my department is a worthwhile task, an opportunity to help my colleagues achieve something honorable.

For my assignment as department head, I have adopted the following quote as my credo:

The first responsibility of a leader is to define reality. The last is to say thank you. In between the two, the leader must become a servant and a debtor.

-- Max DePree, Leadership is an Art

(I found it in a wonderful little book I first learned about at Ward's wiki, on a page about wonderful little books.)

And, besides, if I do find myself trapped under a box with the tiger that is my faculty, I can take solace that my current appointment as Keeper of the Box runs for only three years...

Some folks have expressed concern or even dismay that my becoming department head will pull me away from teaching. Administration can't be as much fun as the buzz of teaching, with its paperwork and meetings and bureaucracy. And there's no doubt that teaching one course instead of three will create a different focus to my days and weeks.

But the more I prepare for my move to the Big Office Downstairs, the more I realize that -- done well -- a head's job involves a fair amount of teaching, too, only in a different form and to broader audiences.

To address the problem of declining enrollments in our majors, we as a department need to educate students, parents, and high school counselors that this is the best time ever to major in computing. To ensure that the department has access to the resources it needs to do its job effectively, we as a department must educate deans, provosts, presidents, and state legislatures about the nature of the discipline and its needs. And that's just the beginning. We need to help high schools know how to better prepare students to study computer science at the university. We need to take educate the general public on issues where computing intersects the public interest, such as privacy, computer security, and intellectual property.

These opportunties to teach are all about what computing is, does, and can be. They aren't one of those narrow and somewhat artificial slices of the discipline that we carve off for our courses, such as "algorithms" or "operating systems". They are about computing itself.

The "we"s in the paragraph above refer to the department as a whole, which ultimately means the faculty. But I think that an important part of the department head's job is to be the "royal we", to lead the department's efforts to educate the many constituencies that come into contact with the department's mission -- suppliers, consumers, and everyone in between.

So, I'm learning more about the mindset of my new appointment, and seeing that there will be a fair bit of education involved after all. I'm under no illusion that it will be all A-ha! moments, but approaching the job with an educator's mind should prepare me to be a more effective leader for my department. The chance to educate a broader audience about computer science and its magic should be a lot of fun. And, like teaching anything else, the teaching itself should help me to learn a lot -- in this case, about my discipline and its role in the world. Whether I seek to remain in administration or not, in the long run that should make me a better computer scientist.

I ran into this quote over at Ben Hyde's blog:

Customers have a tendency to become like the kind of customers you treat them.

Ben related the quote as a commentary on trust in commerce. (Trust and social relationships are ongoing themes of his blog.) He notes that he has observed this truth in many situations. I have, too. Indeed, I think this truth applies in almost all human relationships.

(Like all generalizations, this one isn't foolproof, so feel free to prefix each of the following claims with "by and large" or your favorite waffle words.)

Parents and Children

Children grow into the people you expect them to be. The best sort of discipline for most children is to create an environment in which children know what your expectations are, and then live consistently in that way. Nagging youngsters doesn't work; they come to expect you to nag before they know you care about something. Yelling and screaming don't work, either; they come to think that you don't believe they can behave without being verbally assaulted. If you simply set a standard and then live as if you expect them to meet the standard, they will. When they don't, don't resort to needy negative reinforcement. Usually they know they've fallen short and strive to do better the next time.

Teachers and Students

Students become what their teachers expect of them, too. If you act as if they are not trustworthy, say, by creating elaborate rules for late work, cheating, and grading, they will soon look for ways to game the system. If you act as if they don't respect class time, say, by wasting it yourself through lack of preparation or rambling digression, they will soon come not to value their time in class.

If you set a high standard and expect them to learn and achieve, they usually will. If you trust them with masterpieces, they will come to value masterpieces.

Developers and Users

The quote applies to all sorts of developer/user relationships. If software developers don't trust their clients, then their clients will start to look out for themselves at the developer's expense. If an API designer acts as if programmers are not smart or reasonable enough to use the API wisely, and so creates elaborate rituals to be followed to ensure that programmers are doing the right thing, then programmers will look for ways to game the API. The result is hacks that confirm the API designer's expectations.

Agile methods place a high premium on developing a mutually beneficial relationship between the client and the programmer. The result is that programmers and clients feel free to be what they should be to one another: partners in creating something valuable.

Managers and Team Members

This truth is a good thing to keep in mind for someone embarking on an administrative or managerial position. When "bosses" treat their "employees" as adversaries in a competition, the employees soon become adversaries. They do so almost out of necessity, given the power imbalance that exists between the parties. But if a manager approaches the rest of the team with openness, transparency, and respect, I think that most members of the team will also respond in kind.

Husbands and Wives

All of the relationships considered above are hierarchical or otherwise imbalanced. What about peer relationships? I think the assertion still holds. In my many years of marriage, I've noticed that my wife and I often come to behave in the way we think our spouse expects. When one of us acts as if the other is untrustworthy, the other comes to protect his or her own interest. When one of us acts as if the other is incapable of contributing to a particular part of our lives together, the other stops caring to contribute. But when we act as if we are both intelligent, trustworthy, caring, and respectful, we receive that back from each other.

----

Given its wide range of applicability, I think that the truism needs to be restated more generally. Perhaps:

People tend to become like the kind of people you treat them to be.

Or maybe we can restate it as a new sort of Golden Rule:

Treat people like the kind of people you want -- or expect -- them to be.

Or perhaps "Do unto others as you expect them to be."

Last weekend, while my daughter was doing a final practice for her Suzuki Book I recital, I picked Vaclav Havel's The Art of the Impossible: Politics as Morality in Practice off the piano teacher's bookshelf for a little reading. This is a collection of speeches and short essays that Havel in the first half of the 1990s about his role as dissident, reformer, and president of the Czech Republic. He is, of course, famous as a poet, and his writing and speaking style have a poet's flare.

I ended up spending most of my time with Havel's speech to the Academy of Humanities and Political Sciences in Paris on October 27, 1992. (I just noticed the date -- that's my birthday!) This speech discussed the different forms of waiting.

The first kind is sometimes characterized as waiting for Godot, after the absurdist play by Samuel Beckett. In this form, people wait for some sort of universal salvation. They have no real hope that life will get better, so they hold tightly to an irrational illusion of hope. Havel says that, for much of the 20th century, residents of the former communist world waited for Godot.

At the opposite end of the waiting spectrum lies patience. Havel describes patience as waiting out of principle -- doing the right thing because it is right, not out of any expectation of immediate satisfaction. In this sense, patience is "waiting as a state of hope, not as an expression of hopelessness". Havel believes that the dissidents who ultimately toppled the communist regimes behind the Iron Curtain practiced this sort of waiting.

When the curtain fell and the people of, say, Czechoslovakia took their first unsteady steps into the light of the western world, folks practicing the different forms of waiting encountered distinctive problems. Those who had been waiting for Godot felt adrift in a complex world unlike anything they had known or expected. They had to learn how to hope and to be free again.

You might think that the patient dissidents would have adjusted better, but they faced an unexpected problem. They had hoped for and imagined a free world around them, but when they became free things didn't change fast enough. Havel relates his own struggles at being too idealistic and now impatient with the rate at which the Czech and Slovak republics assumed the mantel of democratic responsibility. Like many revolutionaries, he was criticized as out of his element in the new world, that he was most effective in the role of dissident but ineffective in the role of democratic leader.

What struck me most about this essay came next. Havel recognized the problem: He had waited patiently as a dissident because he had no control over how anyone but himself behaved. Now that the huge impediment of an authoritarian regime had been surmounted, he found that he had become impatient for all the details of a democratic system to fall into place. He no longer waited well.

In short, I thought time belonged to me. ...

The world, Being, and history have their own time. We can, of course, enter that time in a creative way, but none of us has it entirely in his hands. The world and Being do heed the commands of the technologist or the technocrat....

In his own transition from dissident to democratic leader, Havel learned again that he had to wait patiently as the world takes its "own meandering course". He asserts that the "postmodern politician" must learn waiting as patience -- a waiting founded on a deep respect for the world and its sense of time. Read:

His actions cannot derive from impersonal analysis; they must come out of a personal point of view, which cannot be based on a sense of superiority but must spring from humility.

When the world changed, even in the way for which he had been working, Havel had to learn again how to be patient.

I think that the art of waiting is something that has to be learned. We must patiently plant the seeds and water the ground well, and give the plants exactly the amount of time they need to mature.

Just as we cannot fool a plant, we cannot fool history.

I think that 'waiting patiently as the world takes its own meandering course' translates into showing respect for people and the rate at which they can assimilate new ideas and change their behavior.

Perhaps this speech affected me as it did because I am now thinking about leading my department. I certainly do not face a situation quite as extreme as Havel did when the communist regime fell in Czechoslovakia, yet I am in a situation where people do not trust the future as much as I'd like, and I need to find a way to help my department move in that direction. As Havel reminds me, I cannot move the department myself; I can only patiently plant the seeds of trust, water the ground well, and give the plants the time they need to grow.

The value of this sort of waiting is not limited to the world of administration. Good instructors need to wait patiently, working with students to create the atmosphere in which they can grow and then giving them time and opportunity to do so.

I also think that this sort of waiting holds great value in the world of software development. Agile methods are often characterized by folks in the traditional software engineering world as impatient in their desire to get to code sooner. But I think the opposite is true -- the agile methods are all about patience: waiting to write a piece of code until you really know what it should do, and waiting to design the whole program until you understand the world well enough to do it right. In this sense, traditional software engineering is the impatient approach, telling us to presumptuously design grand solutions to force the world to follow our senses of direction and time. The worlds in which most programs live are too complex for such hubris.

I cannot resist closing with one last quote from the rich language of Havel himself:

If we are certain that the planting was good and that we are watering regularly, we have no reason to be impatient. It is enough to realize that our waiting has meaning.

Waiting that has meaning because it grows out of hope and not hopelessness, from faith and not despair, from humility toward the time of the world and not out of fear of its sublime tranquility, is accompanied not by boredom but by suspense. This kind of waiting is more than just waiting.

It is life. Life as the joyous involvement in the miracle of Being.

That sounds like a poet speaking, but it could be a programmer. And maybe the world would be a better place if all administrators thought this way. :-)

I've been thinking a bit about how much the agile software development mindset affected my application for department head. When I first starting making notes for my statement of administrative philosophy, I jotted down some agile ideas: communication, people over processes, trust. Later, as I made notes for my presentation to the search committee, I again had a bullet for agile ideas, with feedback and continuous improvement appearing.

In the end, many of these ideas played important roles in my application. Open communication and building trust became cornerstones of my philosophy. Feedback and continuous improvement became cornerstones of my plan for doing the job. I never got around to using the term "agility" in any of my materials, but its footprint was everywhere.

My administrative philosophy rested on three points:

• open communication
• transparent decision making
• respect for individuals

These principles are essential to any healthy organization. They are perhaps even more important in an academic department, which consists of individuals who are both highly autonomous but also interdependent. They are especially important in a department fraught with lack of trust and persistent interpersonal conflict.

These principles are also very much a part of the agile software movement. Communication fosters trust and enables feedback, which is how we learn to do our jobs better. People matter. What about transparent decision making? Only decisions are made openly can everyone involve contribute to the process. I believe that, in most situations, more ideas lead to better results. Furthermore, when someone disagrees with the decision that is made, at least the person can trust that the decision was made fairly and on principle.

Some folks think that preferring people to processes means having little or no process. Others think that not tying themselves down with process (in administrative parlance "procedures and policies") frees them to adapt better to changing circumstances. Though I value adaptability, and people over process, I believe that appropriate process is essential to effective operation. XP isn't just a set of values or a set of principles; it is also a set of practices. These practices support the values and principles, make it possible for the team to live its values and embody its principles. I hope to help my department develop an appropriate set of procedures and policies. This will involve streamlining some of our existing procedures and implementing some new ones.

Soon after I submitted my application materials, a related discussion developed on the XP discussion list. It started with a request for advice for navigating the waters of corporate politics and soon turned into a discussion of how the principles and practices of P can help us to create a good corporate environment. Along the way, someone said,

Ok, those are good suggestions for navigating oneself through everyday relationships, in and out of work. But they are not techniques that are specific to XP.

The answer to this assertion is both yes and no. Certainly, communication, feedback, continuous improvement, and the like are not specific to XP or any other agile methodology. But they are fundamental to the agile methods, and by making them explicit the agile methods help us to reflect and act on them more readily.

As I told my colleagues and the other members of the search committee, I harbor no illusions that I will do this job perfectly. But I hope that, by making explicit the values that I hold and the principles that I think should guide our department, I hope to do a good job -- and to get better as I go along. This will depend in great part on the level of trust and communication that we are able to develop.

As mentioned last week, I recently applied for the position of department head in my home department. After interviews scattered over the final three days of last week and a weekend of wa-a-a-iting (cue Tom Petty), the Dean called me yesterday to offer me the job. I start on August 1.

I will continue to teach one class each term, for a total of three a year. So I expect to keep blogging about teaching and learning and software development on a regular basis. But because I blog mostly to examine what I am doing and learning, I expect that I'll be posting a new thread of messages over the next three years to examine the administrative and leadership side of my job. To this end, I am creating a new category, Managing and Leading, for this thread.

(Those of you who come here to read about running, fear not! That thread will continue as usual. I've run 74 miles in the last 11 days, so I have plenty of raw material!)

Some of my first entries in this new category will likely deal with what I've been reading about working with people, leadership, and technical administration. I think I've been subconsciously preparing for this role for a few years. But I still have a lot to learn.

My official start date is August 1, but I'll be putting significant energy into the job before then. As I said, I have a lot to learn. Busy, busy, busy.