I've been working on a digitization project at a traditional care facility. The staff there — mostly between forty and sixty years old — spend their days taking care of people.
By the time we shipped version three of the system, it hit me:
My development speed and their absorption speed were at least ten times apart.
Two Kinds of Agile
In software, "agile" is a word that's been beaten to death. Fast iteration, continuous delivery, two-week sprints. With AI in the picture, it's gotten even more extreme — describe a requirement, get a working version in fifteen minutes. Code changes, deploys, rollbacks — all measured in minutes.
This is digital agile. Abstract, fast, low-risk. Something breaks? Roll back. Wrong direction? Pivot. The cost is time, and time is cheap in the digital world.
But when I walked into that facility, I ran into a completely different reality.
The staff's job is caring for people — real people, with emotions, with physical conditions. Their expertise is built on experience and relationships. A senior care worker knows how to coax an elderly resident who refuses to eat. That's a decade of accumulated skill no system can replace.
But ask those same people to use a new system to log their daily work?
Their biggest fear: "What if I press the wrong thing? Will it break something?"
This is field agile. Built on accumulated experience, leading with relationships, driven by trust. Change isn't measured in version numbers — it's measured in months.
Rockets and Roller Skates
I made a mistake early on.
When version one was ready, I shipped everything at once. Photo upload, voice recording, AI-generated reports, PDCA management cycles, data dashboards. From an engineering standpoint, every feature had value and the architecture was clean.
The result?
A staff member opened the app during the trial, took one look at the interface, and closed it.
The system wasn't bad. The problem was — I handed them a rocket when what they needed was a pair of roller skates.
There's a classic agile metaphor: build roller skates first, not a car. It's been around for over a decade, originally about shipping the minimum viable version first.
But in the AI era, I realized it applies differently — it's not about development pace anymore. It's about the pace of human trust in change.
Roller skates → scooter → bicycle → motorcycle → car
You can't hand them a car on day one. Not because the car is bad, but because they don't yet believe they can drive.
Give them the simplest possible thing first — just photo uploads to replace handwritten notes. Once they're comfortable with that, add the next feature. Each step needs to be small enough that they're not scared, but meaningful enough that they can feel the value.
Sounds slow?
It is slow. But it's the only pace that actually works.
Absorptive Capacity Is the Real Bottleneck
I looked into the research on this and found there's an academic term for it: absorptive capacity — an organization's ability to digest new technology and new knowledge.
One line stuck with me: The most innovative organizations aren't the fastest movers. They're the best digesters.
A lot of organizations fall into the same trap: constantly importing new tools, new systems, new processes, while the team never has time to actually absorb them. The result is "knowledge indigestion" — a pile of tools nobody uses.
This problem gets worse in the AI era. Development speed has genuinely increased tenfold, but adoption speed on the ground hasn't moved. That gap is only going to widen.
You can ship three versions of your system in a week. Your field staff might need a full month to absorb a single new feature.
That's not their problem. It means your pace isn't calibrated to their absorptive capacity.
Three Things I Learned
1. Keep dev speed and adoption speed on separate tracks
The system can iterate quickly — but adoption has to go slowly. My approach now: the dev side stays on two-week sprints, but on the adoption side I push exactly one new feature per month. Two tracks running in parallel, neither one held hostage to the other.
Features that are built go into a queue and wait. The next one only gets pushed after the previous one has been absorbed. It takes patience, but the outcomes are much better.
2. The people in the field are the real product managers
The feature priorities I come up with sitting in an office are almost never the same as what the field staff actually needs.
My habit now: spend half a day at the site every month, watching how they use the system. Not asking "is it easy to use?" — because they'll politely say "it's fine." I watch — where they get stuck, what workarounds they've invented to route around the system's design.
Those workarounds contain the most honest requirements you'll ever find.
3. Trust matters more than features
In a traditional institution, the biggest barrier to adopting a new system isn't technical — it's trust.
Staff need to believe: this system won't add to my workload. This system won't make me look incompetent. If something breaks, someone will help me fix it.
The way to build that trust is unglamorous: let them see a colleague use it and genuinely like it. So I always start with the two or three people who are most willing to try something new. I help them become seed users. When they tell a coworker in the break room "actually, that thing's pretty decent" — that's worth more than any training session I could run.
What Agile Actually Means
Back to the word "agile."
The software industry's definition: fast iteration, continuous delivery, embracing change. In a purely digital world, that's completely right.
But when digital tools enter traditional environments — care facilities, hospitals, schools, factories — the definition needs to expand.
Real agility isn't just about how fast you build. It's about how steadily you land.
Not just how quickly you can ship a new feature, but how quickly users can make that feature part of their daily routine.
Not just how fast your system can iterate, but how fast the organization can absorb change.
AI has made the development side ten times faster. But if the adoption side can't keep up, that tenfold speed just produces tenfold waste.
If You're Doing Something Similar
If you're bringing digital tools into a traditional environment — whatever the industry — three questions are worth sitting with before you start:
-
How fast can your users actually absorb change? Not how fast you think they should, but how fast they actually can.
-
Is your adoption pace calibrated to their absorptive capacity? If you're pushing three new features a month but they can only absorb one, the other two are just waste.
-
Have you actually spent time in the field? Not in meetings, not reading reports — actually watching how they work and how they use your system.
One last line to take with you:
Give them the bicycle. Not the rocket. Once they're riding steadily, then hand them the motorcycle.
I'm Young. I specialize in digital transformation for traditional organizations. From field observation to system architecture to AI adoption — I start where the problem actually lives. If you're doing something similar, I'd love to compare notes.