Techfoot

Back in the olden days, I was one of those people whose bedtime was established by end of the Johnny Carson monologue. Carson’s opening act often included an interchange where he would lead with the line “it’s hot/cold/smoggy and the audience would respond “how hot/etc. was it?” to set up the joke. To this day, when someone makes a statement “it’s whatever”, my mind responds with with the audience’s line. “How whatever is it?”

This time of year, I spend a fair amount of time trying to figure out “how bad is it”–not as a way of setting up a joke, but in trying to figure out what problems are important enough to solve “at the root” rather than just dealing with the symptoms. For example, we’ve opened a new building on campus and one of my staff members just spent about a third of last week dealing with issues have nothing to do with academic technology–she’s chasing down questions about wire molding, conduit, network connections, door locks and other stuff that clearly is not her responsibility. (I guess these things are technology related in some broad way–they all do have wires.) She gets the questions because she knows all faculty in the building and because there is no clear communication path established as to who really is responsible. When we try to figure out a way to deflect those questions so she can focus on things are clearly are her job she comes back to the relational question: “If not me, who?”.

In complex, decentralized, underfunded organizations, figuring out who actually does have the responsibility for even something (relatively) simple like coordinating all those building changes (and then documenting the process) may require hours of phone calls, meetings, memos, negotiations and communications–even staff training. Deciding whether or not to try to fix the root problem is a judgment call that we make dozens of times a day, and, more often than not, it’s easier to just spend extra time to solve the immediate problem rather than to try to dig down and fix the root. Our faculty are busy folks and they’re generally very appreciative when someone–whoever–helps them.

But I have to wonder what the long term cost is when “fixing the symptom and ignoring the cause” becomes ingrained in the organizational culture and it becomes the accepted way of doing business. In my real (non-William and Mary) life, I much prefer to deal with organizations where the simple things are simple. No matter how helpful, friendly, and courteous someone might be in helping me navigate the corporate run-around (think Cox or Comcast here), I much prefer not not to get embroiled in a mess in the beginning. I’m wondering if we’re as much a part of the problem as the solution?

Some time ago I was responsible for a camp in the Ardirondacks with a big dam that controlled our lake. One summer we had some problems and had to bring in an engineering firm to do some work, and one of the engineers was explaining why building dams is so expensive. Generally about 90% of the work is invisible: rerouting stream beds, pouring footings and installing other infrastructure elements that, on the surface, have noting to do with stopping the flow of water. While that’s true, the entire project has no value unless you finish the job and do the last 10% that actually stops the water.

In some ways many academic IT projects are a little like that, but with the numbers reversed. Buying and installing hardware and software, configuring systems and running pilot tests all take time and technical expertise. But for many of our projects, the real work that produces gains in teaching, learning or productivity just begins when those initial projects are completed. Producing those gains may take years of communication, evaluation, training and re-engineering. I wonder how many of us really understand that and commit to finishing the job when we launch some new initiative. Would we focus our time differently if we were more realistic about what we were committing to?

Photo by Flickr User Farm3 under a Creative Commons Attribution License

Worth a Listen on IT Conversations Overcoming Bias.

We live in a world of cognitive biases and polarized opinions. We consider ourselves to be largely rational, yet we are often prone to systematic errors such as overconfidence, wishful thinking, and the attraction of strong opinions. This means decisions are often driven more by personalities and passions rather than technical merits. Economic theorist Robin Hanson explores common errors, and points to innovative tools such as prediction markets which can help overcome bias and promote truth.

George Mason economics professor Robin Hanson gave this short speech at the O’Reilly Open Source Conference last year about how cognitive biases get in the way of our accomplishing goals that would make our organizations function better. Bias is the a systematic tendency to produce errors in our judgment. (One way of defining the purpose of education is to help individuals understand these typical human errors and overcome them for the betterment of society.)

Most of know that intellectually. We know that our inability to accurately estimate project times and costs creates all kinds of wasted effort, and that it’s incredibly hard to get ideas accepted on many of our campuses because of our natural tendency to glamorize our own ideas and discount those not invent here. This tendency toward wishful thinking and over optimism is so pronounced, that managers of software developers really

Most of us are passionate about something–vegetarianism, open source, the Red Sox–but, in this talk, Hanson suggests that our greatest passion should be for doing the hard work to overcome biases to come to the truth. One key to betting better at reducing errors in our judgment is to invest some time in investigating our actual track records. Most organizations would be well served by spending some serious time analyzing both failed and successful projects to establish better estimating procedures.

After one of my academic advisors worked with me for a while, she came with what she called the half-it/double-it rule. She’s ask me when I might get her the next draft, and I’d tell her 20 pages, end of next week. She’d half-it (reduce the goal to ten pages) and double-it, (increase the time to two weeks). Having goals that were tied to the time it actually took me to write–rather than speed I wished I could write–made the whole project more manageable.