13. 리더의 권한 위임
난 모르겠고의 마인드가 아니다
대부분의 수석엔지니어 리더들이 정신없이 많은 업무에 시달린다.
개발업무부터 시작해서, 긴급이슈, 팀원관리, 그리고 수많은 수명업무들까지
일반적으로 위임의 대상은, 중요성과 시급성을 판단 기준으로 놓고
긴급하고 중요한 1사분면 업무 외에는, 코칭을 하며 위임하는 것을 원칙으로 한다고 한다.
하지만 중요하면서 시급한 업무를 계속 리더가 결정하다 보면 리더만 바쁜 순환 굴레는 멈추지 않는다.
좋은 위임이란 무엇일까?
처음하는 업무는 리더가 같이 한다
해당 원칙에는 몇가지 조건이 있다.
무조건 처음 하는 업무를 같이 진행하라는 뜻이 아니다. 팀원의 담당역할, 업무가 명확하다면 처음하는 업무도 해당 팀원이 담당해서 결정할 수 있게끔 위임한다.
여기서 리더가 같이 하는 업무는, 팀원 모두가 '처음 해 보는 중요한 업무'여야 한다.
어떤 걸 확인해야 할지, 어떤 방향으로 나아가야 할지 아무도 길을 터놓지 않은 업무들.
이런 업무 중 중요하면서 시급한 업무는 리더가 같이 하고 빨리 길을 터주는 편이 낫다.
우리팀 업무가 명확해졌으면 그 이후에 생기는 모든 후속 업무는 위임한다.
업무가 어느정도 윤곽이 보이고, 업무별로 담당자가 보이기 시작하면 그 때부터는 위임한다.
위임한 팀원에게 권한을 준다
업무는 위임 해놓고, 권한 위임이 없이 리더가 마이크로매니징으로 모든 업무를 간섭하면 좋은 위임이 아니다.
위임받은 팀원(A)에게 모든 권한을 주고, 다른 팀원들도 해당 위임 받은 팀원을 따르게 해야 한다.
A가 업무 진행을 위해 회의 소집을 했는데 잘 되지 않는다면, 보이지 않게 다른 팀원들을 설득해야 한다.
의식적으로 내가 말 한마디 하는 것도 조심해야 한다, 그것이 월권일 수 있기 때문이다.
때로는 무관심한게 아닌가 싶을 정도로 위임한 업무를 신경쓰지 않아야 한다.
셀프피드백을 권장한다
내가 먼저 위임한 업무진행 상황을 챙기지 않도록 한다. 팀원에게 피드백을 스스로 하도록 육성해야 한다.
개인차가 정말 심한 편인데 맡겨놨더니 일은 처리 잘 됐지만, 중간에 피드백이 하나도 없는 경우가 있다. 팀원을 탓하지 말고, 시스템을 동원하자. 업무협업시스템을 통해서 셀프피드백으로 업데이트를 하게 하면 된다.
리더가 나서서 어설픈 피드백은 하지 않도록 한다. 실제로 업무진행한 팀원이 제일 잘 알기 때문이기도 하고, 팀원들끼리 잘 논의해둔 내용을 망칠 위험도 있다.
정 기술적인 피드백이 필요할 때는, 개발이나 해결의 방향이 아니라 지금은 어떤 기술적인 방향을 고민해야 할지를 피드백한다. 예를 들면 A해결법이냐 B해결법이냐가 아니라, 해결법을 생각할 때인지 아니면 원인분석을 조금 더 철저하게 해야 할 때인지를 결정하는데 도움을 주도록 한다.
인사 관련 업무는 위임하지 않는다
인사 관련 행정 취합을 하거나, 고과평가를 할 때 TL별로 뿌려서 취합하는 일들이 있는데
이런 업무들은 위임하지 않는다. 인사권을 가진 리더만이 할 일이다. 이런 업무를 위임하기 시작하면, 팀원들간의 보이지 않는 위계질서가 생기고 특정 팀원을 편애한다는 목소리가 나오게 된다. 이런 일은 리더인 수석엔지니어가 처리하도록 한다.
오늘도 쏟아지는 메일, 메신저 사이에서
직접 처리하고야 마는 업무, 위임을 하기 위해 설명하는데 더 시간을 쓴 업무, 위임을 했는데 처리가 되지 않고 있는 업무, 스스로도 놀라울만큼 위임 했는데 잘 진행된 업무 등등 여러 업무 산더미에서 하루를 보냈다.
한가지 확실한 것은, 위임을 하는 목적은 내가 편하기 위해서가 아니라
수석엔지니어의 진짜노동을 할 시간을 확보하기 위해서라는 점이다. 그리고 다음 리더를 키우기 위함이다.
긴급이슈가 매일 터지는 개발팀 속에서 항상 원칙을 지켜가며 위임할 수는 없지만,
그래도 팀원 육성이나 팀 문화에 도움이 되는 방향으로 위임에 대해서는 늘 고민하는 수석엔지니어이고 싶다.
