Organization: Multi-Health Systems (MHS)
Role: Project Manager → Program Manager
Tenure: ~5 years
Scope: End-to-end product modernization across psychometric assessment and digital platform initiatives
Products I worked on during this period Conners 4 (ADHD assessment), Multi-rater Conners 4, EQ-i 2.0 (emotional intelligence assessment), ASRS (Autism Spectrum Rating Scale, adult version), WordPress/LMS platform.
There were six of us in the PMO. And at some point, we realized we were all writing down the same things.
Different projects, different products, different teams — but the same friction points showing up in the same phases, in the same order, every time. Technology teams receiving requirements documents representing months of upstream work, and immediately raising concerns that should have been surfaced six months earlier. Feedback cycles that weren’t planned for landing in the middle of an already-tight delivery schedule. Launch dates slipping not because anyone dropped the ball, but because the sequence wasn’t working in a way that could support the collaboration the work required.
Nobody was failing. The system was.
That observation — one that had been accumulating across six people doing the same job — was the beginning of a question I spent the next several years trying to answer: if everyone is working hard and things are still getting stuck, what exactly are we fixing?
An Organization Caught Between Two Ways of Working
MHS develops psychometric assessments and related digital products used by organizations and practitioners worldwide. The products themselves are scientifically rigorous — some taking up to five years to build before technology teams even touch them — and the stakes of getting them right are high. These are clinical, educational, talent, and public safety tools.
By the time I joined, the organization was navigating a real tension. Product and R&D teams had long-established ways of working — thorough, sequential, expert-driven. Technology teams were moving toward agile delivery. Both approaches made sense within their own context. The problem was the seam between them.
My role spanned both. As a project manager embedded across delivery teams and then as a program manager with broader visibility across multiple initiatives, I sat at the intersection of these two operating models. I could see the whole lifecycle in a way that most people, working within their own function, couldn’t.
Everyone Was Working Hard. Things Were Still Getting Stuck.
On the surface, the symptoms looked like execution problems. Timelines extending. Requirements changing late. Too many rounds of review before anything got signed off.
But the more time I spent in daily standups, retrospectives, and planning sessions — across teams, not just within one — the clearer it became that the root cause was somewhere upstream of execution.
Decisions were being made in sequence that needed to be made together.
Product and R&D teams would spend months building the science and structure of an assessment. When that work arrived at the technology team’s door, the questions weren’t simply about technical feasibility — they were about how the product would appear on the platform and whether a platform with its own ongoing specifications could support something new. Designers would create partial mockups of reports — not the full output, just enough to test how the assessment results would look when rendered — to make sure the product reflected the science behind it as intended for the user. These were the right conversations to be having. The problem was that they were happening far too late. Rework that hadn’t been scoped into any project plan would quietly be added to the schedule.
There was a trust dimension to this too. Because the product had been built with such care, there was a tendency for product leads and even senior leadership to remain involved well past the point where their involvement was needed. I saw this most visibly in testing — UAT sessions where the intent was for the product team to spot-check a handful of cases, but in practice multiple layers of leadership were running full test cycles alongside the QA team. The QA team had done their job. The culture of trusting that process hadn’t fully taken hold yet.
What made this hard to name was that it didn’t come from bad intentions. The product team wasn’t overreaching out of distrust — they were invested. They cared deeply about what they were building. That ownership was one of the organization’s strengths. The challenge was finding a way to honor that investment without letting it slow everything down.
Nobody gave me the mandate to fix any of this. My job was to manage projects. But because I could see the full picture — every phase, every handoff, every dependency — I decided to try.
Drawing the System Nobody Could See
The first thing I did was make the problem visible.
I built a journey map of the end-to-end product launch lifecycle — from the initial business case through R&D, product development, technology build, testing, marketing, training, and launch — using a shared whiteboard. Not a process document. A visual representation of how work actually moved, including where decisions happened, where handoffs occurred, and where things consistently got stuck.
The goal wasn’t to show who was responsible for what. It was to surface whether the bottlenecks were capability problems or decision-making problems. Because those require completely different responses.
I brought the heads of product, design, software development, testing, and customer experience together to walk through it. The reaction was immediate — they could see exactly where things were getting stuck. They recognized the patterns. One immediate benefit: business and customer priorities that had previously been hard to act on became easier to recognize and sequence. With the full lifecycle visible, the team could see the effort required at each stage and make more realistic commitments to clients.
What didn’t happen was decisions. Not in that first meeting.
People could agree on the diagnosis. The question of what to change — and who would own those changes — required a different kind of conversation. I had to push for a follow-up. And then push again. The distance between “yes, we see the problem” and “here’s what we’re committing to” was its own project.
The resistance came mostly from the product side — understandably. These teams had built their practices over the years. The waterfall approach wasn’t arbitrary; it reflected the reality that for a psychometric assessment, you can’t prototype the science. There are steps that must occur in sequence. The question wasn’t whether to change the fundamentals of how assessments were built — it was whether we could change how the rest of the organization engaged with that work while it was happening, rather than waiting for it to finish.
What eventually moved the conversation wasn’t me. It was revenue. Delayed launches meant we couldn’t meet customer demand. That made the business impact impossible to ignore — and the willingness to change followed.
The Workshop That Made Ownership Visible
The clearest turning point came out of a quarterly scope-building workshop I facilitated.
The format was simple: a whiteboard, two columns. The left — what we’re committing to this quarter. The right — what we delivered within that timeframe. Product and technology teams in the same room, building the plan together.
For what sounds like a straightforward exercise, it produced something that hadn’t existed before: a shared, visual record of what we said we’d do and what we did. We could calculate the rate at which commitments were being met — and we could trace why things slipped into the next quarter when they did.
This did two things at once. It made ownership explicit in a way that was collaborative rather than accusatory — the plan was built jointly, so the accountability was joint. And it gave us data to have better conversations. When a task moved quarters, we could ask: was it a dependency we didn’t see? A decision that came too late? Scope that expanded mid-phase? The answer wasn’t always comfortable, but it was always useful.
Over time, I came to think of this as the first component principle — not a formal methodology, just something I kept observing. If I invested heavily in getting the first component of a product right — not rushing it, building it thoroughly, testing it carefully — the rest became repeatable. The process became error-free. The team moved faster on everything that followed because we’d already solved the hardest problems once. What felt like slowing down at the start was how we sped up at the end.
Building the Habit of Looking Back
Retrospectives existed before I got there. What I tried to do was make them more purposeful — structured as concentric circles.
At the team level, sprint retrospectives were a regular heartbeat. At the phase level, when a major milestone was reached, I facilitated a session with managers to examine what had worked and what needed to change before the next phase began. At the project close — these were 12-to-18-month projects, so people genuinely needed help remembering where they’d started — I brought in senior leadership for a full retrospective that traced the arc from start to finish.
That last one mattered more than it might seem. Long projects have a way of making everyone feel like they’re always behind, always catching up. Taking time to name what had shifted — not just what still needed to be done — changed how people felt about the work and about each other.
My facilitation approach throughout was rooted in root cause analysis — not as a formal audit, but as a mindset. It’s easy for a team to say things aren’t going well. The harder and more important work is identifying why — tracing the symptom back to its structural source so you’re solving the right problem, not just managing its effects. I tried to create the conditions for that conversation to happen — not personal, but for the team. The goal was always to move from “what’s wrong” to “what’s actually driving this, and what do we do about it?”
Where the Change Showed Up
The changes weren’t tied to a single initiative — they accumulated across multiple products and projects over several years.
Launch timelines reduced from more than 24 months to less than 18 months on average. The commitment-to-delivery metric I’d introduced through the scope workshops gave teams a concrete way to track and discuss slippage without it becoming a blame conversation. Cross-functional ownership became clearer — with more explicit phase-gate expectations and earlier engagement from technology teams during product development.
The MVP framework that emerged from the MoSCoW prioritization work meant we stopped trying to launch everything at once. Features that were genuinely valuable but not required for the day-one customer experience were moved to a post-launch roadmap. That shift alone reduced the pressure that had been causing scope to expand unchecked.
The culture change — and the line between process change and culture change is genuinely blurry — showed up most clearly in two places. First, who was speaking in retrospectives. Team members who had previously taken direction were coming back with their own ideas about what needed to change. The room felt different. Second, in how decisions were made. Technology teams were being consulted during product development, not after. That wasn’t a structural mandate — it was a habit that took root because people had seen what happened when it didn’t.
What I Carry Forward
There’s something I keep coming back to from this experience — the difference between being handed a problem and choosing to see one.
Nobody gave me a culture change mandate. I was a project manager. My job was to deliver projects on time. But what made this work possible was something I’d describe as ecosystem-level thinking — the ability to hold the entire system in view, not just the part immediately in front of me. The PM role, precisely because it sits at every phase, every handoff, every dependency, creates that vantage point. The question is whether I use it.
This kind of work is difficult to point to. There’s no artifact to screenshot, no screen to show in a portfolio. It shows up in how teams talk to each other, how decisions are made earlier, and whether people feel trusted to do their jobs. It’s the category of change that’s hard to measure in metrics alone — and yet it’s often what determines whether everything else works. In many ways, the success metric isn’t what you can see — it’s the friction that’s gone.
What I’ve carried forward is the conviction that process changes are often culture changes in disguise. When I changed when a team got involved in a decision, I wasn’t just changing a sequence of tasks — I was changing how much that team was trusted. When I built a retrospective structure where people felt heard rather than evaluated, I wasn’t just running a meeting — I was building a norm.
Looking back, I’m not sure I changed the culture at MHS. What I did was make it visible — the friction, the gaps, the decision points where things were getting stuck. And once people could see it, they could act on it.
That’s the space where facilitation, consulting, and systems thinking meet. And it’s where I do some of my most meaningful work.
5+ products | ~9 functional groups | Launch cycle reduced from 24 to less than 18 months
