Leading Both Ends of the Adoption Curve
Two people can find the same rollout hard for completely different reasons.
Put a twenty-year engineer and a fresh-out-of-college junior in the same tech rollout meeting, and two completely different objections surface. The veteran says the old system worked fine. The junior says the outdated 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 of more patience or more generic training fails both, because they’re not describing the same problem. One is about workflow fluency: the muscle memory and judgment built from years in a specific tool ecosystem. The other is about device fluency: the interaction model someone spent years internalizing (phone-first, touch-native, app-centric) that doesn’t map to a keyboard, file system, and windowed desktop.
Technology leadership sits at an interesting crossroads, but it’s not a generational one. One group is losing cognitive infrastructure they spent years building; that loss shows up as workflow fluency. The other group is missing exposure they never got; that gap shows up as device fluency. Age correlates with which side someone lands on, but age isn’t the cause. 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, in public education, 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 two years out of college.
It took sitting down with a group of teachers and asking them to really understand the problem.
Most local education degrees and teaching certification programs at the time barely touched technology. 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. They had exposure to one device type and one interaction model, and none of it transferred to a keyboard, mouse, file systems, or network shares. The mental bridge between “I know my phone” and “I know 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 got. 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 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 and 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, just 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
| The Veteran (Workflow Fluency) | The Exposure Gap (Device Fluency) | |
|---|---|---|
| Sounds like | “Nothing was wrong with the old system.” | “I don’t want a laptop.” |
| Real mechanism | Earned expertise discounted to zero — whether that’s muscle memory or unproven switching value | Fluency built on one device paradigm, missing the bridge to another |
| What they need | Proof the switch pays for itself | Time and structured exposure to the new device model |
| What fails them | More training on features they already understand | “Just give it time” without a bridge |
Collapse both into one “resistance to change” bucket and the generic advice of “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 is baseless, and generic change management gets it backwards by assuming one 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. BairesDev’s Q2 2026 Dev Barometer, a survey of 1,569 developers across 77 countries, 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 gatekeeping — though the survey shows a pattern, not a verdict on any individual’s motives, and it’s worth watching.
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 as online as any generation gets. Dr. Elinor Carmi, who studies data politics at City, University of London, offers a simple reason: 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 everything.
A few signals consistently show up in people this affects, on any team, at any age:
- They reach for search before clicking 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.
As I dug into these signals and research, I also thought through my own usage.
Being deep into tech for 30+ years, I’m more comfortable with a mouse and keyboard than a touchpad or controller, tend to over-organize my files, and get annoyed when file search takes too long because I know where that file is located. I also tend to work with multiple windows open across multiple monitors.
I compare that to peers and friends who are the opposite in every way — and while some are younger, many are my age but their device exposure journey was entirely different.
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. The list is for coaching, not diagnosis: spot two or three 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” and focus on 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 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 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 with 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 faced this since, it’s 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 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 deeply.
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.
