개발 조직에서 '팀장'이 의미 있으려면...
대부분의 개발자들은 '팀장'을 그다지 좋아하지 않습니다.
분명, 개발 조직이 커지고, 사람이 늘어나고... 업무가 복잡해지고... 커뮤니케이션 비용이 증가하면서 대부분의 조직은 '팀장'자리를 만들고, 해당 롤을 부여하려고 한다.
처음에는 상징적인 의미의 '선임'자리를 부여하면서, 큰 의미가 없는 것처럼 하다가... 일이 진행되면서 보고체계나 의사소통 체계, 회의가 늘어나게 되면서 미묘한 팀장의 기류가 생성되거나, 강제적으로 팀장 자리를 부여하게 된다.
하지만, 대부분의 개발자들은 '팀장'의 자리를 그다지 좋아하지 않는다.
위에서 이야기한 것처럼 소통 비용의 해소나, 관리의 구분을 위한 자리를 위한 팀장의 배치는 개발자들에게는 매우 좋지 않은 구성이다. 특히, 팀장이 된 개발자들은 자신이 개발에만 몰두하는 시간을 지켜야 하는데, 직원들과의 소통 비용이나 보고를 위한 시간들에 시간을 정하게 되고, 이는 곳 스트레스로 바뀌며 업무에 영향을 주게 됩니다.
사실상, 급여가 그렇게 오르는 것도 아니고, 회의비나 팀장의 직급에 따른 약간의 비용 증가는 개발자들에게는 '혜택'이 아니라, '추가된 일'일뿐입니다.
그렇다면, 개발 조직이 커지고, 팀장이나 파트의 구분이 필요한 경우에는 어떻게 하는 것이 좋을까요? 그것은 다음의 전제조건을 갖추는 형태로 진행하는 것이 바람직합니다.
첫째. 개발 일정을 개발자 스스로 정할 수 있게 하는 암묵적인 룰의 활성화
둘째. 각 직군별, 업무별 코드리뷰와 정보 교환을 위한 공식적인 일정의 배분
셋째. 해당 개발 조직의 급여 수준이 업계 표준 이상이거나 최상위 조건을 갖추는 상태
넷째. 팀장의 업무를 수행할 수 있을 만한 시간적인 배분과 스트레스 해소를 위한 인센티브나 혜택
그리고,
가장 중요한 다섯 번째.
과연, 팀장 직함이나 롤을 행할 사람이 '개발자 관리'업무를 스스로 할 수 있는지에 대해서 판단하고, 그 역할에 대한 의미와 책임을 가질 것인가에 대한 명확한 다짐이 필요합니다.
그리고, 여섯 번째.
조직은 '관리'업무의 세계로 입문한 '팀장'에 대한 처우나 대우, 향후 방향성에 대해서 충분하게 커버가 가능한 조직의 구성이나 HR, 인사방침 등을 가지고 있어야 합니다.
마지막, 일곱 번째.
단지, 개발 능력이 좋다고 팀장을 시키면 안 됩니다. 개발 능력이 좋은 것과 '사람 관리'를 하는 것은 전혀 다른 스킬입니다. 일정을 다루고, 특정 미션에 대한 목표의식이나 PM의 형태와 혼동을 하면 안 됩니다.
개발업무의 중복성과 파편화, 팀의 세분화에 따른 알력 다툼이나 사람들 간의 의사소통에 의한 스트레스 등을 받을 수 있어야 하며, '착하다'는 평가를 받는 사람이 팀장을 하면 안 됩니다. 그들 대부분 내부적으로 스트레스를 만들다가, 포기하는 경우가 정말 많습니다.
이렇게 이야기한 조건은 정말 기본적인 조건입니다.
그리고, 제발 좀 '개발 능력'과 '관리능력'을 혼동하시면 안 됩니다. 나이의 많고, 적음도 문제가 아닙니다.
개발자의 관리 스킬은 또 다른 미지의 영역입니다.
개발자들에게 '팀장'을 만들고 시키려는 조직은 깨달아야 합니다. 개발자에 대한 업무태도, 업무방식, 그들의 습관과 세계관에 대한 이해를 얼마나 하고 있는지에 대해서...
