Post by Charles McIntyre, UCSC. It seems like everything I read and hear these days, from EDUCAUSE to Harvard Business Review to MBA programs, is discussing how to deliver more innovation in IT. Webster’s definition of innovation is “to begin or introduce something new.” My question is, “what are the ingredients for innovation for IT at UC?”
The UC IT community is extremely diverse – from desktop support and Rails developers, to high performance cluster admins and DBAs, to project managers and network security analysts. Our IT portfolio spans small- and large-scale systems, mission-critical business systems and small experimental ones, systems with sensitive data, and others that require full transparency.
In the academic and medical worlds, innovation is required and will make or break a department. Faculty members are driven to develop cutting edge technology to be successful in their research. And innovative technology from UC is used in almost every business sector, from high tech to construction.
What is the secret sauce that enables areas and pockets of the university to deliver innovative and sustainable information technology solutions? Is it external business pressures? Or a charismatic engineer or manager? Or something else completely? What are the building blocks that have fostered successful innovation? Let me know your thoughts.
—Charles McIntyre, Manager, Infrastructure & Operations, Applications & Project Management, UCSC.
I think this is a great question and very timely for our UC system with the challenges the University faces in the teaching, research & patient care missions. In my role, getting to work with many groups across the UC, I see tremendous local innovation. But the missed opportunity I witness is one of NOT expanding on local innovation for greater benefit. Information Technology is becoming more & more integrated in the way we teach, discover, and (even more basically) interact. Our ability to take those local innovation, and then expand & take them to scale, with speed – is critical to UC mission sucess.
I do believe it starts with people. People generate thoughts & ideas; and people interact with other people to turn ideas into action; and action is required for there to be innovation. However, years of research have taught us that innovation can be taught and replicated as a process. Therefore, I believe beyond people we need to think about the process by which we put people together, how we organize them & the steps we use to support them to bring out the best results. Lastly, I would speak to culture. When we talk about people working together, getting aligned, rewarding them – it becomes an issue of the type of culture we have – as a team, a location, and ultimately as an (UC) organization. We as IT leaders spend a lot of time talking about how we create greater collaboration across the UC. We know a collaborative culture is key to supporting innovation.
There’s my reaction to you, Charles – creative people, a replicatible process, and the right culture
Thanks Tom for the response. Regarding scaling local innovations, the Lean Startup and Design Thinking methodologies look to be promising.
I think it’s largely cultural. We seem to value stability and routine over innovation, possibly because we believe that’s what the university ‘wants’. That may be an illusion, though. We may not always get a lot of direct pressure to innovate but the need is still very real. Taxpayer dollars, just like sales dollars, can dry up. Then we have no choice.
I agree, and who wants to work at an organization where things are only routine. People need the ability strive, grow, try succeed and fail. I was on a panel at Educause this year and someone made the comments about risk-averse IT seems to be in Higher Ed. I don’t understand why that would be the case. We work with faculty who by their very nature are very entrepreneurial & risk-takers. How is it that we build the completely opposite culture in the same environment? And maybe also just as important, what impression does that leave with them?
Fair point . . . did you know that recent research pegged 94% of IT staff to be “risk-averse.” That’s cross industry. I would wager we’re even a little more risk averse in Higher Ed. Man, do we have some culture to change!
Empowerment at the action level. No one knows a process better than the person that does the job, day by day. These are the people that best know where the kinks are, and what has led to the greatest successes in the past. Give those that do the direct work a feeling of ownership, and I think you’ll find a wealth of ideas.
Often enough, it seems that the recipe for that ‘secret sauce’ is something like this:
– Start with an idea for a small change.
– Add a pinch of “what we’ve wanted to do for a long time”
– Start cooking
– In a separate bowl, set people’s expectations and let them rise over time
– Bake half way – make sure it’s long enough that there’s no turning back
– Set your high expectations on top of your half-baked idea
– Sprinkle on some important questions that should have been asked earlier, and return to the oven for an indefinite amount of time
– Remove from the oven and panic about what we’re committing to here
– Come up with some brilliant innovations to make this thing edible (or at least put some frosting on it to make it presentable)
I’ve seen some brilliant innovations happen this way, but that doesn’t mean they’re the “right” innovations – in fact they often serve to lock us in and make future innovation more difficult.
I think a better recipe might be something like:
– Deal with your infrastructure and ops so that you have a stable service to build on
– Bring a governance team together and make sure they understand both the technical and functional perspectives
– Make technologists and clients work together to propose innovation ideas
– Prioritize ideas, then let the team loose to plan exciting things
– Do exciting things after you’ve done some planning
Yes, and how can we make that new recipe happen in days versus months?
Charles’ question as well as Tom’ and Glenn’s responses made me think of Steven McCormick (Moore Foundation) and his talk on how to “Drive Change through Entrepreneurship.” McCormick describes that the world is VUCA (Volatile, Unpredictable, Chaotic, and Ambiguous) but non-profits (including public education) are consensus-driven and thus slower to respond. McCormick states that because non-profits have no clear measures of success (like profitability is a quantifiable measure of success for the private sector), we become focused less on results and more on tactics. Further, due to the ethos of our culture, if we disagree with a given decision, we don’t always align. So, the secret sauce may be for us to find ways to promote entrepreneurial activity (rapid prototyping, taking risks, and seeing mistakes as constructive) within our consensus-driven and process-laden culture.
I think by giving people “small latitudes” to be risk takers is a great place to start. Big ideas get big attention. That’s tough in our setting (I agree with you), but what if we let people do small things outside the box? With 7000 IT professionals, if we could inspire 20% to take small risk in the month January, that’s 1400 people doing something different/new. Try & wrap your head around that. These type of numbers can add up quickly.
I love this topic, and what Charles, Tom, and Jim rings true to me… I would add a few more I gradients as well though: Passion, Courage and Teamwork:
1). Passion:
A critical ingredient is a passion for the University of California, and its mission of Teaching, Research and Service. A passion for the pursuit of excellence in all aspects of what we do, especially promoting and providing wellness and healthcare for the great state of California with a focus on continuous improvement.
2) Courage :
Another critical ingredient is having the courage and the ability to pursue a vision of a more collaborative and exciting future where the IT community participates as partners. UC technologists need to be brave enough to take risks in trying new things, where we have permission and the freedom to try new things even if they fail. Technologists need the and permission to try creative “pilots” with the faculty and students in creating the “NeXt” Generation of the incredible University of California.
3). Teamwork :
Teamwork is mandatory; only together, with our vast diversity in all aspects can we as new “Digital Citizens” in this new and much more greatly connected age, as constituents, IT staff, students and faculty can we accomplish the goal of the continued greatness of the legacy that is the University of California.
My post:
I love this topic, and what Charles, Tom, and Jim write about rings true to me… I would add a few more Ingredients as well though: Passion, Courage and Teamwork:
1). Passion:
A critical ingredient is a passion for the University of California, and its mission of Teaching, Research and Service. A passion for the pursuit of excellence in all aspects of what we do, especially promoting and providing education, wellness and healthcare for the great state of California with a focus on continuous improvement.
2) Courage :
Another critical ingredient is having the courage and the ability to pursue a vision of a more collaborative and exciting future where the IT community participates as partners. UC technologists need to be brave enough to take risks in trying new things, where we have permission and the freedom to try new things even if they fail. Technologists need the confidence to plan and execute on creative “pilots” with staff, faculty and students in creating the “NeXt” Generation of the incredible University of California.
3). Teamwork :
Teamwork is mandatory; only together, with our vast diversity in all aspects can we as new “Digital Citizens” in this new and much more greatly connected age do what is required. We, the diverse constituent groups of the UC: Technologists, Knowledgable staff, Students and Faculty together, can accomplish the goal of the continued greatness of the legacy that is the University of California.
Reply ↓
Amen sister!
I think Rose really brings those three ingredients to life in her work at the UC. It makes a huge difference to our projects and cross campus efforts.
Charles
Could you please define what you mean by innovation? This word is all over the map and can mean different things.
Most of what I see in terms of what we call innovation in the tech world is adoption. That is being aware of a new ‘thing’ and seeing if it applies to our situation.
As an example, we finally realized that Gmail/Google Apps was a better way to do our email business. It was simply an act of realiation, which for ITS might have seemed new, but for many of my clients they were already using Gmail/Google apps.
I think my last sentence is wrong 😉 it should be
“It was simply an act of realization that Gmail/Google Apps was the better path…
‘
Why is the I.T. staff risk-averse? Much of our job is to provide commodity infrastructure: move your packets, store your data, don’t drag the customers into having to think about those items. Innovation is easier in areas the customers do not yet depend on, so screwups and bad design decisions are less costly. The hardest area to innovate in is an existing service. For example, an ivy-covered professor learned in 1985 the sequence of keystrokes to display his e-mail using Berkeley Mail, and now you want to drag him to a webmail interface.
I’ve seen a lot of innovations go sour because the implementers ignored the basic paradigm: goals first, then identify issues, and take action with those under control, not as the first step. For example, someone said “our website is a disaster and we need a content management system”. See the issue? We went to a lot of trouble to install a content management system and nobody has ever used it. What they wanted was a HTML editor. They love the HTML editor. But they don’t even know what the content management features are. We should have gone with a much simpler framework whose centerpiece was the HTML editor.
Innovations often fail at the end of beta testing. First the implementer uses it him/herself. Then he sics it on the I.T. staff and maybe some other early adopters, for beta testing. When beta testing begins the team should commit to a date, like one month future, at which time they have already committed to roll the product out to the whole department, unless needed fixups delay the rollout. We switched mail user agents, and the new one was stuck in beta for two years; the only thing that broke it loose was a new manager and a capacity issue on one of the servers which the new MUA would mitigate.
The hardest part of innovation is non-technical issues.
You raise some good examples, and I agree with you – when goals are not clear, we start a quick path toward failure. However, if we can get to that clarity, then the process for innovation is pretty well documented. That doesn’t ensure success by any stretch.
However, as I speak with people in our system (and Higher Ed in general) the feeling is we don’t push on the status quo enough. I personally can deal with a failure now and again. If there’s no failure, then it signals to me we are not trying enough to get beyond the status quo.
I’m working on a big sample size when I talk about the UC. A 1% change in 7000 people translates into big change and big (positive) impact. That’s what I’m talking about
“There is no reason anyone would want a computer in their home.” — Ken Olson, president, chairman and founder of Digital Equipment Corp., 1977
Innovation covers many things. Creating something new that people may or may not want.
Using something that has been created and is trending to more and more usage.
My experience with introducing something new is the lack of selling the idea and training in its use as well as a lack of desire to change. This is an audience issue.
If you have a very large population as your target audience for something new, then you have a good chance of it being adopted at a level that will cross the threshold of viability. That population tends to segment itself with younger people adopting faster.
Then there is the incremental adoption of something which was new and is now sort of getting old.
Electricity in the home comes to mind.
For me, innovation is not about creating something totally new or original in my local workspace. It is about bringing new things in to my current environment and adapting them and then introducing them to my client population.
My perception, biased as a developer, is that innovation isn’t perceived as a compelling constant, driven from internal resources, priorities, and growth, but as a sporadic pressure or general managerial malaise created by the increasing contrast between technical debt and stagnation on the back-end and the expectations of contemporary users on the front-end. As such, it isn’t so much a defined, positive force as a nagging and nebulous one, often addressed in fits and starts with temporary budgets yet rarely sustained as a culture.
This leads to a lot of implementations of third party vendor solutions and usage of external consultant resources, maximizing the effectiveness of one-time, project-specific funds, but failing to grow the skill set of the developers supporting these third party implementations in the longer term. While the initial implementations feel successful and immediately relevant, most of them leave a legacy of expensive customizations, isolated (sometimes redundant) home-grown skunk works projects, and very niche black-box support skill sets for proprietary systems, making programmer/developer positions difficult to market and fill.
So, moving on from describing the water we’re drowning in, what could be the positive, sustainable drivers for innovation? Projects with smaller sprint cycles and fewer, yet more defined goals. Big Bang enterprise projects using a waterfall deployment cycle have got to go. Shorter sprint cycles require a stronger, more effective & communicative developer culture and a less layered and officious deployment & testing process, which are all good things. The scale of user buy-in and consensus also needs to be reduced to fit these shorter goals.
I do feel like we’re gradually swimming in that direction, mostly because we have to; I just hope that we begin to use fewer of these expensive vendor “solutions” as life buoys along the way. They’re not serving us well in the long run and feel more like anchors to me.