Q&A
7 Questions with Higher Digital's Joe Gottlieb and Joe Moreau
Effective change management addresses the cultural and workforce shifts that accompany technology transformations in higher education. Here's how to take a holistic approach to IT change across the institution.
Technology leaders in higher education have long recognized that IT initiatives are as much a matter of people and processes as they are about the technology itself. In fact, the "secrets" to successful IT projects are evergreen: Transparent communication, understanding institutional culture, and forging relationships were key themes in a 2015 Campus Technology article entitled "8 CIO Tips for Leading Change in Higher Education," advice that still holds true today.
But knowing those truths in theory doesn't make them any easier in practice. In CT's 2022 Digital Transformation Survey, respondents pointed to culture, digital literacy of constituents, organizational silos, and lack of clarity as some of the biggest obstacles to digital transformation at their institutions, second only to budget restrictions. Why are cultural issues still standing in the way of change for so many college and universities? To answer that question, we spoke with Joe Gottlieb, president and CTO of digital transformation consulting company Higher Digital, and Joseph Moreau, former vice chancellor for technology at Foothill-De Anza Community College District and now an executive consultant for Higher Digital, about the challenges of change management and how institutions can better navigate the evolving landscape of technology in higher ed.
The following conversation has been edited for length and clarity.
Campus Technology: In higher education, it seems like there's general consensus that digital transformation is important, that technology is evolving rapidly, that investment in IT is of strategic importance. So why is change management still so difficult?
Joe Gottlieb: Change management is hard because change is hard for people. It gets down to that human-nature reflex that we get whenever we're uncomfortable or facing something new. And despite all the technology we have, and the motivation we have to use it, change is a people challenge.
Secondly, it's hard because there are just so many moving parts across people, processes, and technologies. We tend to lack the overarching habits and processes and systems necessary to master those moving parts. It's complex. And in higher ed, it's even more complex than in many industries, because higher ed has a complex organizational structure. There's complex governance. You are delivering a value proposition in teaching and learning, but you're also a landlord for real estate; you have medical facilities; oftentimes you're a retail establishment; you've got food service.
Joe Moreau: There's also an enormous amount of fear: people fearing that they're not going to be successful in whatever it is they do for the institution, or fear that they're going to lose their job. You're going to ask us to do this new technology thing and you're going to automate all these tasks, and you're asking me to work myself out of a job. Or you're going to ask me to do a different job that I don't know how to do, and then I'm going to fail at that job and you're going to fire me because I couldn't do the new job.
That fear is legitimate. I've dealt with it for decades. Every time there's a change, whether it's virtualization or cloud or automation or self service, it always turns out that somebody's afraid they're going to lose their job — if not immediately, then in the near future. It's about assuring people that there's so much work to be done, we couldn't possibly afford to lose one head. Your job may change, but we're going to make sure that you are prepared for that change.
CT: Culture and fear of change are age-old problems. So are the obstacles to change just the same as they've ever been? Or are there new obstacles in the mix?
Gottlieb: For at least 30 years, probably 50 years, we've been adopting software that's custom-built for us. We force the vendor or our partners to customize the software to fit how we are organized, how our departments are structured, how we are presently trained to do one thing or another, the way we like to do a process a little bit different than the next institution. We have this habit of imposing our will on technology. And that's no longer the best way to adopt technology — frankly it's almost impossible to adopt it that way.
That's why there are so many people stuck on these customized, brittle, unchangeable, unimprovable systems. You see some institutions that are still on 20-year-old-or-older versions of software that they customized long ago — and once they did that they calcified the tech stack. They literally eliminated their opportunity to get new features from the vendor, or even make changes based upon their own process changes.
There is a big change happening now: The move toward adopting SaaS, and in particular single-version SaaS. When you get to the mature point of delivering software as a service, it is multi-tenant SaaS, meaning everyone's using the same version. That's what gives you great leverage in terms of managing and maintaining your software. That's the objective for the vendor, because it makes them higher margins, keeps everyone on the same page, on the same software, but then it also allows them to keep everyone moving forward.
When you pick your vendors and adopt what they have delivered in their SaaS, that means you have to change. There's organizational change management and process change management required in the way that you adopt software. And notice I use the word "adopt," not "implement," because "implement" really reflects the way we once deployed customized software. We're not doing that anymore; we're adopting what is there now. So how do we adopt it? How do we adjust the way we do things in an industry-standard manner, the way they're being done in these automated software-as-a-service offerings? Only then do you put your fingerprints on it — you take these systems and you point them in directions that reflect the way you're going to innovate — but within a configurable frame and not a customized departure.
Moreau: Going back to these notions of fear and culture: I have an institutional culture. I may have contributed immensely to the calcification of a system, as Joe mentioned, and it may be burdensome —but I own that system, and that gives me a certain amount of clout and authority and control in my culture because I'm the one who knows that system best. Nobody can do anything without passing it by me, because I know how that calcified thing works. And if I give that up for a standards-based approach in, say, a SaaS model, I've automatically lost my clout, my voice, my feeling of self-worth. Those are cultural elements — those are people challenges that are triggered by technology. That's where fear rears its ugly head in culture.
CT: Could you paint a picture of what good change management looks like? How do you get people to give up that autonomy and overcome that fear?
Gottlieb: It starts with leading toward your vision. What is this institution all about? What is our vision and mission for how we are uniquely delivering our teaching and learning offerings to our students? What does that look like? What does that feel like? The best change management practices start with good governance, and I mean coherent, iterative governance and guidance from leadership. That includes iterative prioritization in the context of finite resources.
A second important principle of good change management is serving users as customers. Yes, students are a really important user, but if your broad team of employees at an institution is responsible for delivering value and curating the student experience, you have to make sure they're effective at using your systems as well. And so in IT, this is about delivering value as a service organization that can think about, okay, am I rolling out bite-size chunks that they're going to understand? Do I have to think about training? Do I really care about the reaction? Because if I feel like I'm done and I throw it over the transom, I'm only creating another problem. So it's taking the medicine, doing it right, serving customers, and delivering change in small chunks that are easier to digest.
And then the third principle we talk about is tracking results against objectives, and course-correcting as priorities and new information dictate. And this is where the iterations are so important. Whether you're Agile or not, it's important to give yourself the latitude to act on new information. It's okay to change priorities — it's actually super smart. There's a reflex that goes on where people say, "Oh no, no, no, we've got to stick to the plan." Well guess what? That plan was a guess at a point in time. Keep the far-reaching goal more ambiguous — like a strategic imperative, like the way you're going to measure value, like the way you're going to define success — and then iterate and adapt to what you can learn.
Moreau: The foundation of that is data about the change you're trying to make. This is one of the things that I think is really powerful about the Higher Digital methodology: We start by gathering lots of data from as many stakeholders as possible, and bringing that data and visualizing it and putting it in front of everybody to say, "We know we have this challenge. Here's what everybody thinks about it." A lot of times you find that 90% of the organization feels one way and 10% feels another way, and the people who have significant fear and anxiety about change end up saying, "Well, alright, if everybody thinks we should do it that way, then okay, I guess we need to think about it."
The other thing that I have found over many years is that people who want to be obstructionist in the change zone are eager to throw out definitive statements that are absolutely not true. I call it the mythology of IT. They say, "We can't change that because the law says this, or the regulation says that, or the policy says this, or the software doesn't do that, or students want this," and nine times out of 10, those definitive statements are simply not accurate. We have to get into a method of challenging those without being nasty: "Okay, maybe that's the case, but let's see the citation for that. And let's really make sure that it says what you thought it said or what I thought it said." First of all, it may have said that 20 or 25 or 30 years ago, but it may have changed, and we just never caught up with the change. Or it may have said that and we all thought it meant X, but we've subsequently had interpretations by counsel or the legislature, and it really doesn't mean that, it means this other thing. Or it meant that in the era of XYZ, but it doesn't mean that in the era of ABC. We have to be open to challenging our assumptions about the way we've done things, because there may, in fact, be a better way to do it.
CT: Can you share some common misconceptions about change management?
Moreau: The big one that I've seen for a long time is that institutions assume change management is a one-time thing — that we're going to do it for this project, and then once we've done it, we're done. But it really needs to become part of the fabric of the institution. It needs to be a muscle that the institution can flex regularly and consistently. The plan that we started with may not be the plan we want to keep going with, because we've learned new things through all of these discussions as we've implemented new things and we've gotten to know the product better. We thought it was going to be this way — that was a sound decision when we made it — but based upon what we know today, it's no longer sound. How do we then go back through that process to modify our plan based on new information or new assumptions about how we're going to do this?
Gottlieb: I would add that change management is not project management. Project management is all about managing a particular project: It gets into the details of one project, what needs to be done, etc. That can be Waterfall project management or Agile project management, but the fact is project management is really focused on the details. Change management has to look across the portfolio of projects, because that's the only way you can prioritize.
Another misconception is that lots and lots and lots of detail will help predict the future. We're not magical. We don't have crystal balls. We have information, and it's useful to use your information to make decisions around what you're going to do in shorter timeframes — and then you keep looking at new information as it comes. If you can switch to that mentality, if you keep it more lightweight, and you do it more frequently, now you have what I like to call "rudder control" over your organization. Rudder control is a concept in sailing, where if you're not at a certain velocity, you don't have enough resistance on the rudder to steer the boat. As soon as you have just enough forward motion, you suddenly can steer — you have rudder control over the boat. And when you're rudderless — either there's no rudder or you have no motion — you can't steer.
CT: Could share an anecdote from your experience working with higher ed institutions that has informed your thinking about change management?
Gottlieb: One CIO who I catch up with from time to time spent five years building relationships to establish trust with leadership — to really start to be trusted to make choices and make changes. Part of that was getting the basic stuff right: E-mail works, the networks work, and we don't have a security crisis on our hands right now. They don't have to start the meeting with, "Can you get my e-mail to work, please?" Instead, they're up to the business value conversation. That trust allows you to start delivering things that are more strategic, that start to produce the sort of leverage that a CIO needs to start delivering with higher velocity. That CIO is now enjoying a wonderful rhythm, being at the table and helping his institution to see change as an enabler — not a fearful experience, but an exhilarating experience.
Moreau: I'll share one example of where I did change management very poorly. Almost 25 years ago, the institution where I worked was implementing a new ERP. Their previous ERP was heavily customized; they'd had it for 20-some years, and so moving from that calcified system to adopting a new system, with as little customization as possible, was very painful.
We were in the process of eliminating student registration by telephone — you know, 25 years ago, telephone registration was the thing — and moving straight to the web. And one of the colleagues I worked with in Student Services had enormous fear that students wouldn't figure this out — that we'd lose enrollment, there'd be gigantic lines outside the registrar's office, and all kinds of catastrophes were going to happen. That fear was based on no data: We never asked students what they wanted. We never observed their behavior in our current web-based resources, in order to speculate on how they might receive it. I stood fast and said, "Well, look, we're not doing phone registration — that's so last century. We're going to do web, because if we don't, we're going to have to turn around and do it in two years anyway."
We spent all kinds of time and effort preparing for this web registration to be unsuccessful, and for all the fallout that would happen from that. And of course, when we implemented it, none of that came true. The sky didn't fall, the earth didn't stop turning, enrollment didn't go down. Students figured out how to use it. They liked it. They preferred it. It was an overwhelming success. Ultimately, my colleague in Student Services, and myself as the CIO, neither of us was doing change management at all. We were just acting from emotion, and we wasted a lot of time and effort and money by not using a change management methodology that could have helped us through that conversation more effectively. And our relationship was really forever damaged by the anxiety and the disagreement, essentially over nothing because neither of us had data to back up our position.
CT: Is there a right or wrong way to be transparent and talk about change?
Gottlieb: Don't oversell change by understating its complexity. That's really, really important. Transparency begets trust. Be clear about challenges and build that team trust and resilience through experience. This is where short iterations help, because it allows you to take smaller risks, and even fail, and then learn from that small failure — versus the big failure that happens when you try to take the big swing for the fence but you don't have enough steering input along the way to know whether it's going to be good or bad.
CT: Any advice for institutions that are struggling with, to quote Educause, "the culture, workforce and technology shifts that are central to digital transformation"?
Moreau: Six or seven years ago, I was part of the workgroup at Educause that actually came up with that definition of digital transformation. So I wholeheartedly believe it. And assuming that you believe those are the components of digital transformation — and I think most people who are talking about it seriously probably believe that in some form or another — I would say to my friends and colleagues that technology is the easy part. Culture and workforce are the hard parts. And of those two, culture is the hardest part.
Gottlieb: Culture is the starting point. Understand your culture first — not just as an institution, but also as an organization. There are certain aspects of our culture that we inherit from our commitment to delivering teaching and learning. And that's amazing. But we also should be honest about who we are as an organization. What is our culture and how much capacity for change do we have? How might that change over time? Understanding your culture also means knowing how the culture might be viewed differently by different departments and different people. And that's where the data really helps. It helps us turn culture into an asset, versus this mysterious, unspoken force that we know is having a huge impact but we aren't in touch with because we don't have data.
Think about this in the context of the people you have. When you're planning, forecast capabilities needed relative to what you have, and deploy in parallel with other known efforts and the known staffing that you have. It could be process, system, and data change all at once — you should coordinate that. Do it in small pieces, so you can help drive greater success in the adoption. Pay attention to the adoption success and iterate from there. If you're thinking about this as a people exercise, you'll be in a much better position to know who you need to hire when headcount opportunities arise, or when people retire and you have an opportunity to bring someone in new. Taking this people-centered approach gives you a much stronger feel for what you have in terms of capabilities — not roles in the organization, but capabilities — and therefore what you lack and what seems to be emerging on the frontier.
