一日の終わりに request が届く。最初は小さく聞こえる。"明日までにこれも入れられる？" release は近い。みんな疲れている。役に立ちたい。若い頃の私は、たぶんすぐ yes と言っていた。
Developer は solve するように育つことが多い。役に立つことが好きで、制約の中で道を探すのが好きだ。だから pause する人が、協力的でないように見えることがある。
No を学ぶことは negative になることではない。本当の yes を可能にする条件を守ることだ。risk を隠した yes は、長い目で見ると親切ではない。
最初の step は tradeoff の言葉に変えること。"明日できます。ただし reporting task は動かす必要があります。" "この release に入れられます。ただし別の change を外すか、test scope を狭める必要があります。"
次に urgency と importance を分ける。production down、customer blocked、security issue は本当に urgent だ。一方で、meeting の空気や誰かが今気づいたことから生まれる emotional urgency もある。
よい no は代案を持つ。"この release には入れないが、technical note と estimate は今日出せる。" "この API shape ではないが、安全な小さい version ならできる。"
一番よい no は、calm、specific、early であることが多い。落ち着いていて、何を守っているか具体的で、遅すぎない。遅い no は正しくても裏切りのように感じられる。
"助けたい。そしてこの計画のままだと後で痛む。" その一文には care と boundary の両方がある。よい team では、そのような no は信頼の一部になる。