Honest Take — Module 6: Establishing Shared Context #
"Are we on the same page?" is the most over-used and under-delivered phrase in engineering culture. People say it. Almost no one means it. Almost no one verifies it. Most meetings open with the assumption of shared context and then waste forty minutes discovering there were four mental models in the room the whole time, all subtly different, all unspoken. The cost of those forty minutes is real. The cost of the silent divergences — the ones nobody discovered, where the project shipped misaligned — is much larger and never measured. This module is the protocol that fixes it, and I want to be clear that it is a real protocol, not a vibe. It's also the module the two earlier drafts of this curriculum disagreed about most structurally: one made it a standalone module and a hard prerequisite for conflict, cross-functional work, and pitching; the other folded alignment into meeting craft and never named it as a skill. This edition sided with the first draft, and I think rightly — Modules 7, 8, 10, and 13 all fail in undiagnosable ways when participants don't share context first.
Here is the engineering claim, stated cleanly: the same-page problem is the distributed-consensus problem. You have spent your career on systems that cannot trust two participants to share state without an explicit protocol — two-phase commit, Paxos, Raft. You know in your bones that asking nodes "are we in agreement?" without a confirmation phase is a design that will eventually corrupt your data. You apply this rigor to your software and not to your conversations. The ladder of inference is the divergent log each participant appends privately. The playback is the commit phase. The pre-read is log replication before the vote. The recovery protocol is conflict resolution after a partition. This is not metaphor — it is the same problem in a different substrate, and once you see it that way, the discipline becomes obvious instead of awkward.
The technique that produces the largest immediate change is the playback. At the end of any decision-shaped conversation, one person states in their own words what was just decided, and the others correct or confirm. Two minutes. Always. No exceptions. The first time you do it, you will be embarrassed, because it feels infantilizing — of course we know what we just decided. The first time you do it, you will also discover the room had three different interpretations of the same conversation. This keeps happening. The frequency does not go to zero, ever; the playback is not optional eventually, it is mandatory permanently. Most engineers I've watched grow into staff and principal roles installed this single habit early and never removed it. It is the highest-ROI behavior change in this entire curriculum.
The sub-skill you'll resist most is forcing definitions on the ambiguous nouns — "done," "MVP," "blocker," "soon." The first time you ask "when you say MVP, what specifically do you mean?" the room will pause, and the pause will feel like you've broken a social rule. The pause is the work. The pause is also where the project gets saved, because agreement on a word is not agreement on a meaning — it's the illusion of agreement, which is worse than open disagreement because nobody knows to fix it. One cultural note, treated fully in Module 12 but load-bearing here: in high-context cultures and across native-language gaps, "yes" often means "I heard you," and silence often holds disagreement that doesn't feel safe to voice. The protocol's fix — ask for the concern, not the agreement: "what's the strongest argument against this plan?" — pulls silent divergence into the open without forcing anyone to perform confrontation.
The four-week checkpoint will be uncomfortable in a specific way: you will run every meeting with the protocol, and within two weeks you will see colleagues' faces visibly relax. They did not realize how often they were operating in fog. You did not realize you were in the fog with them. That relaxation is data — proof the protocol is solving a problem they were experiencing too and were too polite or too senior to name. After it happens three or four times, you become the person teams quietly want in the room. Not because you're the smartest. Because you're the one who reliably leaves the room with a shared state.
And defend the pre-read against its own theater. Sending the doc 24 hours ahead only works if anyone reads it, and mostly they don't — the meeting then proceeds as if everyone had, which is worse than no pre-read because the illusion of shared context now has a paper trail. When the stakes justify it, run the silent-reading pattern: the first five minutes of the meeting are everyone actually reading, in the room, in silence. It feels deeply strange exactly once. By the third week, the discussion quality is so obviously better that the team defends the ritual without you.
Conclusion #
Shared understanding is not the default. It must be actively constructed. The distributed-systems engineer in you already knows this; the conversational runtime in you has been ignoring it. The protocol only works when used, and the four-week discipline is the deliverable — Pass 1 gives you the moves, but protocol-as-theory produces the worst outcome of all: believing you verify alignment now while still not doing it, with extra confidence. This is the hinge module. Everything team-shaped that follows stands on it.
Predictions #
-
The first playback you run will surface at least one substantive divergence, and you will be slightly stunned. By the fifth, you'll be unsurprised that there is always one, and grateful the protocol caught it.
-
You will roll your eyes at the protocol in week two because it feels slow. By week four, when someone else ends a meeting without a playback, you will physically feel the absence and want to insert it.
-
The hardest moment will be forcing a definition in a room where you're not the most senior person. Do it once and watch what happens — the senior people are usually relieved someone asked.
-
You will resist the discipline most when tired or rushed — exactly when divergence is most likely. That's why the practice runs four weeks: to make the protocol automatic enough to survive your bad days.
-
A colleague will tell you, within six weeks, that "meetings with you are different now — clearer." They won't know why. You will. Don't explain; just keep doing it.
-
The checkpoint essay — "What I Found When I Stopped Assuming We Were on the Same Page" — will surface one specific past failure you'll re-read in a completely different light. The re-reading is the actual learning; the essay is just the artifact.