Lunch & Learn series on From Code to Team (Second Edition), Chapter 12. 20 minutes: a story before the first slide (under 4), 12 talk, 4 discussion. Verbatim script; timing marks are the running clock. Slide numbers match the deck.
Room: mixed — leads, aspiring leads, and engineers who never intend to lead. Everyone has a product partner, directly or one level up. Most would describe the relationship as fine.
0:00Told with the title slide up and nothing else. Under 4 minutes. Not on any slide. Presenter's voice; swap in your own, keep the shape.
Imagine you have just paid a builder to put a window exactly where you asked for it. And it is exactly where you asked. And it is wrong.
My sister-in-law renovated a kitchen 2 years ago. She is organized — she arrived at the first meeting with a folder. In the folder was a drawing she had done herself, on graph paper, with a window on the north wall, 1,200 wide, sill at 900, and a date: finished by Easter; we have people coming. The builder — a good one, 30 years at it — looked at the drawing, said "no problem," and built it. On time. To the millimeter. He was, by any measure, a competent man who did what he was asked.
Easter lunch. Fourteen people in the new kitchen. And at about 1 o'clock, my sister-in-law is standing at the sink with the sun straight in her eyes, because the window she drew faces the one direction that gets the afternoon glare, and the reason she wanted a window at all — the only reason, it turned out — was that she wanted to see the kids in the garden while she cooked. The garden is on the west. The window is on the north. She can see the neighbor's fence.
Nobody was angry. That is the part I want you to notice. She was not angry with the builder — he had built her drawing. He was not angry with her — she had given him a drawing. Everyone was polite. And everyone had, for 3 months, been holding a different picture of what that window was for, and not one conversation had happened in which anybody said the word garden.
Six months later she had a different builder in to move it. This one did something the first one had not. Before he measured anything, he sat at the kitchen table with a cup of tea and asked 3 questions: "What do you want to be able to do in this room that you can't do now? What's the date actually about — is it the lunch, or is it just a date? And what are we definitely not touching?" And she said, "See the kids in the garden," and he put his tea down and walked to the west wall and said, "Then it goes here, and it's smaller, and it's cheaper, and it's done by March."*
She told me the difference between the 2 builders in one sentence: "The first one built what I drew. The second one built what I wanted, and then told me what it would cost."
That is what today is about. The people who bring you solutions with dates attached are not being unreasonable. They are being uninformed — about your side — the same way you are about theirs. And the polite version, where everyone nods and builds the drawing, is the one that costs the most.
3:30A pattern I keep finding when I read back through my own notes: the priority conflicts that did real damage were almost never the ones anybody saw coming. They were the ones where a customer escalation reached a peer VP before it reached me, and the story I had been telling internally was already 3 days out of date.
The arguments you can see — the roadmap disagreement, the unrealistic date — are survivable; both parties know they are in one. The damage comes from the quiet weeks where you and your product partner each hold facts the other does not, both operate confidently, and somebody senior finds the gap first. The best product-engineering relationships I have been part of did not feel like negotiation. They felt like 2 people running the same play from opposite sides of the ball. The worst were not hostile. The worst ones were polite.
5:00They own why and what. You own how and most of when. Everything else is a trade you make out loud. You want them to bring the customer problem, the context, and the boundaries — not a pre-cooked solution wrapped in a deadline; a solution arriving with a date is a decision somebody made without the information you have, and accepting it silently is how teams build the wrong thing competently. You owe them engineering ground truth early enough to be useful — what you can commit to, the second-order costs, and where you think they are solving the wrong problem. That last one is an obligation, not a courtesy.
Session 4 installed the ceremony-level version of this: the trade at planning, the mid-sprint ticket that displaces something named. Those work inside a fortnight with a chair. This is what happens outside the room — the relationship those ceremonies rest on, which nobody chairs. And for the engineers who never intend to lead: the second half of today, the decision method, is the most immediately usable thing in the book. You will run it on Wednesday.
6:15