← Back

From Diagnosis to Structural Change — Debugging My Team with the Waterline Model (Part 2)

March 19, 2026 · 4 min read

In Part 1, I used the Waterline Model to diagnose why my team felt stuck. Nearly every problem traced back to Structure — roles had shifted without being redefined, eval infrastructure existed on paper but not in reality, and phantom ownership had left critical work unattended.

I ended with a fix plan. This is what actually happened.

What’s Mine to Fix?

Before I could act, I needed to answer a question: which of these problems are actually mine to solve?

Evaluation pipeline is technical execution. Reassigning people to workstreams is engineering management. Making sure the new manager is ramping well is his manager’s responsibility.

As a PM, I can diagnose these problems. I can propose solutions. I can push for change. But I can’t make the structural changes myself — those need to come from someone with the authority to act on them.

Once I saw that clearly, the path forward got simpler: figure out what I should own, figure out what belongs elsewhere, and bring the full picture to the right person.

Figuring Out the Boundaries

I spent some time thinking about how responsibilities should divide between PM and EM on an ML/AI project. I landed on a simple model:

  • Problem Domain (PM owns): What user problem are we solving? What are the priorities? What does success look like?
  • Solution Domain (EM owns): What’s the technical approach? How do we build and evaluate it?
  • Execution Domain (PM + EM co-own): Who does what, by when? Is it on track?

The useful part of this model was the handshake points — where responsibilities overlap and things are most likely to fall through:

Metrics → Evaluation loop. I define what to measure. The EM builds how to measure it. We both own whether the loop is actually running. In our case, I had defined the metrics and run alignment sessions — then mentally checked the box. The pipeline was never built. Looking back, I had been guilty of the same phantom ownership I diagnosed in Part 1: I had completed my part of the chain without checking whether the next link was connected.

Technical direction changes. A major initiative had launched without a clear checkpoint: how will we know if this is an improvement? What metric are we moving? That conversation hadn’t happened.

Ownership transitions. A new manager had joined and responsibilities quietly shifted. A key contributor was leaving without a handover plan. Both transitions happened without anyone making them explicit.

This framework helped me see what to bring to the conversation — not a list of complaints, but a clear picture of where the seams were coming apart.

The Conversation

I requested a 1:1 with our project’s DRI — the senior leader who had delegated day-to-day management but remained ultimately accountable.

I shared what I had found: the observations from my 1:1s, the patterns I had identified through the Waterline Model, and where I saw the structural gaps. I had done my research, and I wanted to walk through the issues together — not to assign blame, but to figure out what to do about them.

Two specific asks came out of the conversation:

  1. We need a single technical POC who owns end-to-end execution across client and backend. Someone with hands-on context who can drive delivery and hold the technical threads together.

  2. Evaluation needs to be a first-class priority. We had agreed on metrics but never built the infrastructure to measure them. That needed to change.

What Happened

Within a day, the DRI sent a public message to the team. He assigned the single tech POC for end-to-end execution, sorted out the responsibility map across the team, and committed to spending more time on the project himself.

The structural gap was closed. Roles went from ambiguous to explicit. The DRI re-engaged with the project after recognizing that the delegation needed more active follow-through.

What I Learned

One big takeaway from this experiment:

Diagnose the system, do your research, then share your observations and thoughts with the person who can actually make the change. That conversation is the change itself.

A few reflections:

  • “I defined the metrics” ≠ “the metrics are working.” Definition without infrastructure is just words. I learned that my job doesn’t end at writing the alignment doc. It ends when the system is actually producing numbers we can act on.

  • Clarity on boundaries helps everyone. When I articulated “this is what I think I should own, and this is what I think needs to come from you,” the conversation became collaborative instead of one-sided. It’s easier to help when someone is specific about what they need.

3 days ago, I read about a management framework and decided to run it as an experiment. I didn’t expect it to lead to a real structural change within days.

One experiment at a time.