Put a twenty-year engineer and a fresh from college junior in the same office tech rollout meeting and two completely different objections usually show up. The veteran says there was nothing wrong with the old system. The junior says the antiquated setup isn’t how they work.

Both sound like resistance to change on the surface. Treat them as the same complaint, though, and the standard playbook (more patience, more generic training) ends up failing both people because they’re not actually describing the same problem. One is about workflow fluency or the muscle memory and judgment built from years in a specific tool ecosystem. The other is about device fluency or the interaction model someone has spent years internalizing–phone-first, touch-native, app-centric–that doesn’t map to a keyboard, file system, and windowed desktop.

Technology leadership is at an interesting crossroads, but it’s not a generational one. One group is losing cognitive infrastructure they spent years building and that loss shows up in workflow fluency. The other group is missing exposure they never got and that gap shows up in device fluency. Age correlates with which side someone lands on more often than not, but age isn’t what causes it. What causes it is what a person has actually done–the work that shaped their instincts–and that makes it a coaching problem.

What 7,500 Laptops Taught Me

I first watched this split up close in 2010. I was in public education at the time and responsible for training and adoption on one segment of a laptop rollout that touched 7,500 teachers over a single summer.

The hardest group to bring along wasn’t who I expected. It wasn’t the veterans. It was the new teachers who were two years out of college and fresh into education.

It took me a while to really understand what our problem was, and it came down to something simple: sitting down with a group of teachers and asking them.

Most local education degrees and teaching certification programs at the time barely touched technology. The curriculum leaned hard into the human side of the classroom–relationships, pedagogy, differentiated instruction–and assignments still got written out by hand more often than not. A twenty-three-year-old who lived on their phone and ordered everything from Amazon could still have never really used a laptop for work in their life. They had exposure to one kind of device and one kind of interaction model and none of it transferred to a keyboard, mouse, or understanding file systems and network shares. The mental bridge between “I know how to use my phone” and “I know how to use this laptop” just wasn’t there to cross.

The fix wasn’t clever and it wasn’t more generic training on the same software everyone else was already getting. It was time, repeated hands-on exposure to the actual device, and a bit of mandated use: log in every morning whether you feel ready or not, and just fiddle with it. A few months in, most of that same group couldn’t be pried away from their laptops.

The veteran teachers had a completely different problem, and it wasn’t muscle memory. It was trust and perceived value. Pen and paper had worked for twenty years. Online gradebooks felt like someone else’s problem, specifically the front office’s. They weren’t struggling to operate the tool. They weren’t convinced that the tool was worth the switching cost.

That side took less time to move but needed something different: not more practice, but a clear demonstration that the new system was worth the trouble it caused–that it actually improved their teaching and their students’ outcomes.

Same Two Mechanisms, Fifteen Years Later

The pattern from that summer is the same one showing up in rollout meetings today, but wearing different clothes.

The veteran’s objection still lives in workflow fluency and it’s still one of two things: relearning cost (muscle memory that took decades to build and doesn’t transfer) or an unresolved question about whether the new system is actually worth what it costs to adopt. Both are judgment calls, not stubbornness.

The other objection still lives in device fluency and it’s still about exposure, not ability. Someone who spent years navigating a phone and never had to manage a computer with files and folders is missing the same bridge that twenty-three-year-old teacher was missing in 2010. That’s a posture and interaction model, not an application preference, and no amount of software polish fixes a device-fluency complaint.

Same Meeting, Two Different Complaints

Collapse both into one “resistance to change” bucket and the generic advice–explain the why, add a feedback loop–misses both targets. It solves a workflow-transition problem that neither the veteran (who already understands the why and rejects it anyway) nor the junior (who has no workflow complaint in the first place) actually has.

Why the Veteran’s Skepticism Holds Up

Neither side of this is baseless, and generic change management gets it backwards by assuming one of them is. A lot of what looks like stubbornness on the workflow-fluency side, then and now, is closer to accurate risk assessment or an honest value question.

A 2025 survey of more than 500 U.S. IT professionals, run by legacy-modernization vendor Saritasa, found that 62% of organizations still rely on legacy software, and half of respondents named the same reason for the delay: their current system still works. That’s the veteran teachers’ gradebook objection at organizational scale. Nobody measured laziness. They measured a rational bet that a known, working system beats an unknown one, especially when nobody has demonstrated what the switch actually buys.

The same trust-and-value check shows up today around AI-generated code and this time it isn’t nostalgia at all. BairesDev’s Q2 2026 Dev Barometer, a survey of 1,569 developers across 77 countries, run by BairesDev, an IT staffing and software-development firm, found that only 16% of senior developers believe junior engineers fully understand the AI-generated code they submit. That may be the same review instinct a senior engineer applies to any code they didn’t write themselves, arriving now at a volume nobody’s built a process to check, more than it is gatekeeping–though the survey shows a pattern, not a verdict on any individual engineer’s motives, and it’s worth watching for the cases where it does tip into turf-guarding. Either way, it’s the same “prove this is worth what it costs” question the veteran teachers asked.

Both reactions come from the same place: pattern recognition earned over years of watching confident-looking systems fail in ways that weren’t obvious (until they did). Writing that off as fear of change throws away a real signal leaders should be monitoring.

A Different Fluency, Not a Missing One

The friction on the device-fluency side matches what I watched in 2010 and it’s not just a hunch that exposure, not age, is the real variable. A 2025 Raconteur feature on the gap between assumed digital fluency and actual workplace tech struggles found the same pattern reporters keep running into: employees struggling with ordinary office tech like printers and spreadsheets, despite being about as online as any generation gets. Dr. Elinor Carmi, who studies data politics at City, University of London, offers a simple reason why: when she asks her students what they mean by “being online,” the overwhelming answer is TikTok. If you’re experiencing only one thing, that thing becomes your mental model for what “online” is–and it doesn’t include folder trees, overlapping windows, and productivity suites.

A few signals consistently show up in people this affects, on any team, at any age:

• They reach for search before they’ll click through a folder tree, even when they know roughly where a file lives.
• Everything lands in one flat location–Desktop or Downloads–instead of a structure they built on purpose.
• They’re faster and more precise with touch and swipe gestures than with keyboard shortcuts for the same action.
• Overlapping windows slow them down. One full-screen task at a time is how they actually work best.

None of that is a deficiency and it isn’t limited to junior hires. I’ve watched a twenty-year veteran show three of those same signals after a decade running his entire workflow from a phone, and I’ve watched two-year hires who grew up on a family desktop skip the pattern completely. The signals track exposure, not tenure, exactly the way the fresh-out-of-college teachers in 2010 tracked their coursework instead of their age. What the list is actually for is coaching, not diagnosis: spot two or three of those signals in someone and the conversation changes from “get comfortable with the new laptop” to “let’s build a folder structure together and talk through why it’s organized this way”–a teachable skill, not a character flaw.

The fluency underneath those signals is real, and it took as long to build as the veteran’s workflow fluency did. Reading it as immaturity says more about what’s unfamiliar to whoever’s doing the judging than it does about the person being judged.

Holding Two Models in the Same Room

The leadership problem isn’t picking a side. It’s recognizing that “this feels hard” means something completely different depending on who’s saying it, and responding to both without treating either one as the version that needs fixing.

For the workflow-fluency group, feeling behind means being asked to abandon expertise that took years to build, or to accept a switching cost nobody’s justified yet. For the device-fluency group, feeling behind means being handed a tool whose entire interaction premise doesn’t match how they’ve ever worked (or their meaning of working), then getting quietly judged for the adjustment period that follows. Most change management assumes one shared direction–everyone catching up to the same new normal at slightly different speeds. This situation has two separate directions of catching up happening in the same room, and building comfort for one group without accidentally shaming the other’s discomfort is the actual job.

The “fix” in 2010 came together organically, and every time I’ve been challenged with this since, the fix has come together the same way, because it’s hard to know everything about a team’s perception until you’re in the thick of it. You can ask ahead of time, but I’d bet the answers won’t match reality once you’re actually running the change.

What’s worked better is naming the actual mechanisms out loud in the room, early, instead of treating this as one change curve–assume you’ll have both and let people self-identify. The veteran hears that the same instinct behind their skepticism shows up in real data. The person missing device fluency hears that struggling with a laptop-first workflow is a paradigm transition, not a competence problem.

Reverse mentoring is the practice that actually fits that shape. It isn’t new–formal versions pairing junior employees directly with senior leaders have existed inside larger companies for well over a decade. What makes it worth trying here is that it isn’t a one-way skills handoff. It’s a structured, recurring pairing where the partner with search-first, touch-native fluency teaches interface and tool patterns and why they hold up, and the partner with years of institutional exposure teaches judgment: why a given shortcut exists and what it protects against. Neither side has a monopoly on judgment; the split here is about which specific kind of hard-won pattern recognition each person is positioned to hand off this year, not a verdict on who thinks more clearly.

Pick one person who shows the muscle-memory or trust-and-value pattern and one who shows the search-first, touch-native pattern, and set up a recurring 30-minute exchange where each teaches the other exactly one thing they’re actually good at. Skip the framework. Start with that.