세부 내용보다 다음에 바꿀 것을 묻는 리더

AI 요약

엔지니어링 조직에서 예상하지 못한 문제가 발생해 글쓴이가 엔지니어링 수석 부사장(SVP)과 회의하게 됩니다. 글쓴이가 발생 경위를 설명하려 하자 SVP는 “세부 내용은 듣고 싶지 않습니다. 무엇을 바꿀지 알고 싶습니다”라고 말합니다. 처음에는 무시당한 듯 느꼈지만, 글쓴이는 이를 구성원이 합리적으로 판단했다는 신뢰를 전제로 한 질문으로 받아들입니다. 이제 중요한 것은 누가 잘못했는지 변론하는 일이 아니라, 다음에는 무엇이 달라질지 논의하는 일이라는 뜻입니다.

원인 설명에 머물지 않기

사고 뒤 조직은 흔히 “왜 이런 일이 생겼나?”를 묻습니다. 타임라인을 만들고, 당시 판단과 의존 관계를 되짚어 사건이 발생한 조합을 설명합니다. 설명에 모두가 수긍하면 일이 정리된 듯 느껴지지만, 문제가 이해됐다고 해결된 것은 아닙니다. 당시 행동이 합리적이었다는 데 동의한 뒤 바꿀 것이 없어지면, 몇 달 뒤 비슷한 사고가 반복될 수 있습니다.

글쓴이는 질문을 “같은 유형의 실패가 다음에 덜 일어나도록 무엇을 바꿀 것인가?”로 옮기자고 제안합니다. 휴가 중인 담당자와 소유 팀을 서로 다르게 이해해 문제를 놓쳤다면, 담당자가 부재할 때도 소유권이 분명하도록 바꿔야 합니다. 출시 사흘 전 요구사항이 바뀌었다면 출시 직전 변경을 어떻게 처리할지 정해야 합니다. 당직 엔지니어가 이미 가치 낮은 알림 스무 건을 처리한 뒤 중요한 알림을 놓쳤다면, 알림의 신호 대 잡음비를 높여야 합니다. 사람을 탓하기보다 사람이 일하는 환경과 체계를 고치는 접근입니다.

실행되는 시정 조치

“지원팀을 더 일찍 참여시키자”, “소통을 더 잘하자”, “다음엔 더 주의하자” 같은 문장은 개선책처럼 보이지만, 실행을 보장하지 않습니다. 반년 전 대화를 기억해야만 작동하는 조치는 시정 조치라기보다 조직에 떠도는 이야기입니다. 사고에 관여한 사람이 모두 내일 회사를 떠나도 해결책이 작동할지 물어보라고 글쓴이는 말합니다. 그렇지 않다면 사람은 배웠어도 시스템은 여전히 같은 방식으로 실패할 수 있습니다.

같은 상황이 내일 다시 생기면 무엇이 다른 결과를 만들지 물어야 합니다. 특정 지점에서 결정을 강제하는 절차도 개선이지만, 같은 종류의 실수를 막는 시스템이 더 강한 방안입니다. 다만 모든 실패마다 새 절차를 추가하면 누구도 일하고 싶지 않은 조직이 될 수 있습니다. 재발 방지 비용이 간헐적인 실패를 감수하는 비용보다 크다면 위험을 받아들일 수도 있습니다. 다만 “이번 위험은 의식적으로 감수한다”는 판단과 “다음엔 더 조심하자”고 말하고 넘어가는 일은 구분해야 합니다.

글쓴이는 SVP의 말을 신뢰의 표현으로 해석합니다. 사람들은 주어진 정보와 유인, 제약 속에서 대체로 최선의 판단을 내리므로 사람 자체를 고치는 일이 답인 경우는 드뭅니다. 글쓴이가 우려하는 것은 공감과 이해가 조직이 바뀌지 않아도 된다는 면죄부가 되는 상황입니다. 리더는 구성원이 유능하다는 믿음에서 출발하되, 재발을 막기 위해 무엇을 바꿀지 물어야 한다는 주장입니다.

Hacker News 반응

• @jameshart — 조직은 질문을 할지 말지를 선택하는 주체가 아닙니다. 사람이 선택합니다. 조직의 행동은 구성원이 한 행동을 모은 결과입니다. 구성원으로서 “이 일이 다시 일어나지 않게 하려면 어떻게 해야 할까요?”라고 묻는다면, 조직은 그 질문을 배우기 시작한 셈입니다. 이제 답하고 실행하는 법을 익히면 됩니다.
• @FartyMcFarter — 이 접근에는 뭔가 맞지 않는 점이 있습니다. 완전히 신뢰한다면 다음에 무엇을 할지도 맡기면 됩니다. 리더십이 필요하지 않습니다. 완전히 신뢰하지 않는다면 세부 내용을 모른 채 다음 계획이 적절한지 어떻게 판단하나요? 리더가 현장을 모르는 상황을 강화하는 것 아닌가요? 제가 만난 좋은 리더는 위에서 아래로뿐 아니라 아래에서 위로도 상황을 살폈습니다.
  • @drfloyd51 — 리더는 엔지니어에게 책임을 묻습니다. 그러려면 계획을 알아야 합니다. 리더도 책임을 지므로 역시 계획을 알아야 합니다.
• @garciasn — 아래에서 위까지 상황을 파악하고 있다면, 잡초 수준의 기술적 세부 내용을 다시 들을 필요는 없습니다. 무엇을 바꿀지 알아야 합니다. 많은 엔지니어가 잘하는 사소한 부분이 아니라 큰 시스템 차원의 변화여야 합니다.
  • @FartyMcFarter — 제가 말한 것은 리더가 모든 논의에 필요한 내용을 항상 안다는 뜻이 아닙니다. 낮은 수준의 세부 내용이 중요할 때 이를 파고들 의지와 능력이 있다는 뜻입니다. 문제의 세부 내용을 모르면 엔지니어가 제안한 큰 변화가 적절하고 충분한지 어떻게 판단하나요?
• @insanetake — 제가 참여한 모든 사후 분석에는 사건 타임라인, 영향, ‘5 Whys’ 방식의 원인 분석, 실행 항목이 있었습니다. 실행 항목 없이 끝나는 사후 분석은 본 적이 없습니다.
  • @mooreds — 그 실행 항목은 보통 실제로 이행되나요?
  • @4lx87 — 실행 항목에 담당자를 지정하고 실제로 처리하는 일이 중요합니다. 사후 분석을 하는 척만 하고 리더십이 후속 조치를 맡거나 처리하지 않는 회의도 많이 봤습니다. 많은 조직이 신뢰성에 입으로만 투자합니다.
• @juancn — 지속적인 개선 절차는 규칙과 알림을 계속 더하는 방향으로 흐르기 쉽습니다. 기존 절차를 다시 살펴 무엇을 없애거나 교체할지도 봐야 합니다. 또 ‘근본 원인’이라는 말은 여러 요인이 얽힌 문제에서도 단일 원인을 찾게 만듭니다. 저는 근본 원인 분석(RCA)보다 기여 요인 분석(CFA)이 더 나은 관점을 준다고 봅니다.
• @esafak — 저는 그렇게 말하지 않았을 겁니다. 세부 내용을 듣고 무엇이 빠졌는지 찾겠습니다. 거의 언제나 뭔가 다른 조치를 할 수 있었기 때문입니다. 그다음에는 위험을 얼마나 줄이기 위해 얼마를 지불할지 판단해야 합니다.
• @cryptonector — 실제 영향과 잠재적 영향을 알아야 자원은 한정돼 있고 기회비용도 있다는 점을 고려해 약속할 조치의 비용을 따질 수 있습니다. 경영진에게 영향과 약속한 조치만 요약해 전달할 수는 있습니다. 그래도 사후 분석 과정 전체를 거쳐야 하며, 누군가는 모든 세부 내용을 알아야 합니다.
• @wolfy1993 — 제가 약국에서 경험한 의료 분야의 사고 대응도 비슷합니다. 오류가 발생하면 원인을 찾지만, 대부분은 재발을 막으려면 환경이나 절차를 바꿔야 합니다. 사람은 시간에 따라 실수할 수 있지만 시스템과 점검 절차는 통제할 수 있습니다. 비난하지 않는 문화는 실수를 드러내고 배우며, 무엇보다 재발을 막는 데 효과적입니다.
• @dualvariable — 이 글은 일을 하는 직원에게 직접 변화를 실행할 권한이 있다고 전제하는 것 같습니다. 실제로 그런 경우가 얼마나 되나요? 요구사항이 출시 사흘 전에 바뀌었다면, “앞으로 마케팅 부사장의 막판 필수 요구사항을 무시하겠습니다”라고 답하라는 건가요?
• @mfbx9da4 — 무슨 일이든 항상 바꿔야 한다는 전제가 스타트업을 반사적으로 대응하게 만들고, 끝없는 관료주의를 쌓게 합니다.
• @sholladay — 직원은 다른 사람의 영역을 침범하거나 선을 넘었다고 여겨질까 봐 변화를 주저할 수 있습니다. 현장 직원이 더 나은 작업 방식을 알아도 “내 일이 아니다” 또는 “내 직급에서 할 일이 아니다”라고 생각할 수 있습니다. 때로는 “그래, 그렇게 해도 됩니다”라는 권한 부여만으로 충분합니다.

원문: michaelheap.com / 번역·요약: Trawling