사고 원인 설명을 끊은 엔지니어링 SVP "무엇을 바꾸는지 말해달라"

"다시는 안 생기게 할까"를 아예 안 묻는 조직이면 어떻게 해야 하냐? 그런 데서 일하면 번아웃과 이직이 걱정될 것 같던데.

조직이 질문을 고르는 게 아니라 사람이 질문하는 거임. 네가 "이걸 어떻게 막을까"를 물으면 조직이 그 질문을 배운 거고, 이제 답하고 실행하는 법만 남음.

그런데 엔지니어링 부사장이 사고의 기술 세부를 모른다고? 그것 좀 이상하지 않아?

문제 해결 담당이 유능하면 관리자가 굳이 디테일을 알 필요는 없음. 근데 디렉터랑 SVP가 기술 세부 논의 중이면 걱정할 상황이고, 그건 기술 문제가 아니라 조직 문제임.

핵심은 맨 앞 인용 박스 하나고 나머지는 AI 말투로 포장한 거라더라. 요약하면 장애로 SVP 미팅이 잡혔고, SVP가 세부 얘기 전에 "이유는 다 합리적일 테니 무엇을 바꾸는지 말해봐"라고 한 게 끝임.

신뢰라는 설명이 좀 수상함. 완전히 신뢰한다면 "다음에 뭘 할지도" 안 물어봐야지. 반대로 불완전하게 믿는다면 세부를 모르고 그 계획이 적절한지 어떻게 판단해? 밑에서부터 쳐다보는 최고의 리더들을 떠올리면 이건 발이 땅에 안 닿은 거임.

리더도 팀에 책임을 묻는 자리라 계획은 알아야 하고, 자기 위에도 책임이 있으니 또 알아야 함.

세부를 말하다가 양쪽 다 몰랐던 사실이 튀어나오는 경우가 있거든. 세부 자체를 안 듣는 건 적신호라고 봐. "너무 길어서 요약하지" 정도만 예외로 치고.

위아래로 다 파악하고 있는 리더라면 잡초 수준 기술 디테일 재탕은 필요 없고, 큰 시스템 차원의 변화를 원하는 거임. 많은 엔지니어가 디테일에서 노는 게 문제라서.

전술이 아니라 전략을 맞추고 싶어 하는 거라 책임 분업으로는 오히려 맞다고 봄. 이견이 잘 안 보이는데?

신뢰는 영역이 한정돼 있음. 나도 초등학생 아들이 등교 준비하는 건 맡기는데 모닥불 피우는 건 안 맡김. "결과가 나빴지만 행동은 합리적이었다"고 믿는 것과 "너 없이도 다 해결할 거라"고 믿는 건 다른 말인데, trust 하나로 묶으면 안 됨.

SVP는 근본 원인 분석 능력은 이미 신뢰하는데, 실제로 뭔가 바꿀 권한이 있다고는 안 믿어서 계획을 확인하는 거임. 실행 가능성을 검증하는 절차라고 봐야 함.