The people who make a program work are the ones who learn the work itself, and can carry it between the experts who build a system and the people who use it every day.
It is the end of a long day on an implementation. A ticket comes in from the ICU. One of the barcode scanners nurses use at the bedside is not reading reliably. To the engineer who picks it up, it is a scanner, and it can wait until morning.
To the nurse, it is the difference between a medication pass that runs on time and one that does not. Every dose is scanned against the patient’s wristband before it is given. When the scanner fails, the nurse works around it, with more steps and more room for error, on a unit where minutes matter. Multiply that across a shift and a floor, and a small device ticket becomes a patient care problem.
Neither person is wrong about what they see. They are looking at the same device from two different worlds. On most large programs, the outcome depends on whether someone in the room can see it from both.
The work behind the system
Every system implementation is, underneath, a change to how people do their jobs. The software is configured around workflows, and the workflows belong to nurses, appraisers, clerks, billing teams and the people who supervise them.
Yet much of what gets planned, staffed and measured is the system itself: the build, the interfaces, the conversion, the go-live date. The work the system exists to support is easy to treat as background.
That is where programs drift. Requirements get written in the language of the team building the system, and the people who will use it read them and agree, because they cannot see their own day in them. Decisions that make sense on a diagram add steps at the worst possible moment for someone on the floor. Nobody intends it. The translation simply never happened.
Knowing a subject and knowing the work are two different kinds of knowledge. Programs need both.
Green lumber
In Antifragile, Nassim Taleb tells the story of a trader who built a successful career in a commodity called green lumber. For years he believed green lumber was lumber painted green. It is actually freshly cut wood that has not yet been dried. What he understood deeply was what moved the market, and that was the knowledge his work depended on.
Programs have their own version of this. Knowledge of a subject is valuable. Knowledge of the work, how it is actually done, by whom, and under what pressure, is a different kind of knowledge. It is often the one that decides whether a new system is adopted or worked around.
People who walk between two worlds
The strongest teams pair deep expertise with people who can move between the experts and the people doing the work. They can sit with an engineer and talk through an interface, then walk onto a unit and understand why a nurse cares about a few seconds at the bedside. They notice the dynamics in a room. They carry what one side knows to the other, in words each side recognizes.
That understanding is usually built over time, through years beside end users and through being in the room when something went wrong and staying to fix it. It does not compete with expertise. It makes expertise land where it should.
I see this in my own work. The projects I am brought in to lead are the ones where failure is not an option: the largest jurisdictions, the most complex conversions, the clients everyone is watching. That trust is earned one program at a time. I have done this work from inside the vendor and beside the client, and I know where these programs tend to break and what it takes to keep them moving. That is what a track record gives you. It is the experience of being trusted with the hardest rooms, and the habit of leaving them better than you found them.
Much of what I bring into those rooms is about the work more than the software: how an appraisal office moves through a valuation cycle, what a tax office cannot afford to get wrong in billing season, and where a conversion will touch both. Knowing that is what lets the vendor’s team and the client’s team understand each other.
How to find it, and how to build it
Ask about the work, not only the system. Ask a candidate to walk you through a day in the life of the end users they supported. People who have learned the work describe it in detail, and they describe it from the user’s side.
Ask for a time they translated. A moment they explained a technical constraint to the floor, or carried a concern from the floor to a technical team, and what changed because of it.
Look at where they have stood. Time spent working beside end users is a skill in its own right. It shows up in how people talk about the work and the people who do it.
Build the habit into the program. Have new team members observe the actual workflow before they design for it. Bring end users into reviews and speak to them in their own terms. Make translation someone’s job, not an accident.
When it goes right
When this works, nobody notices. The nurse scans, the dose is given, the medication pass stays on time, and the scanner never crosses her mind. The appraisal office closes its cycle on schedule and the bills go out right the first time.
That quiet is the result of someone who took the time to learn the work and carried it faithfully between two worlds. It is who we look for, and who we try to be.
Toshika Howard-Patterson is Managing Principal at Strategic Innovations Consulting, a boutique advisory and delivery firm serving healthcare and state and local government. She works with client leaders and SIC engagement teams to strengthen program governance, delivery performance, and organizational capacity.