위임 101: 무엇을 위임할지 파악하기
(leaddev.com)왜 할일 목록은 끝없이 늘어나기만 할까? 다음 연습을 10분간만 해보고 무엇을 위임할지 골라내보자.
## 1단계: 할일 목록 만들기 (a few minutes)
- 당신이 이제 그만했으면 하는 반복 업무가 무엇인가?
- 누군가가 팀에 새로 합류하거나 떠날 때마다 매번 수동으로 하는 일이 무엇인가?
- 다음주에 긴 휴가를 간다면, 돌아왔을 때 해결되어있는 걸 보면 행복해할만한 문제 딱 한가지가 무엇인가?
## 2단계: 할일 목록을 '당신만 할 수 있는 일'과 '위임 후보'로 쪼개기 (a couple of minutes)
"당신만 할 수 있는" 일을 구분하는 방법
- 매니저로서의 일: 비용 승인, 휴가 승인, 성과 리뷰, 오퍼레터 쓰기, 그 외 컨피덴셜한 정보를 다룰 수 있는 사람이 당신뿐일 때. (→ 당신의 매니저나 동료에게 부탁해볼 수도 있음)
- 권한과 관련된 일: 권한 부여 요청을 리뷰하고, 승인하고, 실제 부여할 수 있는 사람이 당신뿐일 때. (→ 승인자를 더 늘려 당신이 유일하지 않게 할 수도 있음)
- 컨텍스트와 관련된 일: 어떤 미팅에 혼자만 참여했는데 팀에게 공유할 정보가 있거나, 팀원의 성과에 아주 중요한 피드백을 혼자만 들었을 때. (→ 이 정보나 맥락을 문서화해둘 수도 있음)
- 데드라인과 관련된 일: 시급하게 처리해야 하는데 위임할 시간이 없을 때. (→ 데드라인은 대개 당신 생각보다 더 유연함. 일정을 늦출 수 있는지 한번 물어본다고 다치지 않는다)
당신만 할 수 있는 것처럼 보이지만 사실은 위임 가능한 일들
- 여러 사람이 참여한 미팅에서 나온 액션 아이템: 당신이 하겠다고 했던 일일지라도, 제시간에 못 끝낼 것 같으면 당신의 가용성을 재산정해보고 위임하라.
- 피드백: 누군가가 당신에게 피드백을 요청했다고 해서, 당신만이 피드백할 수 있는 건 아니다. 피드백해줄 새로운 사람을 피드백 요청자에게 적절하게 소개만 해준다면, 위임해도 괜찮다.
- 공지: 건강한 팀에서는 중요한 뉴스가 여러 사람으로부터 나올 수 있다. 의식적으로 노력해봐라.
- 당신이 직접 부탁받은 일: 직접 부탁받은 일이라도 위임은 가능하다. 다른 좋은 사람들도 그 일을 할 수 있다는 걸 알릴 기회가 될 수 있다.
## 3단계: 더 많은 아이템을 위임 후보 칼럼으로 옮기기
- 당신만 할 수 있는 일들을 우선순위대로 정렬해보고 5개만 남겨라.
- 그 5개만 당장 당신이 할 일이다. 나머지는 다 위임 후보로 옮겨버려라.
## 4단계: 위임 후보를 '노력'과 '효과'로 순위 매기기 (a couple of minutes 이하)
- (당신이 안 하더라도) 적은 노력을 들여서 할 수 있는 일인지, 그리고 수행했을 때 효과가 큰 일인지 구분해볼 것. 정답이 있는 문제가 아니니 정확하게 나누려고 하지 말고 첫번째 본능을 따라라.
- More impact, More effort: 위임함으로써 시간을 가장 많이 아낄 수 있는 일이다. 이것들 먼저 위임하라.
- More impact, Less effort: 당신도 쉽게 할 수 있겠지만, 팀원이 챌린지를 원한다면 위임할 수 있다.
- Less impact, More effort: 자동화를 고려하라.
- Less impact, Less effort: 목록에서 빼는 걸 고려하라.
## 5단계: 위임할 아이템 5개 고르기
- 위임 후보들을 우선순위로 정렬해서 5개만 골라서 위임하라.
- '큰 임팩트가 있는데 적당히 노력해야 하는 일'과, '적당한 임팩트가 있는데 적게 노력해도 되는 일' 중에서는 후자를 더 우선시하라.
## 다음 단계
- 이 연습이 힘들었다면, 당신만 힘든게 아님. 저자도 힘들고 다들 힘들었음.
- 개발자가 리더가 되면서 가장 어려운 일 중 하나가 위임이다. 대개 내가 스스로 하겠다고 한 일을 위임할 때 생기는 죄책감과 실망감 때문.
- 그러나 이 감정을 이겨낸다면 당신은 리더로서 더 중요한 일에 집중할 수 있음. 팀을 더 성공시키는 것.
- 이 연습을 한 달에 한번씩 해보고 패턴을 찾아보길 바란다. 처음에는 작게 시작하고, 편해질수록 더 많이 위임할 수 있음.
- 다음 글은 누구에게, 어떻게 성공적으로 위임하느냐이다. ← 아직 안 나옴
이것과 직접적인 연관까지는 아니지만 최근 고민하는것이
- 연차가 쌓일 수록 도메인 지식과 여러 프로젝트들에 대한 지식, 히스토리가 쌓인다
- 관련된 일들에 대한 인터럽트가 쌓인다
이네요. 이를 어떻게 극복해야할 지 고민입니다
(뻔한 얘기일 수도 있지만) 저는 인터럽트가 들어오면 그걸 처리해주는 것을 넘어서 가이드라인 문서 같은 산출물을 만들어 다음 유사한 인터럽트가 적어지게 노력하니까 조금 나아지더군요. 반복업무를 자동화하는 등의 일로 인터럽트의 원인을 제거하는 것도 가능한 것 같고요.