Higher education technology leaders ask each other a lot of reasonable questions. What CRM are you using? What ERP? What service desk? What AI platform? What are you doing for identity management?
Those questions are useful, but they are usually not the most important ones. The better question is: What problem were you trying to solve?
I have watched institutions make poor technology decisions because they started with the product instead of the problem. Someone hears that another college is using a particular platform, sees a polished demo, hears that a peer institution loves it, and assumes the same answer should work for them.
Sometimes it does. Sometimes it absolutely does not.
Over time, I have also learned something more personal: my job is not to be the smartest person in the room. My job is to be the best listener.
Context matters more than the logo
A technology decision that makes perfect sense at one institution may be a terrible fit for another because staffing, integration capability, institutional size, budget, architecture, leadership support, change capacity, and timing all matter.
I learned this again when we were evaluating a portal. I went into the process assuming one particular direction would be difficult to implement. A combination of my own staff, staff from another KANE institution, and account executives who did not even work for the company involved challenged my assumptions.
I listened.
We went another direction, and that decision ultimately saved my institution roughly $250,000.
What mattered was not that someone had a better title or a louder opinion. What mattered was that several people with different perspectives saw something I did not.
That experience reinforced something I have come to believe strongly: a CIO's job is not to have all the answers. It is to build a process where the best information has a chance to win.
I stopped making technology decisions by myself a long time ago
As a CIO, I am increasingly convinced that if I make an important technology decision by myself, there is a good chance I will get something wrong.
My job is not to pick the platform I personally like best. My job is to get the organization to the most broadly supported answer we can reach with good information.
That does not mean everyone has to agree.
In fact, when one person on the jury disagrees, I pay particular attention. I want to understand why. I want to know what they see that everyone else may be missing. Then, if I ultimately disagree with them, I want to understand why I am willing to do that.
That is very different from consensus for the sake of consensus. It is disciplined listening.
I stopped making my own technology decisions a long time ago.
Ask what went wrong
When I talk with another institution about technology now, the product name is usually just the beginning. I want to know what problem they were actually trying to solve, what they replaced, what implementation required from their own staff, what integrations were harder than expected, what the vendor did well, what the vendor did poorly, what users resisted, and what costs appeared after the contract was signed.
Then I ask one of my favorite questions:
What went wrong?
Success stories are useful, but failure is usually more instructive.
I have only been involved in one technology project I would describe as going almost perfectly. It went that way because I listened to my director.
That lesson has stayed with me.
“Best practice” can be dangerous shorthand
I am skeptical when I hear the phrase “best practice” used too casually because best for whom is often the more important question.
A practice can be excellent in one environment and completely wrong in another. The same is true for technology. An institution with a large development team may get tremendous value from a highly configurable platform, while another institution may need something simpler because it does not have the staff to maintain that complexity.
The better goal is not to copy best practice. It is to understand why something worked and whether the conditions that made it successful exist at your institution.
Best practice without context can become borrowed confidence.
The license price is not the cost of the system
One of the most common things I think institutions underestimate is that buying software also means buying a future workload.
The real cost includes implementation time, integrations, data conversion, training, process redesign, staff attention, change management, ongoing administration, security work, consulting, renewals, and the opportunity cost of everything your team cannot do while supporting the new platform.
And there is another cost that is easy to overlook: whether the people approving the system actually tested it well enough before committing to it.
Peer institutions can help expose those blind spots. They know where the gotchas are because they have already stepped on them.
I have seen platforms such as Salesforce and ServiceNow be both incredibly expensive and incredibly affordable depending on the problem being solved, the way they are implemented, and the capacity of the institution supporting them.
The platform name does not tell you whether the decision was good.
Sometimes the most important person to listen to is the system administrator at another institution who has actually lived with it.
Trusted peers are invaluable
I have learned a great deal from people like Wayne Sager and David Cone at Northeast Community College. They have helped me challenge assumptions, understand risks, and think differently about technology decisions without needing to tell me what to buy.
Bill Young has done the same for me at important moments. Sometimes the most valuable contribution a trusted colleague makes is simply helping you slow down long enough to ask whether you are solving the right problem.
I do not need everyone in my network to agree with me.
I need them to tell me the truth.
Vendor references are useful. Trusted relationships are better.
Vendor references have value, but we should also acknowledge what they are. They are usually customers selected because they have had a positive experience.
There is nothing wrong with that, but it is not the same as calling someone you trust and asking, “What really happened?”
That is one of the reasons a peer network matters so much.
The same is true on the vendor side. There are account executives, consultants, and company leaders I trust deeply because the relationship works both ways. They know I will tell them the truth, and I know they will do the same for me.
The best of them understand that sometimes helping me make the right decision means telling me not to buy something.
Those relationships are invaluable.
Different answers can all be right
One of the hardest habits to break in higher education technology is assuming that if several institutions look at the same product, they should reach the same conclusion.
They should not.
I have watched institutions evaluate the same technologies and make different choices for perfectly legitimate reasons. Staffing was different. Architecture was different. Financial models were different. Institutional priorities were different.
Good collaboration does not produce identical decisions. It produces better-informed ones.
If five KANE institutions study the same problem and reach five different conclusions for five good reasons, the network still worked.
Ask the question nobody is asking
Dr. Michael Chipps, a former president I worked for, had a habit that has influenced the way I think about decisions.
He would remind us that we rarely ask the right question.
Then he would ask something like, “What question are we not asking?”
Or, just as importantly, “Why shouldn't we do this?”
Those are powerful questions because they force you out of the momentum of a decision. They make you examine assumptions instead of simply defending them.
That is what I want KANE to do for its members.
Not tell institutions what to buy.
Not make decisions for them.
Not create another list of supposed best practices.
I want the network to help us ask better questions, find the people who have already learned the hard lessons, and listen carefully enough to make better decisions.
KANE should not help colleges copy one another.
It should help them learn from one another.
