Escalation과 Delegation

소마에서 Escalation과 Delegation은 팀 리스크를 줄이는 기술임.

• 1차적으로는 팀원끼리 해결하는 것이 최우선임.
• 다만 팀 안에서 해결하려고 붙잡고만 있다가 일정과 판단이 늦어지면 Escalation이 필요함.
• Escalation은 팀을 건너뛰는 일이 아니라, 팀이 더 잘 판단하도록 필요한 사람에게 맥락을 공유하는 일임.

Escalation

Escalation은 위험 신호를 미루지 않고 필요한 사람에게 판단 가능한 맥락을 공유하는 것임.

• 문제를 떠넘기는 일이 아니라, 위험 신호를 미루지 않고 알리는 것임.
• 팀 안에서 먼저 해결을 시도하되, 일정이나 판단에 영향을 주기 시작하면 필요한 사람에게 빨리 공유해야 함.
• 혼자 붙잡고 있다가 공유가 늦어지면 작은 blocker가 팀 전체 리스크가 됨.
• 이때 필요한 것은 단순한 “도와주세요”가 아니라, 판단 가능한 맥락을 정리해서 공유하는 것임.

언제 알려야 할까

• 기술이나 구현이 막혔을 때
  • 하루 이상 같은 문제에 막히면 팀원에게 먼저 공유하는 편이 좋음.
  • 에러, 시도한 방법, 현재 가설을 같이 전달해야 함.
• 범위나 일정 리스크가 생겼을 때
  • 기능 범위가 일정 안에 어려워 보이면 멘토나 Expert에게 가져갈 수 있음.
  • 남길 기능과 뺄 기능 후보를 먼저 정리해야 함.
• 피드백 해석이 충돌할 때
  • 멘토 피드백이 서로 충돌하면 다음 멘토링에서 확인해야 함.
  • 피드백을 분류하고 팀 판단 초안을 만들어가야 함.
• 팀원 간 기대치가 어긋날 때
  • 사실, 영향, 필요한 결정을 분리해야 함.
  • 팀 안에서 먼저 맞춰보고, 필요하면 Expert와 상의할 수 있음.
• 행정이나 규정이 불확실할 때
  • 사무국에 확인해야 함.
  • 이때도 질문을 구체적으로 정리해서 보내는 편이 좋음.

어떻게 알려야 할까

Escalation을 할 때는 현재 상황, 지금까지 시도한 것, 막힌 지점, 일정에 미치는 영향, 팀이 생각한 선택지, 확인받고 싶은 내용을 최대한 포함하는 것이 좋음.

• “안 됨”보다 “여기까지 해봤고, 여기서 막혔고, 내일까지 안 풀리면 데모 범위를 줄여야 함”이 훨씬 좋은 공유임.
• 상대가 판단할 수 있는 Context와 상황을 같이 전달해야 함.

Delegation

Delegation은 결과를 책임질 수 있는 단위로 일을 맡기는 것임.

• 일을 넘기는 것이 아니라, 결과를 책임질 수 있는 단위로 맡기는 것임.
• 상대가 일을 끝낼 수 있도록 목표, 범위, 완료 기준, 필요한 권한을 같이 넘겨야 함.
• 작은 팀에서는 한 사람이 문서, 발표, 개발, 멘토 커뮤니케이션을 많이 떠안기 쉬움.
  • 처음에는 빠른 것 같지만, 시간이 지나면 병목이 됨.
• Delegation의 핵심은 “이거 해줘”가 아니라 “이 일을 끝냈다고 판단하는 기준이 무엇인지”를 맞추는 것임.

일을 맡길 때 같이 넘길 것

• 목표와 범위
  • 이 작업이 왜 필요한지, 어디까지 맡기는지 같이 알려줘야 함.
• 완료 기준
  • 어떤 상태가 되면 끝났다고 볼지 맞춰야 함.
• 참고할 문서와 맥락
  • 관련 문서, 이전 결정, 멘토 피드백을 같이 넘겨야 함.
• 결정 권한
  • 맡은 사람이 어디까지 직접 결정할 수 있는지 정해야 함.
• 공유 시점
  • 언제 중간 공유를 할지, 언제 결과를 보여줄지 정해야 함.
• 막혔을 때 물어볼 사람
  • 막혔을 때 누구에게 먼저 물어볼지 정해두면 병목이 줄어듦.

팀에서 정해야 할 기준

• 어떤 문제는 팀 안에서 해결할 것인가?
• 어떤 문제는 멘토에게 가져갈 것인가?
• 어떤 문제는 Expert에게 먼저 상의할 것인가?
• 어떤 문제는 사무국에 바로 확인할 것인가?
• 한 사람이 계속 같은 종류의 일을 떠안고 있지는 않은가?

이 기준이 있으면 문제를 늦게 발견하는 일이 줄어듦.