- 개발자가 팀장이 되면 잃는 것은 코딩 시간이 아닙니다. 직접 만든 것이 작동할 때 오는 즉각적 피드백과 성취감입니다. 이 공백을 메우지 못하면 팀장 역할에서 소외감을 느끼거나 팀 업무에 직접 끼어들어 팀원의 성장을 막습니다.
- 캐밀 푸르니에는 기술 관리자 경로를 분석한 연구에서, 개발자 출신 첫 팀장이 가장 많이 저지르는 실수가 자신이 더 잘할 수 있는 기술 업무에 직접 개입하는 것이라고 했습니다. 성취감 공백을 코딩으로 채우려는 시도이지만 팀원의 자율성과 성장 기회를 빼앗습니다.
- 만들게 하는 성취감은 만드는 성취감과 다른 종류입니다. 팀원이 어려운 판단을 직접 내리고 결과가 좋았을 때 그 경로에 내 맥락이 있었다는 것이 팀장의 성취감입니다. 이 감각이 만들어지는 데는 평균 6개월에서 1년이 걸립니다.
처음 팀장이 됐을 때 무너지는 것
개발자가 팀장이 되고 두 달이 지나면 비슷한 증상이 나타납니다. 회의가 늘었고 코딩 시간은 줄었으며 성과 면담이 생겼습니다. 그런데 가장 힘든 것은 바쁨이 아닙니다. 퇴근할 때 내가 오늘 무엇을 만들었는지 말할 수 없다는 느낌입니다. 어제는 코드 두 기능을 완성했다고 말할 수 있었습니다. 오늘은 회의 세 개를 했고 메일을 처리했습니다. 무언가를 한 것 같은데 아무것도 만들지 않았습니다.
줄리 조는 2019년 '관리자의 탄생'에서 이 현상을 정리했습니다. 개인 기여자일 때 성취감은 즉각적이고 가시적입니다. 코드가 컴파일되고 기능이 작동합니다. 관리자가 되면 성과의 피드백 주기가 길어지고 내 기여가 팀 결과에 어떻게 연결됐는지가 불분명해집니다. 이 피드백 지연이 첫 팀장이 겪는 소외감의 핵심입니다.
이 소외감이 해결되지 않으면 두 가지 문제가 생깁니다. 팀장이 팀 업무에 직접 끼어들거나 자기 역할에서 의미를 찾지 못해 번아웃이 옵니다. 두 경우 모두 팀에는 부담이고 조직에는 손실입니다.
개발자 출신 팀장이 처음 저지르는 두 가지 실수
첫째는 기술 업무에 끼어드는 것입니다. 캐밀 푸르니에는 2017년 '관리자의 길'에서, 기술 팀장의 가장 흔한 실수가 자신이 기술적으로 더 잘할 수 있는 일에 직접 개입하는 것이라고 했습니다. 팀원이 설계한 방식보다 더 나은 방법이 보이면 직접 고치고 싶어집니다. 그 순간 팀원의 자율성이 줄어들고 성장 기회가 사라집니다. 팀장의 성취감은 올라가지만 팀은 수동적이 됩니다.
둘째는 관리 업무의 가치를 낮게 보는 것입니다. 회의, 면담, 채용, 목표 설정이 기술 업무보다 덜 중요하다는 인식이 팀장 초기에 자주 생깁니다. 이 인식이 있으면 관리 업무를 대충 처리하고 코딩으로 돌아가려는 경향이 강해집니다. 결과적으로 팀장도 개발자도 아닌 어중간한 역할이 됩니다.
두 실수 모두 근본 원인은 같습니다. 만드는 성취감이 사라진 자리를 아직 채우지 못한 것입니다.
팀장의 성취감이 오는 다른 경로
Ahn Partners 판단: 아래는 기술 조직 팀장 전환 과정을 여러 번 관찰한 결과입니다. 통제 실험이 아닌 실무 관찰입니다.
만들게 하는 성취감은 다른 신호에서 옵니다. 팀원이 어려운 기술 결정을 직접 내리고 결과가 좋았을 때 그 결정 경로에 내가 준 맥락이 있었다는 것. 팀이 6개월 전보다 더 빠르게 배포할 수 있게 됐을 때 그 환경을 내가 만들었다는 것. 이 신호는 개발자 시절의 즉각적 피드백과 달리 느리게 옵니다.
첫 팀장이 이 전환을 빠르게 하는 방법은 하나입니다. 팀원이 어떤 의사결정을 직접 내렸는지 매주 한 번씩 확인하는 것입니다. 그 결정이 좋았으면 왜 좋았는지 같이 확인하고 나빴으면 다음에 어떻게 다르게 결정할지를 같이 봅니다. 이 과정이 쌓이면 팀장은 팀의 판단 능력이 자라는 것을 보면서 성취감을 찾게 됩니다. 이 감각이 생기는 데는 평균 6개월에서 1년이 걸립니다.
점검 목록
- 이번 주에 팀원이 직접 내린 기술적 판단 중 내가 더 잘할 수 있었는데 개입하지 않은 것이 있는가
- 팀장으로서 이번 주에 만든 것이 무엇인지 퇴근 전에 구체적으로 말할 수 있는가
- 팀원의 역량이 3개월 전보다 나아졌다는 신호를 구체적으로 본 적이 있는가