Some engagements teach a technical skill. This one taught a posture — the discipline of sitting between two groups of capable people who could not, on their own, understand each other.
The context.
A large pharmacy client headquartered in St. Louis was standing up a new Electronic Health Record system to support their operations. The platform decisions had been made. The implementation partner was in place. What the client needed — and what the consulting engagement existed to provide — was a layer in between: someone who could translate the operational complexity of their business into requirements precise enough for engineers to build against, and translate the resulting system design back into something the operations teams could trust.
The engagement ran in parallel with a separate workstream: a set of workflow automation projects targeting Revenue Management Operations — the long tail of follow-up, denial handling, and queue management that sits between a clean claim and a paid one.
What the work actually was.
From the outside, EHR consulting can look like requirements-gathering and slide decks. Inside the engagement, the work resolved into three distinct kinds of effort, each demanding a different posture:
Not how the org chart said it worked. Not how the SOPs claimed it worked. How it actually worked — including the workarounds, the queue-jumping, the tribal knowledge that lived in the heads of senior operators who had been there for fifteen years. The output was a set of process maps and requirements documents detailed enough to design a system against, but honest enough that the operators recognized themselves in them.
Working alongside the engineering team to translate the documented reality into a system design — data model, screen flows, business logic, integration touchpoints, edge cases. The interesting part was not the design itself; it was the discipline of holding two truths at once: that the system had to fit the business, and that the business had to evolve to fit the system. The line between those two requirements is where consultants earn their keep.
In parallel with the EHR work, a separate set of projects targeted Revenue Management Operations — the follow-up queues, the denial workflows, the manual reconciliations that consume the operational hours nobody talks about in board meetings. The automations were not glamorous; they were the kind that quietly remove forty hours of weekly drudgery from a team that had no idea it was carrying that much.
The through-line.
The engagement was, in retrospect, the moment a specific skill set crystallized: the ability to move fluently between business stakeholders and engineering teams without losing what mattered to either. It is the same skill that would later make the Business Analyst and Scrum Master roles natural fits, and the same skill that would, years later, make architecting a school-based EHR from a blueprint feel less like a leap than a continuation.
Operationally, the engagement also reinforced a quieter truth: that automation done well is invisible. Nobody throws a parade for the workflow that no longer needs a person to babysit it. But the team running that workflow knows. And the throughput of the operation, six months later, shows it.
What it taught me.
The engagement closed. The system went live. The Revenue Management Operations team got their forty hours a week back. And somewhere along the way, a particular kind of consultant emerged — one who could sit in either chair, and increasingly preferred sitting in the chair between them.