정기 1:1을 안 한다면, 대화와 결정은 어떻게 이어질까?

세 가지 질문을 따로 해 봐요

첫째는 주기입니다. 매주 정해 둔 시간에 만날지, 필요할 때 약속할지의 문제예요. 둘째는 인원입니다. 두 사람이 말할지, 관련된 여러 사람이 함께 이야기할지의 문제입니다. 셋째는 결정입니다. 정보를 듣는 자리인지, 선택지를 검토하는 자리인지, 실행할 방안을 확정하는 자리인지 물어 보세요. 한 회의가 여러 역할을 할 수도 있지만, 세 질문의 답이 자동으로 같아지는 것은 아닙니다.

체스키가 걱정하는 결정의 경로

캡처 속 예시는 두 사람이 문제를 듣고 토론한 뒤 해법까지 정하는 상황입니다. 이 경우 다른 사람의 의견을 듣지 않았고, 다른 사람은 결정이 어떻게 나왔는지 모를 수 있다고 그는 지적해요. 핵심은 인원수 자체보다 필요한 의견이 들어왔는지, 결정의 이유가 전달됐는지에 있습니다.

예를 들어 제품의 출시 날짜를 두 사람이 정했다고 가정해 봅시다. 실제로 준비해야 하는 다른 팀의 조건을 빠뜨렸다면 결정에 필요한 정보가 부족할 수 있어요. 반대로 여러 사람이 회의에 있었어도 관련 자료를 검토하지 않았다면 정보가 충분했다고 단정할 수 없습니다. 이 예시는 탐구차차가 만든 가상 상황입니다.

같은 a16z에 실린 다른 관점

벤 호로위츠(Ben Horowitz)는 2012년 글에서 1:1을 직원의 정보와 생각이 조직 위로 전달되는 유용한 통로로 설명합니다. 직원이 의제를 이끌고, 관리자가 듣는 데 초점을 두는 방식이에요. 그는 1:1 없이도 좋은 소통 구조를 만들 수 있다고 인정하면서, 많은 경우 1:1이 그 구조의 일부가 될 수 있다고 봅니다. Ben Horowitz · One On One ↗

두 입장을 비교하면 ‘모든 회사에 같은 회의 형식’보다 중요한 정보가 필요한 사람에게 도착하는 구조가 공통 질문으로 떠오릅니다. 체스키의 발언만으로 어느 방식의 성과가 더 좋은지 측정할 수는 없어요. 이 포스트는 하나의 경영 관점이지, 정기 1:1의 효과를 비교한 실험 결과가 아닙니다.

민감한 대화가 있다는 것만으로 문제일까요?

체스키는 일대일로만 나눌 수 있는 민감한 대화가 많으면 그 이유를 돌아봐야 한다는 의견을 제시합니다. 다만 이 말만으로 ‘모든 대화를 다른 사람에게 공개하자’는 결론을 낼 수는 없습니다. 다른 사람이 알아야 하는 업무 맥락과, 개인에게 속하는 이야기는 성격이 다를 수 있어요.

비교 자료인 GitLab의 공식 핸드북은 정기 1:1을 권하고, 성과 피드백을 담는 의제 문서를 당사자와 관리자 사이의 비공개 문서로 다루도록 설명합니다. 다른 사람이 참관하는 1:1에서도 공유하기에 적절한 내용과 기밀 내용을 나누라고 해요. GitLab · 1:1 운영과 공유 범위 ↗

이는 GitLab의 운영 방식이며 Airbnb의 정책을 확인하는 자료는 아닙니다. 다만 업무의 투명성과 개인 대화의 보호를 함께 생각할 수 있는 비교 사례예요. ‘다른 사람도 알아야 한다’는 말에서, 다른 사람이 누구이고 무엇을 알아야 하는지를 구체적으로 적어 보세요.

가상 상황을 둘로 나누어 보기

직원이 개인적인 어려움을 설명하는 대화라면, 그 설명 자체를 팀 전체의 안건으로 만드는 것은 별개의 선택입니다. 반면 그 대화 중 업무 일정의 변경이 필요해졌다면, 관련된 사람들에게 변경될 일정과 이유 중 공유할 수 있는 내용을 전달하는 과정을 따로 생각할 수 있어요. 대화의 모든 내용을 옮기는 것과, 협업에 필요한 결정을 알리는 것은 같은 일이 아닙니다.

두 사람이 만든 해법도 곧바로 팀의 확정안이 아니라 검토할 제안으로 남길 수 있습니다. 관련자의 조건을 확인하고, 결정할 사람이 선택한 뒤 이유와 후속 행동을 기록하는 방식이 가능한지 질문해 보세요. 이는 탐구차차의 가상 설계이며 체스키가 인터뷰에서 설명한 절차를 재현한 것은 아닙니다.

공식을 반대하면서 다른 리더를 인정하기

마지막 대목에서 체스키는 사람을 뽑고 맡긴 뒤 세부 사항에 관여하지 않는 식의 경영 조언을 거부한다고 말합니다. 동시에 다른 훌륭한 리더들이 그 방식을 믿는다는 점도 인정해요. 강한 반대와 상대의 존재를 인정하는 문장이 함께 있다는 점을 읽어 보세요. 그가 젠슨 황의 회의 습관을 언급한 부분은 체스키의 주장으로 남겨 두며, 이 노트에서 별도로 확인한 NVIDIA의 운영 규칙으로 제시하지 않습니다.

읽고 나서 남길 질문

회의를 바꾸자는 제안을 만나면 ‘어떤 정보가 빠지고 있나’, ‘누가 의견을 보태야 하나’, ‘어떤 내용은 보호해야 하나’, ‘최종 결정과 이유를 누가 알게 되나’를 적어 보세요. 정기 일정을 유지할지 바꿀지는 이 질문들과 연결해 생각할 수 있습니다.