If you’ve been through a major tech implementation in higher education, you likely remember the feeling of it, even if you don’t remember the details. The weeks leading up to go-live are full of cautious optimism because all the planning meetings make you feel like you’ve thought of everything. You’ve mapped the workflows, sat through the demos, convinced yourselves that this system will finally fix the reporting problem, or the communication lag, or that one mysterious leak in the funnel that no one can quite explain.

Why the Work Doesn't End Once You Go Live

Go-live week arrives. You log in expecting clarity, and instead you get something you didn’t expect. A field you were certain existed… doesn’t. A report that should reconcile cleanly gives you numbers that are close, but not quite right. Someone down the hall can’t access the system at all. And the historical data you migrated over looks familiar enough to be yours, but unfamiliar enough to make you pause. Nothing catastrophic, there’s nothing on fire, but there’s enough instability to make everyone slightly uneasy. That’s when teams tip in one direction or another. People either retreat into silos or lean toward each other, learning and growing together.

What I remember most about one particular rollout isn’t the technical hiccups. It’s the emotional temperature. There wasn’t panic or the dramatic “We need to pause everything” speech. Instead, every afternoon at four o’clock, a cross-functional group of us met – admissions, marketing, recruitment, IT, whoever was closest to the issue of the day. We’d conduct what we called a daily temperature check. What’s working? What’s not? What can wait? Where are we overreacting?

We fixed some issues immediately and parked others for the next sprint. We decided that some things were good enough for now because perfection wasn’t the goal, progress was. And over the course of a few weeks, something shifted that had nothing to do with the launch. The IT team began to see the enrollment cycle the way we saw it. They understood why a small data element could matter so much at a particular point in the funnel. And those of us not on the IT side of things began to appreciate the architecture under the hood and why a simple request could ripple through three other systems. We stopped talking about “the system” like it was an adversary and started talking about how we were going to make it work.

Technology Projects Are Revelatory

Enrollment leaders are frequently told that they need to be more agile in order to make effective use of tech tools, as if agility is something you can just install. But after enough implementations, integrations, and digital “transformations,” lessons I've learned is that agility is a structural issue. It’s about whether a team has built the habits that allow it to respond to a learning experience without unraveling: clear onboarding processes, shared language about roles and responsibilities, and rules that allow teams to surface friction without defensiveness.

When those elements are in place, a messy rollout becomes a strengthening exercise. But if they’re absent, even a smooth launch can carry inter-group tension and misplaced resentment. Which is why being “tech ready” has very little to do with mastering new tools and everything to do with whether a team understands how it works together when things get a little messy.

Onboarding Is Where Culture Shows Itself

Orientation is what most of us are familiar with. It’s the initial walkthrough, the tour of the interface, the “here’s where you click” training session that gets someone functional enough to begin using the system. This kind of work is important and necessary, but it’s also incomplete if it stops there. As described in Liaison’s whitepaper, Building Tech-Ready Teams: A Guide to Effective Technology Onboarding in Graduate Admissions—onboarding is developmental. Good tech onboarding unfolds in layers—introductory, intermediate, advanced—with the expectation that understanding and fluency deepen over time.

The goal isn’t simply to make sure someone can operate the system, it’s to help them understand how that system fits into their role, how their role fits into the enrollment funnel, and how all of it connects back to institutional purpose.

That distinction may sound procedural on the surface, but it’s cultural at its core.

Tools in Service of a Mission

When onboarding is treated as an ongoing process rather than a one-time event, it sends the message to staff that technology is not static, that feedback is welcome, and that growth is expected. It reinforces the idea that tools exist in service of mission, not the other way around.

The whitepaper encourages leaders to align tech use with institutional goals, to map roles clearly to workflows, and to build structured opportunities for feedback and refinement. If you read that quickly, it might sound like project management jargon. But taken seriously, this is really org design. These kinds of efforts can shape how authority is distributed, how information travels, and how a team responds when pressure inevitably increases.

Over time, those decisions cultivate ownership and build trust. And it becomes clear that shaping the system is an ongoing process where everyone has an ownership stake. When that expectation is established early, and onboarding is handled with intention rather than haste, technology stops feeling like something imposed from the outside.

Why This Matters Now

When I think back on that implementation now, the technical details blur together. I couldn’t tell you which field was missing or which report didn’t show what we expected. Those frustrations have faded the way most technical inconveniences do. What stays with me is the rhythm of those 4:00 PM meetings and the way the room felt: focused, candid, occasionally tired but never frantic. There was a quiet understanding that the work would be imperfect for a while, and that was acceptable. We would keep showing up, keep sorting through what mattered most, and keep adjusting when we needed to.

Over time, that rhythm built trust and reinforced the expectation that friction was part of the process, not a sign of failure. It reminded us that progress is usually incremental, and that shared ownership of education technology makes even difficult stretches manageable.

That kind of response reflects a culture in which habits are formed over time, clarity about roles is shared, and ed tech systems are treated as shared tools by leadership rather than external mandates.

If you’re preparing for an implementation, recovering from one, or simply trying to understand why your technology feels heavier than it should, this guide offers a thoughtful starting point. It provides structure, language, and practical steps for building teams that can adapt without unraveling. Because in the end, ed tech systems will evolve and tools will change, but what carries you through is the team.

Download Building Tech-Ready Teams: A Guide to Effective Technology Onboarding in Graduate Admissions.