"Ask for No, Don't Ask for Yes (2022)" 영화

Hacker News 의견

• 대기업에서 중요한 기술임. 모두 바쁘고 일이 잊혀지기 쉬운 상황에서 유용함. 이메일로 문제를 설명하고 "만약 [N]일 내에 답변이 없으면, [DAY N]에 XYZ를 하겠습니다"라고 말함. 이는 승인을 기다리지 않고 상대방에게 통보하는 방식임
  • 가끔 몇 주 후에 누군가가 XYZ를 했다고 화를 내지만, 그들이 실수한 것임을 보여주는 기록이 있음
  • 이를 "묻지 말고 말하라"라고 부르며, 직장 안팎에서 다양한 용도로 사용 가능함. 명확하고 결정적인 결과를 이끌어냄
  • 아내와도 자주 이런 대화를 나눔. 아내는 질문하는 스타일임. 저녁 모임에서 아내는 "몇 시에 도착할 건가요?"라고 물었지만, 나는 우리가 언제 도착할지 알려주고, 바에서 기다릴 것이라고 말함. 결과적으로 모두 일찍 도착했고, 최소한의 소통으로 완벽했음
  • "용서를 구하라, 허락을 구하지 말라"는 아이디어와 관련이 있음. 위험할 수 있지만, 나는 본질적으로 반항적임. 그러나 GitHub 같은 협업 환경에서는 큰 변화를 무작정 시도하는 것은 좋지 않음
• 동료들에게 추천 승인을 받는 방법에 대해 조언을 줄 때 비슷한 말을 함
  • "승인을 쉽게 받을 수 있도록 하라"
  • 문제를 간단히 설명하고 해결책이 왜 맞는지 설명함. 더 깊이 알고 싶다면 문서 링크를 제공함. 이미 팀원이나 제품 소유자에게 승인을 받았는지 확인함
  • "우리는 X를 해결하기 위해 Y를 할 것입니다. 팀은 모두 동의했습니다. 자세한 내용은 [링크]에 있습니다. 추가 피드백이 필요하지 않으면 화요일에 시작할 것입니다"
  • 관리자들은 모든 세부 사항에 시간을 쏟을 수 없으므로, 팀의 지지를 얻은 경우 승인을 쉽게 할 수 있음
• "의도를 방사하라"는 접근 방식도 있음. 하고자 하는 일과 계획을 알리고, 이해관계자에게 명시적으로 반대할 기회를 줌. 일부 상황에서 작동하며, 기본적인 신뢰가 필요함
• 처음으로 무언가를 망가뜨리면 재앙이 될 수 있음. 예, 아니오를 받는 것은 상사가 알고 있다는 것을 의미함
  • "누가 승인했나요?"라는 질문에 아무도 승인하지 않았다고 답할 수 있음
• 이 접근 방식은 미국 회사나 미국식 비즈니스에 익숙한 상사에게만 작동할 수 있음. 상사가 좋아하지 않으면 역효과가 날 수 있음. 성과 평가에서 상사가 불복종으로 낙인찍을 수 있음. 때로는 허락을 구하는 것이 최선일 수 있음
• "내가 이 일을 할 것입니다"라는 트릭의 일부는 질문처럼 표현하지 않는 것임. 이렇게 하면 수신자가 답장을 쓸 필요가 없고, 추가 이메일을 읽을 필요가 없음
  • GitHub와 Google Docs의 이모지 반응 기능을 좋아함. 간단한 방법으로 동의했음을 알릴 수 있음. HN에서는 인기가 없지만, 이모지 반응은 간단한 소통 방법임
• OP의 입장을 이해하지만, 용서를 선호하는 것은 상황에 따라 다름. 소셜 네트워킹 웹사이트에서는 빠르게 움직이고 실수를 할 수 있지만, 핵 발사 제어 시스템에서는 "허가될 때까지 발사하지 않음" 시스템이 필요함
  • 큰 협업 프로젝트에서 이 기술을 사용함. "합의에 도달하지 않으면 기본 선택을 따르겠습니다"라고 말함. 젊었을 때는 끔찍한 기본값이 필요하다고 생각했지만, 이는 몇 번만 작동함
• "합리적인 기본값을 만드는 것"이라고 부름. 모든 세부 사항에 대해 결정을 요청하는 대신, 상황에 대한 지식을 보여주는 기본값을 선택하고 이를 실행할 것이라고 알림. 이는 신뢰를 쌓고, 정말 필요할 때 주의를 기울이게 함
• 이 소통 방식이 좋지만 "마감일" 부분은 선호하지 않음. 보고서가 내가 반대할 수 있는 작업을 하고 있는지 알려주기를 바람. 관리자에게 마감일을 주는 것은 이상하고 성가신 위협처럼 느껴짐. 팀원들에게 자율성을 주고 싶음