개발자가 관리를 하기까지의 여정
테크니컬 리더, 제랄드 와인버그
이 글은 지금으로부터 7년 7개월 전인 2016년 3월 17일에 저장해둔 글을 그대로 발행하였다.
올해 독서모임을 운영하면서 최근에 테크니컬 리더를 다시 읽을 일이 있었다.
내가 이 책을 처음 읽은건 벌써 10년 전인 2013년이지만, 이 글은 그로부터 3년 뒤인 2016년에 작성했다. 3년 동안 나는 본업이 개발자에서 인하우스 컨설턴트로 바뀌었고, 주로 상대하는 사람들은 조직장이나 임원이었으며, 매니징에 대한 고민을 해야할만큼 시야도 이전보다 좀 더 넓어진 상태였다. 즉, 처음보다는 조금 더 성장한 시점에 같은 책을 또 읽으며 느낀 점을 적어놓은 것이라 그 자체로 스스로의 스냅샷이라는 의미가 있어서 기록으로 남겨둔다.
Gerald Weinberg가 쓴 Technical Leader라는 책을 보면 개발자가 관리자가 되기까지의 부딪혔던 상황, 성장해온 과정을 잘 볼 수 있다. 또, 각 장마다 생각하고 토론할만한 질문을 던져주고 있는 점 또한 인상깊다.
내가 일하는 곳은 이름을 말하면 다 아는 대기업, 제조업체로 시작한 곳이다. 굳이 우리 회사가 아니더라도 과거에 비해 지금은 다뤄야할 문제도 복잡해졌고, 규모도 커졌다는 것 쯤은 인정해야 한다. 그러한 문제에 대한 솔루션을 제공할 SW의 비중이 점차 커지면서, 관리자의 역할 또한 범위가 넓어진 것이 사실이다. 과거의 작은 조직에서 리더는 특정 문제를 잘 분석하고 그것을 풀어낼 방법을 찾아내는 역할이었다면, 현재 덩치가 커지고 풀어야하는 문제도 복잡, 다양한 조직에서 리더는 work managing과 더불어 people managing에도 관심을 쏟아야 한다. 혼자 일하는 것이 아니고 여러 명이 한 팀으로 일을 해야 하는데, 모두 함께 같은 목표를 보면서 달릴 수 있도록 목표를 명확히 설정해주는 역할과, 각 구성원들이 잘하고 있는지, 혹시 어떤 문제는 없는지, 일하는데 문제가 있어서 진행이 잘 안되고 있는지 그런 것들도 주의 깊게 살펴야하는 역할 또한 매우 중요한 일이다. 이런 일을 하는 것을 통틀어 관리자라고 부른다.
approach하는 것이 노련한 dev leader의 느낌
개발자가 techy한 것으로 빠지는 것과 사용자 입장을 조율하는 느낌
