LOCAL PREVIEW View on GitHub

Story 06 — How I scaled my judgment without being in every meeting

One-line: Decision quality on the team had become a function of who was loudest in the room. I built a five-persona discussion framework — Priya/Marcus/Aiko/Jordan/Sam — that forced every major ML decision to be argued from all five seats. Escalations dropped, junior engineers grew into senior judgment, and I stopped being a bottleneck.

Situation

Roughly the four-month mark, post-launch. The team had grown from 4 ICs to 12. I'd shipped past the 92% POC trap, the hybrid-execution decision, the hallucination calibration, the EWC fix — and now I was the bottleneck. Every non-trivial decision was getting routed back to me. "Should we use LoRA rank 8 or 16?" "Should we add another reranker layer?" "Should we ship this prompt change without an A/B?" "PM wants Feature X — is it worth the cost?"

I could feel two failure modes coming. Mode 1: I'd burn out trying to be in every decision. Mode 2: the team would learn to stop bringing me decisions and just ship — which sounds like the right outcome but actually means the team would re-litigate every architectural call I'd ever made, badly, in private.

I needed to scale my judgment, not my bandwidth.

Task

Build a system that produced senior-quality decisions even when I wasn't in the room.

Action

1. Diagnosed why decisions were going wrong. I sat in on three week's worth of architecture meetings as a silent observer. Pattern was obvious: decisions were dominated by whichever person had the loudest opinion. The ML engineer would push for a model-side fix; the architect would push for an infra-side fix; the data scientist would push for a data-side fix. Everyone was right from their seat, but nobody was reasoning across seats. The arguments weren't bad; they were partial.

2. Built the five-persona framework. Five named personas, each representing a real role and a real perspective:

  • Priya — ML Engineer. Cares about model behavior, training stability, fine-tune costs, evaluation metrics, what the loss curve says.
  • Marcus — Solutions Architect. Cares about service contracts, latency budgets, scaling characteristics, deployment patterns, operational blast radius.
  • Aiko — Data Scientist. Cares about distribution shift, sampling bias, statistical rigor, causal inference, what the data actually says (vs. what the metric says).
  • Jordan — MLOps. Cares about pipelines, reproducibility, drift monitoring, on-call burden, how this thing fails at 3am.
  • Sam — Product Manager. Cares about customer outcomes, business metrics, time-to-ship, scope, what we're not doing.

For every major decision, the team had to write the argument from all five seats before the meeting. Not after. Not as an exercise. Before.

3. Embedded the framework into the project artifacts. All 18 fine-tuning deep dives in Fine-Tuning-Foundational-Models/ carry these personas as group-discussion participants. New ML engineers learn the framework just by reading the onboarding scaffolding — they don't need a separate training session. The framework is in the work, not adjacent to it.

4. Made the conflict scenarios explicit. Some decisions inherently produce conflict between seats — and the team needed to know how to handle them without escalating. I wrote up four behavioral conflict scenarios under CI-CD-Pipeline-User-Stories/ covering ML-gate disagreements, rollback policy disputes, tooling fights, deployment-frequency arguments. Each scenario shows what each persona would say, where the disagreement is actually coming from, and how to resolve it without picking a winner. Most conflicts are framing problems, not preference problems.

5. Stopped attending most architecture meetings. Hard part. Started declining meetings I'd previously sat in on, with a note: "Use the five-persona framework, send me the doc, I'll review async." First two weeks were rough. Decisions still got made, mostly correctly. By month two, the team was producing better-argued decisions than they had with me in the room — because the discipline of writing all five views forced the rigor I used to provide by being a single voice.

The math/algorithmic depth that mattered

This story isn't about an algorithm. It's about which question to ask first — and that's where the DS background and the Amazon mentorship merge:

  • The DS degree taught me to look for confounders before answers. When a team is debating "should we use rank 8 or 16," the right move is rarely to pick — it's to ask what variables are confounded in the disagreement. The five-persona framework is, structurally, a confounder check: each persona surfaces a different variable that the other four are implicitly holding constant.
  • The Amazon experience taught me that clear thinking happens on paper, not in conversation. Working backwards / PRFAQ / six-pagers — the cultural artifacts of Amazon are all about forcing argument structure into written form before talking. The five-persona framework is the same idea applied to engineering decisions: the writing is the work; the meeting is just verification.

The leadership move

The framework's actual power isn't the personas — it's the forcing function. By requiring all five views to be written down before the meeting, you eliminate the "loudest voice wins" failure mode without anyone having to be the meeting referee. The structure does the work.

The deeper move was naming the seats explicitly. "What would Aiko ask?" is a much easier question for a junior engineer than "what's the data-science perspective on this?" — even though they're the same question. Personas reduce the cognitive load of cross-functional reasoning, especially for engineers who haven't yet built a strong intuition for the other seats.

There's a Trojan-horse effect, too. Engineers who use the framework long enough start asking Aiko-questions in their own designs without prompting. The personas internalize. You're teaching multidisciplinary thinking through repetition with named hooks — same principle as how the DS degree teaches you to think probabilistically by making you write probability for two years.

Result

  • Decision escalations to me dropped roughly 70% within two months.
  • Decision quality stayed flat or improved (measured by post-decision regret rate — how often we revisited a decision within 30 days).
  • Two junior engineers grew into senior-judgment positions over the next 6 months — both attributed it explicitly to the persona framework giving them a model for cross-functional thinking.
  • The framework outlived me on the project; new lead hires inherited it as the team's operating system.
  • Embedded across 18 fine-tuning deep dives and 4 behavioral conflict scenarios — see Fine-Tuning-Foundational-Models/.

What I'd want a future ML lead to take away

Your job as lead isn't to make the right decision in every meeting. It's to build the system that produces right decisions when you're not in the meeting. The framework doesn't have to be five personas — pick whatever maps to your team — but it has to be a forcing function for cross-functional argument that doesn't depend on you being there. If your team's decision quality drops the day you're on PTO, you haven't built a team yet; you've built a dependency.