목차12개 항목
출처와 참고
「개발자에서 개발팀장이 되기까지 겪은 5가지 실수」(Patrick Kua의 「Techie to Tech Lead」 번역), 「초보 개발 팀장의 1년 회고 - 좋은 팀장이 되기 위한 노력들」(2020.04)을 바탕으로 재구성한 노트다. 매니저 자리에서 달라지는 것은 Sofia의 「The Truth About Being a Manager」(2026.06)로 보강했다.
역할이 바뀌면 성공 기준이 바뀐다
개발자의 성과는 내가 만든 것으로 잰다. 리더의 성과는 팀이 만든 가치로 잰다. 리더가 된 뒤에도 개인 산출물로 자신을 평가하면, 직접 코딩을 놓지 못하고 팀의 병목이 된다.
| 구분 | 개발자 | 테크 리드·팀장 |
|---|---|---|
| 성과 | 내가 짠 코드, 해결한 이슈 | 팀 전체의 산출과 성장 |
| 주로 보는 신호 | 빌드 성공, 테스트, 배포 | 이해도, 동의와 저항, 업무 부담, 소통 구조 |
| 핵심 역량 | 기술 깊이 | 영향력, 설득, 코칭, 이해관계자 관리, 전략적 사고 |
| 시간 쓰는 곳 | 구현 | 장애물 제거, 의사결정, 사람 |
기술은 리더십의 뿌리이지만 리더십 자체는 아니다. 기술 역량과 리더 역량은 따로 길러야 한다.
새 리더가 흔히 하는 다섯 가지 실수
| 실수 | 결과 | 바꿀 것 |
|---|---|---|
| 1. 기술 실력이 리더 자격이라고 믿는다 | 팀원을 경쟁자로 보고 불신과 우유부단이 생긴다 | 팀원을 협력자이자 잠재적 후계자로 본다 |
| 2. 기술만 계속 깊게 판다 | 설득·코칭 같은 넓은 역량이 자라지 않는다 | 익숙하지 않은 역량을 의식적으로 연습한다 |
| 3. 여전히 생산자로 일한다 | 과로하고, 리더가 팀의 병목이 된다 | 팀원이 집중하도록 방해 요소를 치운다 |
| 4. 모든 것을 알고 통제하려 한다 | 결정이 몰리고 틀린 정보를 퍼뜨린다 | 위임하고, 모르면 모른다고 말한다. 멘토링·팀 코드 리뷰 같은 구조로 푼다 |
| 5. 역할이 바뀐 신호를 못 읽는다 | 사람 문제를 늦게 알아챈다 | 기술 지표 대신 사람의 신호를 본다. 원인 해석은 신중하게 한다 |
팀을 키우는 실천
1:1 면담을 고정 일정으로
- 주 또는 월 단위로 30~60분을 달력에 고정한다. 바쁠 때 가장 먼저 밀리기 때문이다.
- 감정 상태, 고민, 커리어 방향, 강점을 듣는다. 업무 진행 점검은 다른 자리에서 한다.
- 기록을 남기고 질문을 템플릿으로 만든다. 쌓인 기록으로 사람마다 고민이 어떻게 바뀌는지 볼 수 있다.
사람에 맞춰 일을 나눈다
- 팀원이 집중하고 싶은 영역과 강점을 업무 배정에 최대한 반영한다.
- 빨리 크는 사람에게는 도전 과제를, 천천히 크는 사람에게는 작은 성공을 주는 과제를 준다.
- 정답을 바로 주지 않고 스스로 생각할 질문을 던져 문제 해결력을 키운다.
심리적 안전감과 피드백
- 질문과 반론이 부끄러운 일이 아니라는 신호를 꾸준히 보낸다. 정기 회고로 자유로운 피드백 통로를 연다.
- 피드백은 사실에 근거하고 대안을 함께 준다. 듣기 좋은 말만 하는 것은 성장을 막는다.
- 판단 기준과 말을 일관되게 유지한다. 방향이 자주 바뀌면 신뢰가 깎인다. 비교나 도덕적 평가가 담긴 말은 피한다.
목표·규칙·문서
- 분기·연 단위 목표와 진행을 잴 지표를 정하고 주기적으로 본다.
- 회의 방식, 코드 리뷰 가이드, 공용 도구를 문서로 남겨 새 팀원이 빨리 적응하게 한다.
- 성과는 가능한 한 수치로 남기고, 수치화가 어려운 기여는 조직에 준 영향을 설명하는 자료로 보완한다.
리더 자신부터 점검한다
자신의 스트레스 요인, 능률이 높은 시간, 원하는 커리어를 알아야 팀원의 이야기를 여유 있게 들을 수 있다.
매니저 자리에서 달라지는 것
엔지니어링 매니저는 권한과 책임을 함께 진다. 그래서 같은 사람이라도 팀과의 관계, 말의 무게, 일하는 시간의 단위가 바뀐다.
| 달라지는 것 | 무슨 일이 생기나 | 대응 |
|---|---|---|
| 팀과의 거리 | 연봉 협상·어려운 결정 뒤로 팀원 사이의 대화에서 빠지게 된다 | 자연스러운 변화로 받아들인다. 속을 털어놓을 동료 매니저를 최소 한 명 둔다 |
| 말의 무게 | 가벼운 한마디가 지시로 들려 혼란과 걱정을 만든다 | 말을 줄이고, 의견인지 결정인지 밝히고, 다른 사람이 먼저 말하게 한다 |
| 공유할 수 없는 정보 | 조직 개편, 성과 문제, 예산 삭감, 개인 사정을 알고도 말할 수 없다 | 질문에 신중하게 답하고 감정을 드러내지 않는다 |
| 동의하지 않는 결정 | 위에서 내린 결정을 팀에 설명하고 설득해야 한다 | 팀 앞에서 불만을 털어놓지 않는다. 반대는 위로 전한다 |
| 보이지 않는 진척 | 하루가 끝나도 손에 잡히는 산출물이 없고, 일이 몇 주 단위로 굴러간다 | 분명한 목표를 세워 추적하고 작은 성과도 짚는다. 회의만으로 하루를 채우지 않는다 |
| 업무 바깥의 압박 | 어려운 대화와 사내 정치, 팀원의 개인 위기가 퇴근 뒤에도 머리에 남는다 | 스트레스와 되새김을 빨리 끊는 자기 관리 방법을 만든다 |
| 무력감 | 내 의견 없이 결정이 나고 예산이 깎인다. 책임보다 통제권이 작다 | 감정을 조절해 팀에게 흔들리지 않는 존재가 된다 |
매니저가 새로 익혀야 하는 일
- 피드백을 미루지 않는다. 분명한 피드백을 피하면 문제 행동이 이어지고 팀 전체가 그걸 본다. 반대로 팀원·동료에게 솔직한 피드백을 청하고, 실수를 인정하고, 내 상사에게도 피드백한다. 매니저의 태도가 팀 문화의 기준이 된다.
- 호감보다 존중을 택한다. 인기 없는 결정, 어려운 대화, 때로는 내보내는 일까지 해야 한다. 모두에게 사랑받으려 하면 신뢰와 존중을 둘 다 잃는다.
- 방 안의 어른이 된다. 압박 속에서도 침착하게 갈등을 풀고 미성숙한 행동을 가라앉힌다. 팀은 매니저의 행동을 따라 한다.
- 비즈니스와 옆 조직을 안다. 제품·디자인·데이터·영업·마케팅·고객 지원과 관계를 쌓고, 회사의 핵심 지표와 전략을 이해해야 팀의 맥락과 의존성을 챙길 수 있다.
- 팀을 대변한다. 좋은 일도 누군가 알리지 않으면 인정받지 못한다. 팀의 성과를 다른 조직에 알리고, 팀원의 보상·승진을 위해 싸운다.
- 위로 관리한다(managing up). 상사의 우선순위를 알고, 나쁜 소식은 분명하게 전하고, 상사를 막는 문제를 풀어 준다. 상사의 성공은 나중에 팀을 도울 신뢰 자본이 된다.
- 전체 그림을 지킨다. 여러 매니저·부서와 이야기하면 팀 사이의 의존성과 오해를 위기 전에 발견할 수 있다. 이 시야는 매니저만 줄 수 있는 기여다.
- 스스로 배운다. 매니저 교육을 제대로 하는 회사는 드물다. 학습 목표를 정해 공부하고, 휴가·휴직 규정과 노동 법규의 기본을 익히고, 인사 담당자와 관계를 만들고, 멘토를 찾는다.
엔지니어링을 그리워하는 것은 자연스럽다. 대신 코칭한 사람이 자라고 팀이 성과를 내는 것을 보는 데서 오는 보람이 있다.
리더십은 직함이 아니다
- 리더십은 직선으로 자라지 않는다. 리더를 하다 다시 개발자로 돌아가는 것도 경력의 한 경로다.
- 직함 없이도 리더십은 발휘된다. 팀은 리더 역할이 없는 사람에게도 안전하게 연습할 기회(회의 진행, 기술 결정 주도, 온보딩 맡기)를 준다.
정리
- 리더의 성과는 팀이 만든 가치다. 내 코드가 아니다.
- 직접 생산과 통제를 줄이고, 위임과 장애물 제거에 시간을 쓴다.
- 1:1 면담, 사람에 맞춘 업무 배정, 근거 있는 피드백, 문서화된 규칙이 팀을 키운다.
- 기술 지표가 아니라 사람의 신호를 읽는 감각을 기른다.
- 매니저는 말의 무게, 공유할 수 없는 정보, 보이지 않는 진척을 안고 일한다. 의견과 결정을 구분하고, 피드백을 미루지 않고, 팀을 대변하고 위로 관리한다.
관련 노트: 친절한 엔지니어링, 회사에서 빠르게 성장하는 법, 회의 잘하는 법, 협업을 잘하는 개발자, 엔지니어 레벨