A Big Question

3

The great thing about starting up a blog is that you get asked interesting questions. Even something as vanilla as my introductory post brought some good comments (and some help in setting up the Word Press theme; thanks!). Then along comes Ruby Bright and asks one of the big questions. As Ruby so beautify put it,

How do you get buy in for institutional change when the culture is exactly as you have described: Rooted in success and afraid to take chances?

I’m not all that sure that I have the answer to this question; if I did I’d be rich and famous. People have written books about the problem (Crossing the Chasm is probably the most famous). I’ve thought about the problem a lot. And so have a lot of others, much smarter than I. When I worked at Sun Microsystems, this was a constant topic of conversation. It caused the company to move from workstations to servers (an innovation that worked), and to support Java (much more innovative, but maybe not so successful financially), but in the end we didn’t find another innovation that the company could support. I’m sure that this is a topic of conversation (all the time) at places like Google, and Facebook, and Microsoft. Doing something new is really hard, especially when what you are currently doing is working well. It is even harder when you are well known, because then everything you do is watched by everyone, and there is the worry that failure will dull (or even ruin) your reputation.

I remember seeing this risk-aversion develop in the Java organization. When Java first came out, the people working on the project thought of it as a new way of writing software, with the virtual machine, object-oriented language, and portability from machine to machine no matter what the operating system. There were all sorts of new things that we wanted to try. Innovation piled on innovation. It was really fun.

But then Java took off, and we had other companies as partners and the price of the company stock was determined by the latest news story on something that had gone wrong (or, less often, something that had gone right) with Java. Within a couple of months the question stopped being “what new can we do with this shiny thing?” and became “how do we keep from making any mistakes?” And a lot of innovation was stopped or never started.

Fortunately for those of us who want to innovate in the IT world of Harvard, we aren’t under quite the same set of constraints. Harvard is not, at core, an IT organization (or at least it doesn’t believe that it is, at core, an IT organization– this may be the subject of a future post). Since IT is a support for the core activities of teaching and research, we are not under quite the same microscope as we would be if Harvard were a hi-tech company.

And innovation, as I continually tell my colleagues in HUIT, is not an activity that can be planned, or managed, or controlled by some process. It is messy, and unpredictable, and requires leaps of faith. It is hard. But there are a couple of things that seem to help.

I’m a big fan of skunkworks projects– small groups of engineers that go off and build something out of sight of most everyone. This is a great way to build a prototype. You need to do it fast, and you need to understand that you might fail, and be willing to take the risk. But with the right people this can work amazingly well. The first version of what became the Common Object Request Broker Architecture (CORBA) was written by a group of 5 engineers in six months in a skunkworks (I had the great pleasure of leading that team). When we did the Jini work at Sun, the team was hidden from the rest of the organization by being put (organizationally) in Human Resources. Making such an investment is something I hope we soon have the freedom to do, at least at some scale. It may be that we involve students to keep the costs down, but we should try something.

I’m also a fan of importing good ideas from elsewhere, and then making them our own. This may be in the form of adopting an open-source solution that we then customize for Harvard. It may be in the form of taking work someone else has done here, and adapting it for a new purpose. To quote the sage Tom Lehrer, “brilliance borrows, genius steals.” We should be unashamed of using the work of others (always respecting IP laws, of course, and giving credit where it is due).

But most of all, we need people to be willing to take risks. Managing projects in any organization is like managing a financial portfolio– if you want major rewards, you need to allow some risk. You don’t want every investment to involve major risk, but you need to have some to balance the low-risk parts of what you do. It is best to manage risk with some vision of where you want to go; this is a vision of the future. I’m trying to encourage some risk taking in the organization, and there is plenty of support for trying this out. We will see if it will allow us to innovate. I think it will, if we let it.

previous:
Trying out the blog…
next:
Open Office Hour

3 Comments »

  1. Larry Bouthillier

    July 28, 2011 @ 12:24 pm

    1

    “Rooted in success and afraid to take chances” sounds very similar to the position incumbent leaders are in when they are about to be displaced by a disruptive innovation. Solid, successful organizations try to meet their customers’ needs by focusing on improving the quality of existing services and service models. Why not – after all, they are successful and are what the customer says they need?

    But disruptive innovations begin by targeting a population of users who are unserved by current offerings. The disruptive service is always inferior in some way (if not many ways) to the established service, but it serves people who were previously non-consumers of the original service. Eventually, it improves and displaces the original service entirely.

    I think one of the great opportunities for innovating our IT services at Harvard is to look for these gaps – look for the places where our assumptions are leaving potential users with unmet needs while we focus on providing an arguably higher-end service to fewer people.

    There are lots of potential examples that bear investigation, even in my own area. We invest heavily in high-def video conferencing infrastructure while many faculty and students just use Skype. We strive to create and publish broadcast-quality recordings of classes, while some faculty are just doing it themselves with a Flip cam or an iPhone. Many schools have sophisticated video streaming servers closely managed by IT, while their faculty are using YouTube and Vimeo to publish their material.

    These ad hoc solutions aren’t as “good” as what we are providing, but they reach users and meet needs we can’t. It challenges our assumptions about what “good” actually means when it comes to the services we offer, and points to areas ripe for innovation.

  2. raman

    August 2, 2011 @ 1:17 pm

    2

    Related to last Friday’s CTO office hours, the federal government is another institution that is starting to open source its software:

    Available on github, this project includes wordpress themes, ruby, RESTful APIs, json, etc:

    http://www.federalregister.gov/learn/developers

  3. Gary McGath

    August 2, 2011 @ 1:25 pm

    3

    Harvard is a feudal-bureaucratic organization and operates on a very different dynamic from a business organization. Success here doesn’t mean excellence or good sales, but the preservation of one’s position. Change in that type of organization is almost always threatening. Responsibility tends to be static; people aren’t encouraged to grow, but to fit in. Out-of-band communication is discouraged because it disrupts the hierarchy.

    The University Library Committee process, which ended only recently, provides an illustrative example. Once a year, the ULC would set the agenda for HUL OIS. These people, while highly competent in their own field, aren’t primarily
    technologists and couldn’t know in detail what’s involved in a software development organization, nor were they allowed to talk to developers. The result, inevitably, wasn’t a plan for technological advancement and intelligent maintenance, but the preparation of a wish list that for lack of any other process became the agenda for the next year. This is now gone, but nothing has replaced it.

Leave a Comment