“예”를 구하지 말고 “아니오”를 요청하라 (2022)

• 작은 회사에서 자기 업무 범위 안의 일을 추진할 때는 허가를 기다리기보다 거절할 기회와 기한을 주는 방식이 실행 속도를 높일 수 있음
• “action X를 설치해도 될까요?” 같은 승인 요청은 상사에게 문제 검토, 해결 방식 판단, 우선순위 조정까지 떠넘겨 답변이 늦어질 수 있음
• “월요일에 action X를 설치하겠습니다. 다르게 생각하시면 알려주세요”라고 말하면 실행 의지를 보이면서도 상사가 개입할 여지를 남김
• 이 방식은 일이 자신의 역할 범위 안에 있고, 피드백은 환영하지만 답이 없어도 진행할 만큼 방향에 자신이 있을 때 적합함
• 가까운 기한을 함께 제시하면 필요한 사람이 더 빨리 반응할 가능성이 커지고, 실행을 멈추지 않으면서도 관계자를 계속 알릴 수 있음

---

허가를 기다리지 않고 거절 기회 주기

• 아주 작은 단계라도 앞으로 나아가는 실행 편향은 정체 상태를 깨는 데 도움이 됨
• 핵심 습관은 “예”를 요청하지 않고 “아니오”를 요청하는 방식임
  • 경험 기반은 직원 수 200명 미만의 작은 회사임
  • 큰 회사, 비영리 조직, 정부 조직에서도 같은 방식이 통할지는 확실하지 않음
• 자기 업무 범위 안에 있다고 느끼는 일을 하려 하지만 안심이 필요하거나 상사에게 알리고 싶을 때, 보통은 먼저 허가를 구하게 됨
• 대신 상사에게 거절할 기회를 주고, 그 판단을 할 수 있는 명확한 기한을 함께 제시함

GitHub Action 예시로 보는 차이

• 예시는 소프트웨어 품질 개선에 도움이 된다고 판단한 새 GitHub Action을 저장소에 설치하는 상황임
  • 단순한 변덕이 아니라 조사와 로컬 테스트를 거친 상태임
  • 이전 동료에게 해당 GitHub Action 사용 경험을 물어봤을 수도 있음
• “action X를 설치해도 될까요? 우리가 겪는 XYZ 문제에 도움이 됩니다”라고 묻는 방식은 상사가 “예”라고 말하기 전에 추가 작업을 하게 만듦
  • XYZ 문제를 다시 검토해야 함
  • X가 문제를 어떻게 해결할지 판단해야 함
  • 다른 업무와의 우선순위를 따지거나, 담당자가 알고 있는 내용을 먼저 공유하길 원할 수 있음
  • 바쁜 상사에게서는 이 일이 밀릴 수 있고, 여러 번 리마인드해야 할 수 있음
• 대안은 “XYZ 문제를 해결할 action X를 설치하겠습니다. 다르게 생각하신다면 알려주시고, 그렇지 않으면 월요일에 처리하겠습니다”라고 말하는 방식임
  • 담당자가 문제를 직접 처리하겠다는 신호가 됨
  • 상사는 원하면 개입할 수 있지만 반드시 답해야 하는 부담은 줄어듦
  • 상사가 잊거나 다른 일이 생겨도 진행이 멈추지 않음
• 이 방식은 개인뿐 아니라 여러 사람으로 구성된 그룹에도 적용할 수 있음

기한이 만드는 응답 압력

• 기한은 이 접근의 핵심 요소임
  • 1월 15일 기준으로 “task X를 하겠습니다”보다 “1월 17일에 task X를 하겠습니다”가 더 빠른 반응을 유도할 수 있음
  • “2월 15일에 task X를 하겠습니다”처럼 먼 기한보다 가까운 미래의 기한이 더 즉각적인 응답을 이끌 가능성이 큼
• 피드백 기회는 열어두되, 피드백이 없어도 실행할 만큼 방향에 자신이 있을 때 가장 잘 맞음

[GN⁺]

Hacker News 의견들

• 모두가 바쁘고 일이 묻히기 쉬운 대기업에서는 이게 핵심 역량임
  이메일에 문제를 설명한 뒤 “[N]일 안에 답이 없으면 [N일째 되는 날] XYZ를 하겠습니다”라고 적음. 승인 요청을 해놓고 무력하게 기다리거나 재촉하는 대신, 가만히 있으면 XYZ가 진행된다는 통지를 남기는 방식임
  가끔 몇 주 뒤에 왜 말 없이 했냐고 화내는 사람이 나오지만, 그때마다 상대가 놓친 기록을 보여줄 수 있음

  • “답이 없으면 XYZ를 하겠다”는 표현은 불필요하게 대립적으로 들림
    “이런 이유로 XYZ를 하려고 하고, [날짜]에 진행하겠습니다. 반대나 우려가 있으면 알려주세요”처럼 말해도 충분함
    이 방식은 사전에 탄탄한 근거를 제시하게 만들고, 본인이 모르는 제약이나 실수를 피하기 위한 피드백도 받을 수 있게 해줌
    Amazon의 리더십 원칙을 문제 해결책처럼 따라 하는 화물 숭배식 행동도 이상함. “행동 편향”이 Amazon에서 통하는 건, 독단적으로 움직였다가 실패한 사람은 희생양이 되어 해고되고 그런 사람들은 행동 편향의 미덕을 블로그에 쓰지 않기 때문임
  • 실제로는 어떻게 표현하는지 궁금함
    “3월 1일에 thingamajig를 조각 모음할 예정입니다. 이 작업이 문제를 일으킬 수 있는 분들께 미리 연락드립니다. 우려가 있으면 알려주세요. 3월 1일까지 답이 없으면 thingamajig는 조각 모음됩니다” 같은 식인지
  • 이건 약간 판타지처럼 들리거나, 어기는 규칙이 사업적으로 전혀 중요하지 않은 경우에만 가능해 보임
    “5일 안에 답이 없으면 X를 하겠다”는 말은 징계를 받을 수 있는 일을 했을 때 아무 방어책도 되지 않음
    통하는 곳은 기껏해야 사업과 무관한 내부 설계 결정을 어기는 정도임
  • “가끔 몇 주 뒤에 누군가 XYZ를 말 없이 했다고 화낸다”는 부분이 수상함
    이런 걸 “항상 한다”고 하면서 마법 문구를 템플릿처럼 적는 게 정말 본인 경험인지, 아니면 본문처럼 일하고 싶다는 투사인지 의심스러움
    화난 동료들에게 기록을 보여줘서 승리하는 장면을 떠올리면 헛소리 탐지기가 빨간색까지 올라감
  • 누가 진행을 막거나 거부하고 있는지 기록으로 남기는 효과도 있어서 좋음

• 이걸 “묻지 말고 알려라”라고 부르며, 회사 안팎에서 쓸모가 많음
  기본적인 의사소통 기술이고, 결과를 간결하고 결정적으로 만들어줌
  아내와도 이런 대화를 자주 하는데, 아내는 “몇 시에 도착해?”처럼 8명 단체방에 열린 질문을 보내는 편임. 우리는 아이를 맡기는 일정 때문에 한 시간 일찍 도착한다는 걸 알고 있었으니, 그냥 “우리는 이 시간에 도착하고, 먼저 술 마실 사람은 바에 있겠다”고 알려주라고 했음
  답장을 요구하지 않아도 되고, 모두가 일찍 와서 최소한의 소통으로 잘 풀렸음
  “허락보다 용서를 구하라”와도 조금 관련 있지만, GitHub 저장소처럼 여러 사람이 협업하는 곳에서 다른 사람에게 영향을 주는 큰 변경을 막 던지는 건 좋은 자리가 아님

  • 나도 이렇게 함. 이건 단순히 더 나은 소통이 아니라 더 나은 삶의 방식이기도 함
    다른 사람들이 조율해줘야만 즐길 수 있는 상태가 아니라, 내가 하고 싶은 걸 시작하고 다른 사람에게 합류할 수 있다고 알려주는 방식임

• 동료들이 자기 제안을 승인받는 방법을 물어보면 비슷하게 조언함: “상대가 예라고 말하기 최대한 쉽게 만들어라”
  누군가에게 14문단을 던져놓고, 내가 몇 시간 동안 문제를 파고든 수준까지 바로 따라오길 기대하면 안 됨
  접근에 자신이 있다면 문제와 해법이 왜 맞는지 간결하게 설명하고, 더 깊이 보고 싶은 사람을 위한 문서 링크를 붙이면 됨. 팀원이나 제품 책임자에게는 이미 동의를 받아두는 게 좋음
  예: “X를 Y로 해결하려고 합니다. 팀은 모두 동의했습니다. 자세한 제안 문서는 [link]에 있습니다. 추가로 다룰 피드백이 없다면 화요일에 시작하겠습니다”
  관리자는 모든 세부사항을 들여다볼 시간이 없고, 넓은 팀의 지지까지 포함해 일을 정리해두면 승인만 하면 되므로 고마워함

  • 관리자가 이런 식으로 일하면 인기투표가 시작됨. 그런 관리자는 비효율적이거나 쓸모없음
  • “자신이 있다면”이 핵심임. 나는 자기애가 아니라 객관적 통계와 불확실성으로 자신감을 정함
    성공 확률이 10%지만 시도할 이유가 있다면 그렇게 말하지, 성공할 거라고 확신한다는 식의 헛소리 발표로 포장하지 않음. 성공 확률이 80%면 20%도 숨기지 않고, 98%라고 하면 실제로 그 정도에 가깝다는 뜻임
    관리자의 일은 이런 통계를 다루고 위험을 헤지하는 것임. 헤지펀드는 돈으로 하고, 관리자는 사람과 자원으로 함
    안타깝게도 전형적인 기업 관리자는 성공한다고 100% 말해놓고 실제로는 50% 실패하는 사람을 더 좋아함

• 비슷한 표현으로 의도 방사(radiating intent) 가 마음에 듦
  무엇을 언제 하려는지 널리 알리고, 이해관계자가 명시적으로 반대할 공간을 주되 합의·정렬·승인을 일일이 쫓지는 않는 방식임
  일부 상황에서 잘 통하고, 대체로 기본적인 신뢰를 먼저 얻어야 함
  https://medium.com/@ElizAyer/dont-ask-forgiveness-radiate-in...

  • “의도 방사”를 해야 하는 4가지 이유는 납득됨. 중간 이상 신뢰가 있는 조직에서 잘 작동함
    Eliz Ayer가 덧붙인 뉘앙스도 좋았음: “공정하게 말하면 의도 방사로는 일을 덜 해낼 수도 있다. 방해하거나 참견하는 사람에게 끼어들 통로를 주기 때문이다. 또한 이런 조언은 상황과 조직에 크게 의존하므로 항상 적절하지는 않다”

• 이런 의사소통 방식은 상대를 즉시 위험 인물로 보게 만들 것 같음
  겉으로는 시간을 아껴주는 것처럼 보이지만, 실제로는 관리자가 그 직원이 뭘 하는지 항상 챙기지 않으면 원치 않는 행동을 할 수 있다고 알려주는 방식임
  본문은 이를 알림처럼 다루지만, 아무리 선의와 이해가 있어도 알림은 신호의 소음 속에서 묻히기 쉽고, 답이 없다는 게 동의를 뜻하지는 않음. 메시지를 받지 못했다는 뜻일 수도 있음
  이미 직원과 관리자가 문제를 논의했고 이제 해법을 실행하는 상황이라면 괜찮을 수 있지만, 상대가 아직 고려조차 하지 않은 문제를 처음 꺼낼 때는 최악임. 이기적이고 팀워크의 정반대임
  전설적인 10x Rockstar 엔지니어가 이렇게 하는 걸 보고 따라 하는 느낌도 듦. 그 엔지니어는 늘 일을 잘하고, 무엇을 해야 할지 알고, 관리층과 상호 이해와 존중이 있어서 자율 관리를 맡길 여지가 있는 사람임. 그걸 본 누군가가 왜 그런 대우를 받는지, 자신은 어떻게 얻어야 하는지 이해하지 못한 채 자신에게도 적용된다고 생각한 것 같음

  • 결국 모든 건 관계에 달려 있음
    세 번 연속 이렇게 했는데 “멈춰달라”는 답을 받았다면 뭔가 어긋난 것임. 세 번 연속 칭찬을 받았다면 계속하면 됨
    진짜 위험한 사람은 안 된다는 말을 듣고도 대부분을 어떻게든 실행한 뒤, 나중에 예스를 찾는 사람임. 다음 일에서도 같은 식이고 피드백에 반응하지 않음
    그러니 핵심은 방식 자체보다 업무 관계임. 신뢰가 높고 모두가 바쁜 환경에서는 시도해볼 만함
  • 모르는 사람이 나에게 이렇게 하면 건방지고 짜증나게 느껴질 것 같음
    함께 일해봤고 신뢰가 있으며 내 시간을 존중해서 그러는 걸 안다면 전혀 다른 이야기임

• 처음으로 뭔가를 망가뜨리는 순간 재앙의 레시피가 됨
  예스나 노를 받았다는 건 상사가 알고 있었다는 뜻임. 일이 터져 “누가 승인했나?”라는 질문을 받으면, 진실한 답은 아무도 승인하지 않았다는 것임

  • 조직 문화와 관리의 효과성에 따라 크게 다름
    조직 안에 이렇게 행동할 수 있는 사람이 아무도 없다면, 리더십 팀이 위임에 실패하고 있다는 신호임
  • 이건 상사에게 쓰는 게 아니라, 작업에 관여해야 하는 동료 부서 사람들에게 쓰는 방식에 가까움
    예를 들어 Y팀의 X가 어떤 일에 반대하는 상황 같은 경우임
    상사가 1) 뭔가 해야 한다고 말하고 2) 어떤 계획도 승인하지 않는다면, 그냥 하지 않으면 됨. 그 경우 일을 되게 지시할 책임은 상사에게 있음
  • 상사가 하는 모든 일에 승인해야 한다면 그건 상사가 아니라 마이크로매니저이고, 둘 다 잘못하고 있는 것임
  • 적어도 소프트웨어에서는 아무도 혼자서 무엇이든 할 수 없어야 함
    “이걸 하겠다”는 말은 괜찮지만, 검토와 자동화 테스트 같은 절차 없이 프로덕션에 나가면 안 됨
    물론 그러면 병목이 생김. 병합 요청을 올렸는데 아무도 제때 검토하지 않으면 아무 일도 일어나지 않음. 이럴 때는 일정 시간 안에 확인하고 검토한다는 합의를 팀 리드 수준에서 정해야 함
  • 무언가를 책임진다는 건 망가뜨리고 고치는 것까지 포함

• 이런 접근은 미국 회사나 미국식 비즈니스 문화에 익숙한 상사에게서만 통하는 것 같음
  상사가 싫어하면 크게 역효과가 날 수 있음. 인사 평가 때 상사가 불복종이라고 딱지 붙이기 쉽고, 필요한 증거를 스스로 쟁반에 담아 건넨 꼴이 됨
  때로는 미국에서도 허락을 구하는 게 정말 최선이고, 자원과 관련된 일이라면 더더욱 그렇다

  • 불복종은 군대에나 어울리는 말임. 다 큰 성인이 “불복종”할 수 있다는 발상 자체가 우스움
  • 미국식이 아닌 업무 방식도 매우 다양함
    예를 들어 스칸디나비아 문화권에서는 관리가 꽤 손을 떼고, 직원들이 많은 결정을 독립적으로 또는 서로 상의해서 내린다고 기대하는 경우가 많음
  • 내가 겪은 상사들 중 이런 방식을 싫어했을 사람은 거의 없었음. 물론 하려는 일이 멍청하지 않다는 전제임
    다만 그 상사들은 모두 미국 문화에 깊이 젖어 있었음
  • 독립적 의사결정이 불복종으로 여겨진다면, 그런 관리자는 어떻게 위임을 하고 사회 전반에서 일은 어떻게 돌아가는지 궁금함
    효과적인 군사 의사결정조차 현장 부대가 본부에 매번 전화하지 않고 적응할 수 있어야 한다는 점에 크게 의존함
  • 상사가 실제로 삶이 있어서 주말에 일하지 않거나, 심지어 며칠·몇 주 쉬는 비미국 회사에서는 이 방식이 통하지 않을 수 있음

• 이걸 합리적인 기본값 만들기라고 부름
  모든 세부사항에 대해 사람들에게 결정을 요구하는 대신, 상황을 이해하고 있음을 보여주는 합리적인 기본값 묶음을 정하고 그대로 진행하겠다고 알리는 방식임
  이렇게 하면 신뢰가 쌓이고, 정말로 주의가 필요할 때 사람들이 더 잘 봐줌. 평소에 시간을 낭비하지 않는다는 걸 알기 때문임

  • “기본값”이라는 프레이밍이 좋음. 제안과 변경의 여지를 남겨줌

• 이 소통 방식은 좋지만 마감시한 부분은 별로임
  부하 직원이 내가 거부권을 행사할 수도 있는 일을 하고 있다면 알려주면 됨. 내가 더 많은 맥락을 알고 있어서 그 일이 시간 낭비이거나 우선순위가 아니라고 판단할 수 있기 때문임
  관리자에게 마감시한을 주는 건 이상하고, 묘하게 짜증나는 협박처럼 들림
  GitHub Action 같은 사소한 일은 팀원이 스스로 결정할 만큼 충분한 자율성을 줬다고 생각하고 싶음

  • “진행하면 안 되면 알려달라”처럼 노를 구하는 방식은 정말 좋음
    하지만 “이 날짜에 하겠습니다. 다른 말이 없으면요”를 붙이면 약간 공격적으로 느껴짐
    작업 시점만 언급하고 “그때쯤 끝낼 것 같습니다” 정도로 남겨도, 진행하지 않는 게 낫다고 판단할 수 있다는 여지를 줄 수 있음
    그래도 오래전부터 더 단호해지는 게 목표였음. 움츠러드는 것만으로는 한계가 있음
  • 언제 작업할지 말하지 않으면 상대가 노라고 했는지 아닌지 어떻게 알 수 있나?
    하루면 충분하다고 생각해서 진행했는데, 상대가 이틀 뒤에 답하면 이미 지시에 반하는 일을 한 상태가 됨
    날짜를 넣으면 피할 수 있음: “수요일(26일)에 빌드 시스템을 마이그레이션하겠습니다. 우려가 있으면 알려주세요”
  • 본문이 그걸 마감시한이라고 부른 게 손해였음
    예시를 읽고 나서야 이해됐는데, 실제로는 마감시한이 아니라 작업 예정일에 가까움
  • 자기 행동에 대한 마감시한은 예의일 수도 있음
    상대에게 통지 기간을 알려주고, 오래된 이메일을 나중에 읽는 사람이 지금도 관련 있는지 판단할 수 있게 해주기 때문임
  • 아직 아이디어일 뿐인 것에 마감시한을 박는 건 이상하고 공격적임
    보통 마감시한은 “이미 하기로 결정했고 승인이나 합의도 받았으니 이제 실행 사실을 알린다”는 의미로 쓰임

• “다르게 알려주지 않으면 이걸 하겠다”는 요령의 일부는 질문처럼 표현하지 않아 소통 비용을 줄이는 데 있음
  그러면 받는 사람이 답장을 쓸 필요가 없고, 나나 참조된 사람들도 추가 이메일을 읽지 않아도 됨
  그런 의미에서 GitHub나 Google Docs의 이모지 반응처럼, 읽고 동의했다는 표시로 엄지를 누를 수 있는 기능이 좋음. HN 일부에서는 이상하게 인기가 없지만, 매번 “좋습니다, 말 됩니다!” 같은 댓글을 쓰는 절차를 거치지 않아도 되는 가벼운 소통 방식임. 업보트와 비슷함