R&D 팀 부팀장이 된 지 한 달이 지났다. 데일리 노트를 기반으로 배운 것과 개선할 것을 정리해본다.
배운 점
Alignment 간극은 생각보다 크다
팀원들과 방향이 잘 맞고 있다고 자신했다. 그런데 연말 wrap-up에서 뼈아프게 깨달은 것이 있다. 지시한 방향을 캐치하지 못하거나 다른 길로 빠지는 케이스가 생각보다 많았다는 것이다. 한 팀원은 데드라인 3일 전에야 요구사항 충족이 불가능하다고 보고했고, 다른 팀원은 발표 당일에야 말했다.
이 경험이 승진한 1월부터 daily scrum을 도입한 직접적인 계기가 됐다.
시스템을 만드는 것보다 유지하는 것이 더 어렵다
Daily scrum, 1:1, Gantt chart, 소통 원칙, 근태 가이드라인 등 한 달 만에 여러 시스템을 세웠다. 그런데 시스템을 세우는 것 자체는 어렵지 않았다. 진짜 역량이 필요한 건 그것을 일관되게 유지하면서 팀이 자연스럽게 따라오게 만드는 것이었다.
공유 문화가 무너지면 정치가 시작된다
DM 위주 소통이 늘어나면 서로 무슨 일을 하는지 모르게 되고, 뉴스를 들을 수 있는 포지션의 영향력만 커진다. 열심히 일하는 사람이 드러나야 다른 팀원들도 동기부여가 된다. 공개 채널 중심 소통을 밀어붙인 이유다.
기간 산정에는 ‘근거 도출 시간’이 필요하다
팀원들이 일정을 못 맞추는 핵심 원인을 파고들어 봤더니, 기간 산정 자체에 시간을 쓰지 못했기 때문이었다. 대충 2주라고 잡고 시작했다가 5주가 걸리는 일이 반복됐다. 앞으로는 기간 산정을 위한 별도 시간을 WBS에 공식적으로 넣고, 30% buffer를 원칙으로 가져간다.
3개월 끝난다고 하면 4개월 정도로 잡아라.
선배 리더에게 들은 말인데, 처음엔 과하다고 느꼈지만 한 달만 지나니 정확히 맞는 말이었다.
1:1과 Daily Scrum에 대한 팀 반응
도입 초기에 부담을 줬을 수 있지만, 1:1을 하고 나서 솔직하게 의견을 물어봤다. 팀원 전원이 필요성에 공감하고 있었다. “데일리 스크럼 꼭 필요하다”, “생각도 정리돼서 원오원은 좋은 것 같다” 같은 피드백을 받았다. 방향은 맞았다.
실무와 관리는 둘 다 해야 한다
상위 리더로부터 받은 피드백: 팀 관리와 문서 작업에 너무 치중하고 실무에 신경을 못 쓰고 있다. 부팀장이라고 관리만 하면 안 된다. 기술적 난제를 직접 풀 수 있어야 팀원들의 신뢰를 유지할 수 있고, 방향 판단도 정확해진다.
이건 진짜 뼈 아팠다.
개선할 점
성과를 적극적으로 표현하라
리더 위클리에서 하이레벨로만 말하고 넘어가는 버릇이 있었다. 상위 리더의 직접적 피드백: “자랑할 거 있으면 확실하게 자랑해라. 표현을 해달라.”
“무엇을 했다”보다 “이것이 왜 의미 있다”를 앞세우기로 했다. 정량 지표와 비즈니스 임팩트를 한 줄로 연결해서 말하는 연습이 필요하다.
Scrum이 압박 도구가 되지 않도록
팀원의 우려가 있었다. 스크럼이 소위 K-애자일화돼서 “한다면서 안 됐네”라는 압박 도구가 될 수 있다는 것. 스크럼의 본래 목적은 안 되는 걸 빨리 발견해서 우선순위를 바꾸고 되게 만드는 것이지, 못한 걸 추궁하는 자리가 아니다.
blocker 발견 시 “왜 안 됐나”가 아니라 “이걸 되게 하려면 뭐가 필요한가”에 초점을 맞추는 톤을 의식적으로 유지해야 한다.
코드 기반 협업 체계를 확립하라
팀원의 피드백: 코드 공유를 파일로 주고받는 게 비생산적이다. Git commit 기반으로 얘기하는 문화가 필요하다. 누군가 한 사람이 받아서 합치는 형태가 아니라, 각자가 커밋하고 그 커밋 위에서 대화하는 구조. 실험 코드라도 커밋 단위로 공유하는 습관을 팀 전체에 정착시켜야 한다.
Backlog를 머릿속이 아닌 시스템에 넣어라
도메인이 전환되면서 해봐야 하지만 못 하고 넘어간 것들이 많다. 이런 것들이 개인의 머릿속에만 있으면 연구 연속성이 끊긴다. 이슈 트래커의 backlog에 아이디어 레벨까지 적재하도록 팀 전체에 요청했고, 분기 1회 backlog review를 정례화할 계획이다.
반복적으로 밀리는 태스크를 직시하라
특정 태스크가 열흘 가까이 매일 미완료로 이월된 적이 있다. 반복적으로 밀리는 태스크는 우선순위가 낮은 것이 아니라 착수 자체가 막혀 있는 것일 가능성이 높다. 왜 못 하는지 원인을 분석해야 한다 — 시간 부족인지, 의존성인지, 심리적 저항인지.
시야를 팀 너머로 넓혀라
부팀장 급 됐으니 시야를 넓혀서 회사 전반 차원을 다시 보는 시야가 필요하다.
평가 면담에서 받은 피드백이다. 현재까지는 팀 내부 관리에 집중하고 있지만, 다른 팀들의 이슈도 파악하고 우리 팀 기술이 어디에 연결될 수 있는지를 폭넓게 보는 시각이 필요하다.
앞으로 어떻게 나아갈 것인가
핵심 원칙 3가지
- 투명성: 공개 채널 중심 소통, 이슈 트래커 기반 진척 관리, backlog 공유. 정보 비대칭을 최소화한다.
- 예측 가능성: WBS + 30% buffer 원칙, 마일스톤 기반 로드맵. 팀원이 2개월 앞을 볼 수 있는 상태를 유지한다.
- 기술적 신뢰: 관리 업무에 파묻히지 않는다. 핵심 기술 난제에 직접 관여해 실무 감각과 기술 판단력을 유지한다.
자기 개발
- 말수를 줄이고 말의 결을 고른다. 급히 반응하지 않고 한 박자 쉰다.
- 조직 내 다른 리더들과 미팅 전에 상대의 역할을 미리 파악하고 대화에 임한다.
- 리더십 관련 서적 읽기를 지속한다 — 어려운 결정들에 대한 프레임워크 확보.
한 줄 정리
Daily scrum, 1:1, 로드맵, KPI, 이슈 트래커 — 시스템은 세웠다. 이제 중요한 것은 이 시스템 위에서 팀원이 자율적으로 성과를 내고, 그 성과가 조직 전체에 보이게 만드는 것이다.