Hacker News • 3일 전

자세한 설명은 필요 없어요 — 무엇을 바꿀지가 중요합니다

IMP

6/10

핵심 요약

엔지니어링 SVP가 사고 원인 설명을 거절하며 '이미 여러분이 유능하다고 믿는다, 무엇을 바꿀지 이야기하자'고 말한 사례를 소개합니다. 저자는 '왜 이런 일이 일어났는가' 대신 '다음에 같은 실패가 덜 일어나려면 무엇을 바꿀 것인가'를 물어야 조직이 실제로 변화한다고 주장합니다. 좋은 설명은 수정이 아니며, 사람이 아닌 시스템을 바꾸는 포스트모템이 필요합니다.

번역된 본문

몇 달 전, 저는 엔지니어링 담당자와 그 상사(우리 엔지니어링 SVP)와의 긴급 회의에 끌려 들어갔다. 잘못될 일이 없어야 했던 일이 잘못되었다. 치명적이진 않았지만, 제가 SVP와 통화하게 될 만큼은 중요한 일이었다. 제가 어떻게 그 일이 발생했는지 설명하기 시작하자, 그들은 저를 끊으며 말했다. "마이클, 자세한 내용은 원하지 않아요." 그리고 이어서 말했다. 자세히 들어가면 이유가 완벽하게 합리적일 것이라는 걸 알고 있다. 당신이 무슨 일이 있었는지 설명하고, 나는 왜 모두가 그런 결정을 내렸는지 이해하게 되고, 당신에게 공감하게 될 것이다. 그러면 같은 일이 다시 일어난다. 그래서 자세한 내용을 원하지 않는다. 내가 원하는 건 우리가 무엇을 바꿀 것인가다. 처음에는 '자세한 내용을 원하지 않는다'는 말이 무시하는 것처럼 들렸다. 세부 사항을 이해하지 못하고 어떻게 합리적인 결정을 내릴 수 있단 말인가? 그러다 깨달았다. '자세한 내용을 원하지 않는다'는 것은 무시가 아니었다. 그 임원은 우리가 유능하다고 가정했고, '이미 당신들을 믿는다. 이제 다음에 무엇을 할지 이야기하자'고 말하고 있었던 것이다.

올바른 질문하기 문제가 발생한 후 대부분의 조직은 '왜 이런 일이 일어났는가?'라고 묻는다. 우리 모두 익숙한 질문이다. 우리는 타임라인을 작성하고, 결정을 재구성하고, 의존 관계를 설명한다. 그리고 마지막에 사고로 이어진 구체적인 사건들의 조합을 담은 문서를 넘긴다. 모두가 고개를 끄덕이며 '그럴 만했다'고 말하고, 각자 일상으로 돌아간다.

문제를 이해하는 것과 문제를 고치는 것은 다르다. 좋은 설명은 오히려 상황을 악화시킬 수 있다. 모두가 그 행동이 합리적이었다는데 동의하는 순간, 무언가를 바꿔야 한다는 긴박감이 사라진다. 사고가 비운이지만 이해할 수 있는 사건의 연쇄이고 누구의 잘못도 아닐 때, 아무것도 바뀌지 않는다. 그리고 6개월 뒤 같은 일이 다시 일어나면, 모두 어째서 또 여기까지 왔는지 의아해한다.

조직에 변화를 일으키려면 '왜 이런 일이 일어났는가?'를 묻지 마라. 대신 이렇게 물어라: 같은 유형의 실패가 다음에 덜 일어나도록 우리는 무엇을 바꾸고 있는가?

합리적인 사람들 그 SVP는 문제가 어떻게 발생했는지, 누가 관여했는지 이해하는 데 관심이 없었다. 관련자 모두 합리적으로 행동했다는 걸 설득받고 싶지도 않았다. 그건 기본 전제였다. 그들의 질문은 이것이 되었다: '합리적인 사람들이 이런 결과를 낳았다면, 무엇이 바뀌어야 하는가?'

이런 예시들을 생각해 보자.

'앨리스가 휴가 중이었고 밥은 Widgets 팀이 담당한다고 생각해서 놓쳤어요.' 그렇군요. 누군가 자리에 없을 때 소유권을 모호하지 않게 만들려면 어떻게 해야 할까?

'런치 3일 전에 요구사항이 바뀌었어요.' 물론이죠! 런치 기간 내에 요구사항이 바뀌면 어떻게 되나요?

'알림은 발생했지만, 당직 엔지니어는 그날 저녁 이미 가치 낮은 알림 20개를 처리한 상태였어요.' 이해합니다. 알림의 신호 대 잡음 비율을 어떻게 개선할 수 있을까요?

시스템을 바꾸는 데 집중하라. 바뀌어야 하는 것은 대개 사람이 아니다.

좋은 설명은 해결책이 아니다 포스트모템에 '지원팀을 더 일찍 참여시켜야 합니다', '소통을 더 잘해야 합니다', 그리고 개인적 최애인 '다음번엔 더 조심하겠습니다' 같은 문장이 가득하다면, 그건 희망 사항을 진척처럼 포장해 놓은 것이다. 시정 조치가 6개월 전의 대화를 사람들이 기억하는 데 의존한다면, 그건 시정 조치가 아니다. 조직의 구전 설화일 뿐이다.

사고 관련자 전원이 내일 회사를 떠나도 수정책이 여전히 작동하는가? 답이 '아니오'라면, 사람들은 뭔가를 배웠을지 몰라도 시스템은 여전히 실패할 운명이다. 포스트모템이 지속적인 변화를 일으키려면 이렇게 물어라: 같은 상황이 내일 벌어진다면, 무엇이 다른 결과를 낳을 것인가? 이 시점에서 결정을 강제하는 프로세스는 개선이다. 이런 유형의 실수를 원천적으로 막는 시스템은 더욱 강력하다.

프로세스를 위한 프로세스 '시스템이 이런 유형의 실수를 막는다'는 원칙을 지나치게 밀어붙일 수도 있다. 모든 실패가 새로운 프로세스를值得 있지는 않다. 그렇게 하면 아무도 일하고 싶어 하지 않는 환경을 만들게 된다. 때로는 예방의 비용이...

원문 보기

원문 보기 (영어)

A few months ago I was dragged into a call with my engineering counterpart and their boss (who happens to be our SVP of engineering). Something had gone wrong that shouldn't have. Nothing catastrophic, but important enough that I was now on a call with an SVP. I started to explain how it happened when they cut me off with "Michael, I don't want the details". They continued: I know that if we get into the details, the reasons will be perfectly reasonable. You'll explain what happened, I'll understand why everyone made the decisions they made, and I'll empathise with you. Then it'll happen again. So I don't want the details. I want to know what we're changing. At first I thought "I don't want the details" sounded dismissive. How can they make informed decisions without understanding the details? Then I realised that "I don't want the details" wasn't being dismissive. The executive assumed that we were competent, and was saying "I already believe you. Now let's talk about what happens next". Asking the right question After something goes wrong, most organizations ask "Why did this happen?" This is a question we're all familiar with answering. We write up timelines. We reconstruct decisions. We explain dependencies. At the end of it, we hand over a document that contains the specific combination of events that led to the incident. Everyone nods their head, says "that makes sense", and we all move on with our day. Understanding an issue is not the same as fixing it. A good explanation can make things worse. Once everyone agrees that the behaviour was reasonable, the urgency to change anything disappears. When an incident is an unfortunate but understandable sequence of events where no-one is at fault nothing changes. Then the same thing happens six months later, and everyone is left wondering how we landed here again. To drive change in your organization, don't ask "why did this happen?". Instead, ask: What are we changing so that the same class of failure is less likely next time? Reasonable people The SVP wasn't interested in understanding how the issue happened or who was involved. They didn't want to be convinced that everyone involved behaved reasonably. That's a baseline expectation. Their question became: “Given that reasonable people produced this outcome, what needs to change?” Consider these examples: "We missed it because Alice was on holiday and Bob thought the Widgets team owned it". Okay. How do we make ownership unambiguous when someone is unavailable? "The requirements changed three days before launch." Of course they did! What happens when requirements change inside the launch window? "The alert fired, but the on-call engineer had already dealt with twenty low-value alerts that evening". Makes sense. How do we improve the signal to noise ratio of our alerts? Focus on changing the system. The people are usually not what needs changing. A good explanation is not a fix If your postmortem is full of sentences like "we should involve support earlier" and "we need to communicate better", or my personal favourite, "we'll be more careful next time", you have a collection of hopes dressed up as progress. If your corrective action depends on people remembering a conversation from six months ago, you don't have a corrective action. You have organizational folklore. If everyone involved in the incident left the company tomorrow, would the fix still work? If the answer is no , the people may have learned something while the system is still destined to fail. For a postmortem to drive lasting change, ask: If the same situation happened tomorrow, what would cause a different outcome? A process that forces a decision at this point is an improvement. A system that prevents this class of mistake is stronger still. Process for process' sake You can take "the system prevents this class of mistake" too far. Not every failure deserves a new process. That's how you build environments that no-one wants to work in. Sometimes the cost of preventing recurrence is higher than the cost of occasionally accepting the failure, and that's ok. But you need to accept failure with your eyes open. "We are consciously accepting this risk" is very different from "we said we'd try harder and everyone felt better". Trust I still think about what the SVP said a lot. What sounded like impatience was a declaration of trust. They didn't need me to prove that the people involved were competent or well intentioned. They were willing to start there. If the investigation showed otherwise, we could deal with that separately. What they didn't want was for empathy to become the mechanism by which the organisation absolved itself of having to change. People are usually making the best decisions they can with the information, incentives and constraints around them. That's why fixing the people is often the wrong answer. Sometimes the most useful thing a leader can say is: I believe you. I don’t need the details. Tell me what we're changing.

엔지니어링 문화 포스트모템 조직 관리 장애 대응 리더십