TL;DR: If you present a problem and solution simultaneously, people skip the problem and jump to poking holes in the solution. Split them across two meetings. Week 1: make the problem feel urgent. Week 2: present options. Also — meeting scripts are ESL cheat codes.
This is the communication companion to 62% of Our Packages Are Blocked by torch and Three Ways to Smuggle torch into Bazel. Those posts cover the technical problem and experiments. This one covers how to make a room full of engineers care about it.
The Setup
I’ve been running a Bazel migration on a 95-package Python monorepo. The work was going fine until I hit a wall: 62% of packages are blocked by GPU/native dependencies, mostly torch. I ran three experiments, got CI green on all three, and had a recommendation ready.
So I booked a meeting to present everything.
Then I stopped. Because I’ve seen what happens when you walk into a meeting with “here’s the problem AND here’s my solution.”
What happens is: nobody listens to the problem.
The Two-Meeting Strategy
Instead of one meeting, I split it into two.
Week 1 — “The Blocker Framing”
- Present the problem. Numbers, dependency diagrams, the absurdity of the current state.
- End with “I’m exploring solutions — results next week.”
- Goal: make the team feel the problem before anyone tries to solve it.
Week 2 — “The Experiment Results”
- Quick recap, then three options with tradeoffs.
- Recommendation at the end.
- Goal: team has context, so the discussion is about tradeoffs — not “is this even a real problem?”
Why split? Because the dynamics of problem-and-solution meetings are broken in a specific way.
Why Problem-First Works
When you present a problem and solution together, the room’s attention splits. Some people are still processing “wait, 62% of packages are blocked?” while others have already jumped to “but what about the Bazel 8 bzlmod bug in your custom Starlark rule?”
You end up defending implementation details to people who don’t yet understand why the work matters.
By separating them:
- Week 1 builds shared context. Everyone walks out with the same mental model.
- Week 2 starts from that shared context. Questions are about tradeoffs, not “remind me why we care.”
It also does something subtler: it creates anticipation. “I have a plan forming. Results next week.” Now people are curious. They show up to week 2 pre-engaged instead of cold.
Leading with Numbers
The first thing I said in the meeting:
“Out of 95 packages in the monorepo, 62% are blocked.”
Not “I’ve been analyzing the dependency graph and there are some concerning patterns in the transitive closure of native dependencies.” Just the number.
Three numbers anchor the entire conversation:
- 95 total packages
- 62% blocked
- 27 depend on torch directly
If you lose your thread mid-meeting — and you will — come back to the numbers. “The main point is, 62% of packages are blocked by torch.” Reset, reorient, continue.
Numbers do something that narrative can’t: they stick. A week later, when my squad lead is thinking about priorities, he’s not going to remember my explanation of dependency graph cascades. He’s going to remember “62%.”
The “Aha Moment” Pattern
Every technical problem has one detail that makes the room go “…wait, what?” Find it. Lead toward it. Let it land.
For me, it was mai_config.
“There’s a package called mai_config. It’s a config utility — it reads settings, sets defaults, things like that. But it imports torch. A config package depending on a 2GB GPU framework.”
Pause. Let the absurdity register.
Then the second one:
“The current workaround for flash-attn?
sys_platform == 'never'. A platform that doesn’t exist. So pip just skips the dependency entirely.”
These aren’t just fun facts. They’re proof that the problem is deep, not surface-level. Anyone can say “we have dependency issues.” But when you show them a config package importing a GPU framework, and a production workaround that literally pretends a dependency doesn’t exist — now they understand this isn’t a matter of tweaking a config file.
The trick is delivery. Don’t explain why it’s absurd. Just state the fact. Deadpan. Let the room arrive at the absurdity on their own. It lands harder that way.
The Strategic Hold-Back
The hardest part was not presenting the solutions.
I had three working experiments. CI green on all of them. PRs ready. I was proud of the work and wanted to show it. But I said:
“I’m exploring several approaches. I want to present results next week once I have more data.”
And then the magic sentence:
“Today I mainly wanted to frame the problem so everyone understands why this is the biggest blocker and why it needs priority.”
This does two things:
- Signals competence — “I have a plan forming” means you’re on it, not stuck.
- Protects the problem-framing — if you reveal solutions, the conversation pivots to implementation critique. The problem never gets its moment.
Handling Pushback (The Branches)
The thing about meetings is they’re not linear. Someone will ask a question you didn’t expect, or challenge a premise you thought was obvious.
I prepped for this by scripting branching responses — the same way you’d handle conditional logic in code.
Branch: “Can’t we just migrate the easy ones and deal with torch later?”
“We can, and I’m doing that in parallel — those 23 are straightforward. But without solving torch, we cap out at 33%. If we’re serious about Bazel being the build system, we have to crack torch eventually.”
Measured. Data-driven. Not emotional. And notice: I acknowledged their suggestion (“we can”) before redirecting.
Branch: “Won’t you just hit the next wall with GPU test execution?”
“Fair point. That’s a separate problem. Today I’m focused on dependency resolution — can Bazel even see the package graph. Test execution is the next layer.”
Acknowledge. Scope-bound. Defer. This is “yes and” from improv, adapted for engineering meetings. You never say “no, that’s wrong.” You say “yeah, fair point — and here’s how it relates to what I’m discussing.”
The ESL Angle: Meeting Scripts as Cheat Codes
Here’s the part I don’t usually talk about publicly.
I’m an ESL speaker. Mandarin is my first language. And meetings — especially ones where I’m presenting — are cognitively expensive in a very specific way.
English comprehension is fine. I can read anything, process complex technical docs, follow fast conversations. But English generation under pressure — producing fluent, precise, confident sentences in real-time while also managing social dynamics and technical content — that’s the hard mode.
It’s not a vocabulary problem. It’s a real-time generation problem. When someone asks an unexpected question, three things compete for cognitive bandwidth simultaneously:
- Parse the question (in my second language)
- Formulate a technical answer
- Construct grammatically natural English sentences
Any two of those is fine. All three at once? That’s where the freeze happens.
Scripts Fix This
Meeting scripts aren’t about memorizing lines. They’re about converting real-time generation into pattern matching.
When Ryan asks “is that a uv bug or a rules_py limitation?” — I’ve already rehearsed the answer. My brain doesn’t have to generate it from scratch. It just has to recognize the pattern and retrieve the pre-loaded response.
The key parts of the script:
Recovery phrases — pre-loaded sentences for when you lose your thread:
- “The main point is, 62% of packages are blocked by torch.”
- “Can you say more about what you mean?”
- “That’s a good question. Let me think about it and follow up on Slack.”
These sound trivial. They’re not. When you’re mid-freeze, having a practiced recovery phrase is the difference between awkward silence and a smooth reset.
Branching responses — multiple prepared answers for the same question, depending on how the conversation goes:
- If they agree → next point
- If they push back → acknowledge + redirect
- If you don’t understand → clarification phrase
Stage directions — notes to yourself about tone, not just words:
- “(deadpan delivery — let the absurdity speak)”
- “(confident but not overselling — you’re holding the reveal)”
- “(measured, data-driven — not emotional)”
The Practice Protocol
- Read through silently once. Understand the flow.
- Say your lines out loud. Not reading — performing.
- Focus on the branches. Those are the high-value rehearsals.
- Say the numbers out loud: 95, 62%, 27, 59. Until they’re automatic.
- If a line feels unnatural, rewrite it until it sounds like you.
This is not “practicing a presentation.” This is rehearsing a conversation. The difference matters. Presentations are monologues. Meetings are dialogues. You need to practice the back-and-forth, not just your opening statement.
Who This Is For
If you’re a native English speaker reading this and thinking “wow, that’s a lot of prep for a team meeting” — you’re right. It is. But here’s the thing: you’ve been rehearsing English conversations since you were two years old. You have decades of pattern-matching built up.
I’m building that library in real-time, for a second language, in a professional context where “um, let me think about how to say this” reads as “doesn’t know the answer.”
The scripts level that playing field.
And honestly? I think native speakers would benefit from this too. Most meetings are bad because people are winging it. Preparing branching responses forces you to think about what people will actually ask, not just what you want to say.
The Meta-Pattern
If you take one thing from this post, it’s this:
Separate the problem from the solution. Let the problem land first.
This applies to:
- Meeting presentations — two meetings beats one
- PR descriptions — lead with “why” before “how”
- Incident postmortems — establish the failure mode before proposing fixes
- Architecture proposals — frame the constraint before the design
- Convincing your manager — show the gap before pitching the project
The best technical communicators I’ve worked with all do this instinctively. They make you feel the problem before they offer relief. It’s the difference between “here’s what I built” and “here’s why you should care what I built.”
Week 2 is coming. Three experiments, three PRs, all CI green. But that’s a different post.
Field notes from presenting a Bazel migration blocker to a DevEx squad. The two-meeting strategy, meeting scripts, and “hold back the solution” technique are real practices I use. The ESL meeting prep workflow was built with Claude Code.
Previously: 62% of Our Packages Are Blocked by torch — the technical blocker analysis. Next: Three Ways to Smuggle torch into Bazel — the experiment results.