5P by GN⁺ | ★ favorite | 댓글 1개
  • 관리자와 리더의 모호한 요청은 작은 질문처럼 보여도 팀의 시간, 우선순위, 실행 방향을 크게 흔들 수 있음
  • “확인해달라”, “현대적으로 해야 한다” 같은 표현은 보고서, 슬라이드, 주말 작업, 대규모 업그레이드 같은 과도한 대응으로 번지기 쉬움
  • 요청자는 기대하는 시간 투자, 우선순위 영향, 기존 자료 확인인지 새 작업인지, 결과물을 어디에 쓸지까지 함께 말해야 함
  • 요청을 받은 사람도 노력 수준을 되묻고 모르는 점을 확인해야 하며, 리더가 바빠서 답하지 못할 것이라고 가정하면 안 됨
  • 앞단에서 약간 어색할 정도로 구체적으로 말하면 뒤에서 생길 혼란, 잘못된 작업, 비용 낭비를 크게 줄일 수 있음

작은 요청이 큰 작업으로 커지는 방식

  • 조직 안에서는 짧고 가벼워 보이는 요청이 예상보다 훨씬 큰 작업으로 커지는 일이 반복됨
  • 관리자가 “X를 해줄 수 있나?”라고 묻자, 직속 보고자가 예상보다 10배 많은 시간을 쓰고 관리자는 “그렇게까지 시간을 쓰길 원한 게 아니었다”고 반응하는 사례가 있음
  • 임원이 회의에서 “이것 좀 확인해줄래?”라고 짧게 말한 것이 24명이 4개 버전의 슬라이드 덱을 만들고 주말까지 일하는 상황으로 이어질 수 있음
    • 정작 회의에서는 임원이 첫 슬라이드의 첫 문장 요약만 보고 “전체 발표는 필요 없다”고 말할 수 있음
  • “변명 없이 현대적이어야 한다”는 말도 의미를 확인하지 않으면 대규모 기술 업그레이드로 해석될 수 있음
    • 실제 의도는 몇 년에 걸쳐 새 버전에서 API 문법을 갱신하는 수준일 수 있음
    • 그 사이 중요한 프로젝트 출시는 밀릴 수 있음

요청자가 먼저 정해야 할 것

  • 리더는 요청할 때 기대하는 시간 한도를 직접 말해야 함
    • 예: “20분 이상 쓰지 말고, 20분 뒤에 가진 것만 가져오라”
  • 우선순위에 어떤 영향을 줘야 하는지도 함께 정리해야 함
    • 예: “약 2주 걸릴 것으로 예상하며, 다른 주요 작업의 우선순위를 크게 낮추지 않아야 한다”
    • 실제 일정이 다르거나 다른 일과 충돌하면 즉시 연락하라고 말해야 함
  • 기존 자료만 확인하면 되는지, 새로 분석하거나 만들어야 하는지도 구분해야 함
    • 예: “이 주제에 대해 이미 가진 것이 있는지만 알려달라. 아직 생각해본 적이 없다면 그것만 알아도 된다”
  • 결과물의 사용처를 알려주면 상대가 노력 수준을 맞추기 쉬움
    • 예: 영업 잠재고객에게 보낼 답변, 다음 All Hands의 Q&A 대비, 다음 이사회 핵심 주제 등

요청받은 사람이 확인해야 할 것

  • 요청을 받은 사람은 명확화 질문을 해야 함
    • “여러 시간이 필요한 매우 철저한 결과를 기대하는가, 아니면 짧은 정리인가?”처럼 노력 수준을 확인해야 함
    • 질문한다고 어리석어 보이는 것이 아니라, 묻지 않고 완전히 잘못된 일을 하는 편이 더 위험함
  • 리더의 이메일이나 메신저를 고대 유물처럼 해석하며 시간을 쓰기보다, 요청한 리더에게 직접 확인하는 편이 낫음
  • 리더가 요청할 시간이 있다면 그 요청을 명확히 해줄 시간도 있음

댓글과 토론

Hacker News 의견들
  • 비기술 리더가 한두 단계를 건너뛰고, 명확화 질문이나 일정·산출물 정의를 할 경험이 있는 시니어 기술 인력 대신 주니어 기술 인력에게 직접 말하는 경우가 제일 싫음
    여러 캠페인 조직이나 정치 기술 조직에서 자주 봤던 패턴임

    • 이런 식의 위계 우회는 자주 보지만 잘 풀리는 경우가 없음
      주니어 기술 인력도 지휘 체계를 이해하고 있어서, 윗사람이 의도했든 아니든 그걸 깨면 혼란과 난장판이 생김
    • 리더는 아니지만, 내가 리더였다면 아마 이런 실수를 했을 것 같음
      실제 물리적인 작업을 하는 사람은 주니어 엔지니어인 경우가 많고, 상위 수준에서 보는 사람보다 특정 질문에는 더 잘 답할 수 있음
      굳이 전언 게임을 할 필요가 없지 않나 싶음
    • “명확화 질문을 할 줄 아는 경험”은 영업에서도 봤음
      경험 없는 벤더의 프로젝트 코디네이터, 코디네이터가 일을 처리해 주는 데 익숙한 벤더 기술자, 이 판이 처음인 고객이 만나면 꽤 큰 혼란이 생길 수 있음
  • “질문하지 않아서 완전히 엉뚱한 일을 하면 분명 멍청해 보인다”, “작업 중 명확화 질문에 답하기엔 상대가 너무 바쁠 거라고 절대 가정하지 말라”는 말에 대해, 원격으로 일하고 온라인 채팅도 안 되는 상황에서는 어떻게 하면 좋을지 궁금함
    대면이면 작고 빠르고 대충 정리된 질문을 많이 던지기 쉬운데, 이메일은 더 형식적이고 방해되는 느낌이라 무엇이 헷갈리는지 설명하고 예상 답변까지 미리 막느라 시간이 더 들어감
    화상 통화는 잡는 데 시간이 걸리고 부대비용도 큼
    고객 프로젝트에서는 Google Doc에 작은 질문이 생길 때마다 덧붙이고, 가끔 고객에게 문서를 확인해 달라고 알리거나 고객이 수정 알림을 구독하게 함
    고객은 답을 문서에 직접 쓰고, 작업이 진행되며 이 과정을 반복함
    장점은 고객이 한 번에 전부 답하지 않아도 되고, 알림이 줄고, 양쪽 모두 덜 형식적으로 써도 괜찮으며, 협업 느낌이 나고, 관련 부분 옆에 후속 질문을 붙이기 쉽고, 문서 댓글로 짧은 논의나 작은 작업 할당·추적도 가능하며, 다른 사람이 읽고 기여하기도 쉬움
    여기서는 잘 모르는 비기술 고객과의 계약 작업처럼 작은 질문이 많이 생기는 상황을 생각하고 있음

    • 먼저 이메일에 부여한 형식성과 방해된다는 느낌부터 고치는 게 좋겠음
      다른 사람들은 이메일에 그런 제약을 걸지 않음
      CEO에게 보내는 게 아니라면, 생각나는 대로 질문을 적고 바로 보내도 됨
      “아, 이 질문도 깜빡했네요. 감사합니다! $QUESTION”처럼 곧바로 두 번째 메일을 보내는 것도 두려워할 필요 없음
      https://twitter.com/TechEmails에서 고위 임원들의 이메일을 보면 대부분 아주 비격식적임
      Bill Gates와 Microsoft 임원들이 주고받은 오래된 메일 중 일부는 고등학생 문자보다 크게 더 정돈돼 있지도 않음
      상사의 상사의 상사의 상사에게 이모지를 넣으라는 뜻은 아니지만, 빠른 비격식 이메일이 경력의 끝이 되지는 않음
    • 전화나 화상 통화는 누군가의 자리로 걸어가서 이야기하는 것보다 객관적으로 더 큰 부담이거나 방해가 되지 않음
      많은 사람에게 더 크게 느껴지는 건 이해하지만, 양쪽 모두에게 실제로 더 성가신지는 모르겠음
      질문을 명확히 하려면 왕복 대화가 필요하다면 그렇게 하면 됨
      공유 문서 방식도 좋은 아이디어이고, 추가 장점이 두 가지 있음
      글로 쓰는 행위가 질문을 더 명확히 하는 추가 단계가 되고, 질문과 답변이 나중을 위해 문서화됨
      나중에 다시 적어야 하는 빠른 대화보다 둘 다 큰 이점임
    • “상사님, 이 요청을 이해하는 데 조금 어려움이 있는데 정확히 무엇을 원하시는지 조금 더 설명해 주실 수 있을까요? 특히 X, Y, Z가 궁금합니다. 감사합니다”처럼 보내면 됨
      인지 부담을 상대에게 넘기면 됨
    • 온라인 채팅이나 대면 접근이 가능해도 질문은 모아서 하는 편을 선호함
      하루에 여러 번 방해하는 것보다 한 번 방해하는 게 낫기 때문임
      새 이슈를 받으면 먼저 훑고, 무엇을 할지 계획하고, 잠재 문제나 충돌을 머릿속에서 파고들어 때로는 거대한 질문 목록을 만든 뒤, 누가 어떤 질문에 답할 가능성이 높은지 나누고 나서 온라인 대화를 시작함
    • 이건 원격 근무 문제라기보다 외부 고객과 일하는 문제에 더 가까워 보임
      회사 안에서는 보통 Slack 같은 사내 메신저로 짧은 5분 화상 통화를 요청하면 됨
      가까이 일하는 동료라면 예고 없이 바로 전화하기도 함
      외부 고객에게도 사전에 합의했다면 실제 전화번호나 화상 통화로 비슷하게 할 수 있음
      예를 들어 킥오프 회의에서 고객이 원하는 연락 빈도와, 어떤 질문은 즉시 소통해야 하고 어떤 질문은 느린 비동기 소통으로 충분한지 정해 두면 됨
  • 시간은 노력·실질·범위를 대변하는 지표로 매우 나쁨
    예를 들어 “20분만 살펴보고, 20분 뒤에 가진 걸 가져오라”는 요청을 보면, 사람마다 20분 안에 달성하는 양이 조금씩 다름
    설령 그 차이를 무시해도, 요청한 관리자가 그 20분의 노력에서 필요한 것을 얻는다는 보장은 없음
    애자일 환경에서 발견·조사 작업을 “스파이크”라고 부르고 “타임박스”를 주는 걸 자주 보는데, “그 시간 안에 원하는 것을 발견하지 못하면 어떻게 되나?”라고 물으면 대체로 좋은 답이 없음
    실제로는 필요한 것을 알아낼 때까지 타임박스가 늘어남
    그래서 시간은 노력이나 실질이나 범위의 나쁜 대리 지표임
    글의 뒤쪽 예시인 “여러 시간 들인 아주 철저한 걸 기대하나요, 아니면 빠른 정리면 되나요?”가 더 낫다고 봄
    이는 걸리는 시간이 아니라 작업 범위를 두고 말하기 때문임
    시간으로 재면 그 시간 안에 원하는 것을 얻을 보장이 없고, 결국 더 많은 시간을 붙이게 됨

    • 타임박스에 대해서는 동의하기 어려움
      “그 시간 안에 원하는 걸 발견하지 못하면?”에 대한 답은, 예상했던 시간 안에는 답을 발견할 수 없었다는 사실을 알게 되고 이 조사 작업에 필요한 노력에 대한 기대치를 조정한다는 것임
      관리자로서는 바로 그 정보가 알고 싶은 핵심 정보 중 하나임
    • 어떤 양의 시간을 쓰더라도 원하는 걸 얻는다는 보장은 없음
      그래서 프로젝트가 탈선해 쓰레기통으로 가는 걸 막으려면 무엇이든 타임박스가 필요함
      개인 작업이나 혼자 하는 작업에도 적용됨
      무엇이든 영원히 붙잡고 있을 수 있으니, 멈추는 지점을 강제로 만들고 피드백을 받거나 출시한 뒤 계속할 가치가 있는지 결정하는 편이 훨씬 나음
      여기서 작동하는 메커니즘은 사람들에게 우선순위를 강제하는 것임
      우선순위 판단을 아주 잘한다면 타임박스가 덜 필요할 수 있지만, 그 경우에도 타임박스가 없으면 필요한 수준보다 더 높은 품질까지 계속 작업하고 싶은 유혹을 견디기 어려울 수 있음
    • “그 시간 안에 원하는 걸 발견하지 못하면?”의 답은, 지금보다 더 많은 정보를 가지고 재평가한다는 것임
      이런 작업 패턴은 아는 것보다 모르는 것이 훨씬 많은 경우에 유용함
      목표는 야생 추측이 아니라 정보에 근거한 추측을 할 만큼 “아는 것”의 비중을 조금씩 늘리는 것임
      예를 들어 레거시 코드베이스에 버그가 있는데, 대체 시스템은 거의 완성됐고 두 달 뒤 출시 예정이라면 그 버그를 어떻게 처리할까
      무시할 수도 있고, 누군가에게 “무슨 수를 써서든 고쳐라”라고 할 수도 있지만 둘 다 좋지 않음
      그래서 “이 버그를 조사하되 한 시간 넘기지 말고, 어디까지 갔는지 알려 달라”고 함
      끝나고 나면 문제의 형태를 더 잘 알게 됨
      “문제 영역은 찾았지만 비즈니스 로직을 잘 아는 사람과 같이 풀어야 수정할 수 있다”고 돌아오면 적절한 자원을 붙이고 수정으로 이어가면 됨
      “코드의 이 부분이고 정리는 꽤 되어 있는데 아직 완전히 추적하지 못했다”고 하면, 거대한 일이 아닐 거라는 신뢰를 바탕으로 시간을 더 줄 수 있음
      반대로 “이 기괴한 스파게티 어딘가에 있고, 들여다보니 심연이 나를 되쳐다봐 등골이 서늘하고 벽의 그림들이 피눈물을 흘렸으니 다시 보내지 말아 달라”고 하면 더 추적할 가치가 없다는 게 분명해져서 내려놓을 수 있음
    • “빠른”도 결국 “짧은 시간 안에 끝나는”이라는 뜻이라, 지적한 문장 역시 시간을 이용해 일을 설명하고 있음
      원하는 것을 시간 안에 얻지 못하면 더 시간을 붙이는 경험을 했다는 건 믿지만, 보편적이지는 않음
      문제는 “원하는 것” 자체를 최종 목표로 취급하는 데 있음
      그래서 글에서도 “그게 왜 필요한지 말하라”고 함
      “최대 고객이 계약 갱신 전에 알아야 한다”는 “그냥 궁금했다”보다 더 많은 돈과 더 많은 직원 시간을 쓸 가치가 있음
      리더십 수준에서는 모든 이익을 좇을 수 없다는 걸 깨닫고, 비용 대비 효과가 가장 좋은 것에 전략적으로 집중해야 함
    • 업무를 적절히 위임하는 것은 관리자의 일임
      단순히 일에 사람을 붙이는 게 아니라, 적절한 기술을 가진 사람에게 적절한 일을 배정하는 것까지 포함됨
  • 스타트업 CEO가 뭔가를 요청했는데, 요청은 한두 문장 정도로 짧았던 것 같음
    그 결과 14쪽짜리 보고서를 만들었고, 몇 시간을 들였으며 대부분은 개인 시간에 했음
    CEO에게 보고서를 보냈지만 이후 아무 답도 없었고, 아무 일도 일어나지 않음
    이후 스스로 새 규칙을 만들었음
    요청의 비용은 그 요청을 전달하는 비용과 비례해야 함
    이제 비용이 큰 요청을 받으면 기다리고 지연시키고, 에스컬레이션을 요구함
    요청한 사람은 실사를 하고 더 윗선의 승인을 받아 그 비용을 치를 가치가 있음을 보여야 함
    헛소리 요청이면 다시는 들리지 않을 것이고, 가치 있는 요청이면 처리할 것이며, 그 노력도 적절한 가시성 없이 몰래 이루어지지 않는 부가 이점이 있음

    • 요청자에게 비용을 높이는 규칙이 두 가지 있음
      첫째, 첫 요청에는 절대 아무것도 하지 않음
      중요하다면 다시 요청할 것이고 그때 생각함
      둘째, 내가 야근해야 하면 상대도 야근해야 함
      상대가 야근하기 싫다면 그만큼 중요하지 않았던 것임
  • 엔지니어링에서 주니어부터 C레벨까지 여러 단계에 있어 보며 몇 가지를 배웠음
    첫째, 모두가 선의로 행동해야 함
    리더가 5초도 생각하지 않고 즉흥적으로 직속 부하에게 뭔가를 요청하는 걸 봤고, 반대로 직속 부하가 “인간 명령줄”처럼 정확한 문법이 주어져야만 움직이는 것도 봤음
    둘 다 되면 안 됨
    둘째, 관리자나 리더에게는 “일회성 요청”이 없음
    어떤 요청이든 다른 모든 일보다 암묵적 우선순위를 갖게 됨
    전체 시스템과 환경 안에서 움직여야 하며, 그렇지 않으면 팀에게 그런 선택을 떠넘기는 것임
    셋째, 요청을 받는 쪽이라면 요청자가 무엇이 필요한지 이해하도록 도와야 함
    암묵적 가정을 없애야 하고, 바로 그곳에 용이 숨어 있음
    소통하고, 알리고, 가르치고, 요청자가 원하는 것을 확정해 양쪽이 동의했는지 확인해야 함
    이런 일은 필요 없으면 시간을 낭비하지 않으려는 효율성 때문에 생기지만, 요청자와 수신자가 서로 도우려 하면 대체로 삶이 훨씬 견딜 만해짐

    • 선의로 행동하는 것은 정말 중요함
      어디까지 해도 되는지 한계를 밀어붙이는 리더와 팀과 선의의 관계를 만들려는 리더는 극명하게 다름
      생각 없는 요구를 계속하는 관리자는 최고의 직원들을 꾸준히 잃게 됨
      경험상 충분히 시간이 지나면 이런 리더 밑에는 주니어만 남는데, 경험 있는 사람들은 그 팀을 피하기 때문임
      “인간 명령줄” 팀원도 나쁜 믿음으로 움직이는 좋은 예임
      아주 작은 요청도 자신이 만든 양식이나 문서를 채워야 시작할 수 있다고 요구하고, 며칠 동안 논쟁하거나 비판하거나 회람한 뒤에야 작은 일을 생각하는 사람들과 일해 봤음
      질문을 정확히 던지는 수고를 아무도 하고 싶어 하지 않게 만들어 작은 요청에서 자신을 보호했다고 생각하지만, 시간이 지나면 같이 일하기 어려운 사람이라는 평판이 쌓임
      또 다른 변형은 모든 요청의 모호성을 악용하는 사람임
      무엇을 요구받았는지 대체로 알면서도 “교훈을 주겠다”며, 요청의 문자 그대로는 맞지만 모두가 필요하거나 원한 것이 아님을 아는 결과물을 내놓음
      우연이 아니게도 이런 게임을 하던 사람들 대부분은 지난 1년 사이 해고됐음
      사람들은 어느 정도 일은 하는 나쁜 동료를 한동안 참을 수 있지만, 감원할 때는 제거 대상 목록 맨 위에 오름
    • “일회성 요청은 없다”에 크게 동의함
      한 달 전 리더로서 내가 저지르던 실패를 깨달았음
      겉으로는 팀에 주인의식을 주려는 의도였고, 해야 할 여러 일을 쏟아부었지만 실제로는 “지금 이 순간 무엇을 해야 하는가”의 스트레스를 팀에게 떠넘기고 있었음
      “팀을 엄청나게 권한 위임하고 있어!”라고 생각하기 쉬운 교묘한 함정인데, 실제로는 팀을 스트레스받게 하고 집중력을 떨어뜨림
    • “ask”가 오래된 동사에서 현대적이고 유행하는 어색한 명사로 변한 게 흥미로움
      OED에 따르면 명사화는 호주 구어에서 시작됐다고 함
      https://www.oed.com/search/dictionary/?q=ask
      언어가 끊임없이 변하는 생물사회적 인지 산물이라 진짜 규칙은 없다는 걸 모두 알지만, 이미 좋은 동의어가 멀쩡히 있는데 이런 쓰임은 모래를 씹는 느낌처럼 거슬림
    • 한 번은 우리가 할 수 있는 두 가지 선택지를 제시하면서, 하나가 훨씬 오래 걸린다는 말은 하지 않았음
      그 정보가 결정을 좌우하지 않기를 바랐기 때문임
      나에게 쉬운 것이 아니라 비즈니스와 최종 사용자에게 가장 좋은 것을 해야 한다고 생각했음
      그런데 상대는 더 길고 어려운 쪽을 골랐고, 나중에 알고 보니 사실은 다른 쪽을 원했지만 그게 나에게 더 어려울 거라고 생각했음
      현실에서도 같은 일이 일어남
      새 주방 수납장을 만들 때 문 상단 레일 옵션 두 가지를 아내에게 줬는데, 하나가 더 어려웠지만 좋아하는 것을 고르길 바라는 마음에 말하지 않았음
      당연히 아내는 더 어려운 걸 골랐고, 알고 보니 더 쉬울 거라고 생각했으며 사실은 다른 쪽을 더 좋아했음
      그래서 항상 상대에게 모든 정보를 줘야 함
    • 두 번째 요점은 맞지만, 반드시 그래야 할 좋은 이유는 없음
      경영진이 던진 질문이 말이 안 된다고 왜 말할 수 없을까
      답은 물론 위계에 거스르지 않기 때문임
      하지만 이런 위계 순응은 실제로 비즈니스에 도움이 되지 않음
      더 쉽게 버릴 수 있어야 하는 가치처럼 보임
  • “아주 철저한 걸 기대하나요, 아니면 빠른 정리면 되나요?”라는 질문은 웃김
    엔지니어가 비엔지니어에게 어떤 일이 얼마나 걸리는지 솔직히 말하면, 비엔지니어는 충격받고 안 된다고 말할 것임
    “20분 이상 쓰지 말고, 20분 뒤 가진 걸 가져오라”는 요청은 미친 소리 같음
    20분 걸리는 일은 없음
    차라리 “이거 보지 말고 커피 마시고 와서 대충 추산해 달라”고 하는 편이 나음
    우리는 복잡한 작업을 하고 있고 생각할 시간이 필요함
    생각할 시간을 쓰지 않길 원한다면 그냥 묻지 않으면 됨
    문제의 일부는 상사에게 꺼지라고 말하고 싶지도 않고, 상사가 20분짜리라고 생각하는 일에 6시간 썼다고 말하고 싶지도 않다는 데 있음
    그래서 대신 다른 모든 일이 밀림
    좋은 엔지니어링 관리가 엔지니어를, 의도치 않게 기술자를 낚아챌 사람들에게서 최대한 멀리 두는 이유임

  • 약한 관리의 전형적 신호는 본인이 전체 함의를 이해하지 못하는 보고서를 요구하거나 작업을 배정하는 것임
    약한 엔지니어링의 전형적 신호는 그 요청에 “예”라고 답하는 것임
    약한 관리자가 사소하게 처리할 범위를 벗어난 일을 요청하면, 작업자는 기술적·사회적 맥락에 따라 세 가지 중 하나를 해야 함
    A) “그건 어떻게 해야 하나요?”라고 묻기
    관리자가 기술자이면서 자신의 기술적 무능을 보완하려고 모호하게 일을 던지는 경우에 통함
    그 헛소리를 그대로 돌려보내면, 자신이 요구하는 일의 범위와 메커니즘 현실을 마주하게 됨
    B) “그 일에는 X 자원이 듭니다. 기대치는 무엇인가요?”라고 알리기
    여기서 X는 막대한 인시, 돈, 구식 RuneScape GP 등 무엇이든 될 수 있음
    비기술 관리자에게 적합하고, A와 비슷하게 이것이 즉석에서 승인할 일이 아니라 정상 절차를 거쳐야 하는 큰 요청임을 마주하게 함
    C) “아니오”라고 말하기
    모든 조직이나 모든 사회적 맥락에서 가능하진 않지만, 고성과 조직은 이걸 가능하게 만듦
    고성과 엔지니어링 환경에서는 엔지니어링 조직이 말도 안 되는 헛일에 강한 거부권을 갖고, C레벨 상층에서만 뒤집을 수 있음
    이 거부권을 언제 어떻게 행사할지 아는 것도 엔지니어링이 키워야 할 중요한 기술임

    • 내가 “약한 조직”이라고 부를 만한 곳에서 겪은 현실은, 절반의 일이 사소할 것으로 기대되지만 실제로는 아무것도 사소하지 않고, 모두가 기존 배정 업무를 지연시키는데 상사는 이를 인정하지 않으며, 상사의 말투상 후속 논의에 진짜 관심이 없다는 게 분명해지는 식이었음
      그래서 그에 대해 무슨 말을 하든 자신을 문 쪽으로 밀어내는 결과가 될 수 있었음
  • “ask”를 명사로 쓰는 걸 볼 때마다 언어 감각이 간질거려서 찾아보니 이런 글이 있었음
    https://english.stackexchange.com/questions/4246/can-or-shou...
    비슷하게 거슬리는 사람에게 도움이 될 수 있음

    • 읽었을 때는 오타라고 생각했고, “task”를 뜻한 줄 알았음
  • 요청에 맥락이 빠져 있을 때가 가장 큰 시간 낭비 중 하나임
    필요한 사람에게만 알린다는 식으로 시간을 아끼려는 듯하지만, “왜”와 맥락은 좋은 해결책을 내는 데 정말 중요함
    그게 없으면 상대가 이미 무엇을 생각해 봤는지 알 수 없음
    예를 들어 “X 국가에서 오는 요청을 차단해야 한다”고 하면, 대부분의 방화벽 서비스로는 어렵지 않음
    하지만 왜 해야 하는가
    특정 국가에서 트래픽이 발생하지 않는다는 계약상 보장을 하려는 거라면, 누구나 VPN으로 2분 만에 국가 코드 감지를 우회할 수 있으니 그 방식은 통하지 않음

    • 전형적인 XY 문제처럼 들림
      사용자는 X를 하고 싶지만 방법을 모르고, Y가 통할 거라고 생각해 Y에 대한 도움을 요청하며, 다른 사람들은 Y가 이상해 보여 혼란스러워함
      https://xyproblem.info/
    • VPN과 국가 차단 문제는 엔지니어링 대 관리의 대표 예시이고 대부분 조직에 존재함
      이미 많은 사람이 그 언덕에서 죽었고, 그래도 구현됐음
      또 다른 희생자가 되지 않는 게 좋음
  • 결국 회사 문화와, 사람들이 시니어 리더에게 얼마나 편하게 반박할 수 있는지에 크게 달려 있음
    그 부담은 아래 사람들이 반박하기 편하게 만들어야 하는 시니어 리더에게 있음
    경험상 최고의 리더는 겸손하고 들으려는 태도를 보임
    다만 때로는 헛일을 하는 것도 직업의 일부임
    너무 많다면 당연히 다른 일을 찾으면 되지만, 항상 경영진을 의심하고 되묻는 사람이 되지는 않는 편이 좋음