You need to sign in or sign up before continuing.
Reflection — An Honest Take 8 min

Honest Take — Before You Begin

Honest Take — Module 8: Across the Aisle #

I want to be careful with this one, because for a meaningful slice of readers it inverts the usual diagnostic posture. If you're the integrator type — the engineer whose career is already full of crossings, who has translated a designer's intent into code, turned a sales conversation into a schema, built the product-shaped solution to an engineering-shaped request — then you already make this module's move, repeatedly, without naming it. The risk in writing for you is either understating that (inaccurate) or inflating it into flattery (insulting). The honest version: what this module gives you is not the skill. It's the names for the moves, so you can make them deliberately, debug them when they fail, and — this is the part that matters for your career — teach them. Most growth past senior is transferring patterns you've internalized to people who haven't. The naming is the precondition for the transfer. And if you're not the integrator type, the module is more straightforwardly new material, and the core move is learnable: beneath most stated requests sits an underlying need, and the question "what would having that let you do?" is how you find it.

Two gaps I'd guess at even for the reader who's already good at this. First: the translation reflex works better in writing than in real time. The engineer whose docs adapt register beautifully for non-technical readers is often slower in the live cross-functional moment — the unscheduled customer call, the design review question from left field — partly because of the introvert's activation gap from Module 5, partly because live translation is just harder. The post-call summary practice helps more than it looks like it should, because it converts a real-time skill into a writing-bracketed one: you get a second pass at the translation, in your home medium, within the hour. Second: the commercial conversations have a specific shape worth pre-loading. When a client or stakeholder asks "how much would it cost to...," the underlying ask is rarely "give me a number" — it's "help me understand whether this is feasible, worth it, scope-able." Engineers default to producing the number. The better move is surfacing the real question first: "before I estimate — what would this unlock for you, and what range are we working within?" That's not sales manipulation; it's the same underlying-need question applied to money. Module 15 builds a whole discipline on it.

A confession about my own framing. I lean heavily on the underlying-need-vs-stated-request model in this module, and the model is real — independently arrived at by product, design research, sales, and therapy traditions, which is decent evidence. But it's incomplete, and over-applying it is its own failure mode. Sometimes the stated request is the whole story: the customer just wants the bug fixed; the PM just wants the feature shipped. Run the dig-deeper move on every interaction and you come across as condescending or evasive — the engineer who answers a question about the deploy date with a discovery interview. The skill is calibrating when to dig and when to just deliver, and I don't have a clean rule for it. Experience teaches it, faster if you're paying attention. The translation audit in the checkpoint is how you start paying attention.

One more honest note: the cross-functional posture this module teaches — engineer, PM, and designer as roughly equal parties who can push back on each other — is itself a cultural assumption, mostly American in origin. Plenty of working cultures carry stronger implicit hierarchies about who's allowed to question whom. If you operate across cultures (Module 12 is the full treatment), the integrator posture is more egalitarian than many defaults, and the move is to choose deliberately when to lean into it and when to honor a different convention. There's no universal answer; there's calibration.

It helps to know each counterpart's deserializer by its load-bearing variable, because the translations aren't interchangeable. The PM lives in priorities — your technical concern lands when it's rendered as a tradeoff against something already on their list, not as an abstract quality argument. The designer lives in intent — "this interaction is expensive to build" goes nowhere; "here's a cheaper interaction that preserves what you're going for" goes everywhere, but only if you've understood what they're going for. The salesperson lives in commitments — they've promised someone something, and your real conversation is about which commitments engineering can stand behind. The customer lives in outcomes and almost never in mechanisms. Same underlying need beneath every stated request; four different renderings.

And steal one practice from the consulting world regardless of whether you ever consult: the post-call summary. After any substantive cross-functional conversation, send five lines — what we discussed, what was decided, what I heard as the underlying goal, what happens next, what I might have gotten wrong. It's Module 6's playback in written form, it catches translation errors while they're still cheap, and it quietly builds your reputation as the engineer whose conversations produce records instead of vibes.

Conclusion #

The integrator move has a structure: find the underlying need beneath the stated request, then render your answer for the receiver's deserializer — the PM's priorities, the designer's intent, the customer's outcome, the salesperson's commitment-shaped world. If you've been making this move tacitly, the work now is noticing when you make it and when you don't, until the pattern becomes controllable, then teachable. The Mom Test is the sharpest book in the module precisely because it's the inverse of pitching: the best translation starts with the best listening.

Predictions #

  • The translation audit will surface an asymmetry you didn't expect: you under-dig in friendly contexts (probing feels rude when things are warm) and over-dig in formal ones (turning small asks into big conversations). The audit gives you the data to rebalance.
  • The boundary conversation with a PM or stakeholder will go better than expected with one person and worse than expected with another — and the one it goes badly with is the relationship that most needed it. That's not bad data; it's the data.
  • The Mom Test will become the book from this module you quote most in the next year, possibly without noticing you're doing it. It's the rare cross-functional book that's short, specific, and doesn't pretend to more than it covers.
  • Within six months, you'll catch yourself running "what would that let you do?" in a conversation that has nothing to do with work — a friend stuck on a decision, a family member's request that doesn't add up. The skill is portable; that's the deeper benefit.
  • You'll over-dig for the first few weeks after this module. People will gently signal it. You'll calibrate down. The over-dig phase is part of the learning, not a failure of it.
  • At least once in the next year, a stakeholder's stated request and underlying need will genuinely diverge on something that matters, and catching it will decide whether the work ships well. The pre-module version of you might have built the stated request and been confused by the lukewarm reception.