구글 엔지니어는 이렇게 일한다. | #5장 팀 이끌기를 읽고
#5 팀 이끌기를 읽고
| 일부 내용
엔지니어링 관리자는 자신이 관리하는 팀의 구성원 모두의 성과, 생산성, 행복을 책임져야 합니다.
그와 동시에 팀에서 만드는 제품의 사업적 요구까지 충족시켜야 하죠. 하지만 사업적 요구와 개별 팀원의 요구가 항상 일치하는 것은 아니라서 이따금 관리자를 난처한 상황에 놓이게 합니다.
진짜 어려운 주제이고, 완벽한 정답을 찾기란 불가능하지 않을까 라는 생각이 든다.
실제 업무, 사이드 프로젝트 진행 과정에서도 각각의 팀원들의 니즈에 맞춘 업무 분배는 쉽지 않다.
누구나 반복적인 일이 아닌 커리어에 도움이 되는 성능 개선, 비용절감, 지표 개선등과 연관된 업무를 할당 받고 싶어 할것 이기 때문이다.
소규모의 팀에서도 이런 목소리가 나왔었는데, 구글과 같은 대규모의 팀은 어떨지 짐작이 되지 않는다.
더욱이 개발팀과 경영팀이 서로 다른 목소리를 내기 시작하면 '사업적 요구와 개별 팀원의 요구' 를 맞추기란 더 어려워진다.
그중 대표적인 예로는 기술부채의 처리 vs 신규 기능 개발이 있다.
내가 경험한 실무에서는 대부분 "신규 기능 개발 진행 및 잔여 시간 기술 부채 처리" 로 진행 되었다.
즉, 신규 기능 개발이 일찍 마무리 되면 남는 시간에 기술 부채 처리를 하는 방식으로 병렬 수행하는것이었다.
팀 구성원의 성과, 생산성, 행복, 사업적 요구까지 충족 시키는곳이 있다면... 거기가 개발자의 천국이 아닐까... 😭
| 일부 내용
팀의 역량
뭔가 뼈맞은 느낌이었다.
여태까지 내가 몰두했던것은 팀원 개개인의 역량이었지, 팀의 역량이라고 생각해본적이 없기 때문이다.
한편으로는 부끄러워진다.
개발 기획 / 트러블 슈팅 & 이슈 문서 작성 / ERD 테이블 설계 문서 작성 / 개발 기획 프로세스 점검 / 세미나 진행등 행동 자체만을 놓고보면 팀의 역량을 위한다고 볼 수 있지만, 그것을 명시적으로 생각하고 의도하지는 않았던것 같았다.
이 책에서 얻어가는것이 또 하나 생겼다.
| 일부 내용
완전히 번아웃 되지 않고서 두 역할을 동시에 수행하기란 너무도 어렵기 때문이죠.
여기까지 인지하고 실제로 행동한다는 점에서 정말 놀라웠다.
대부분은 한명에게 두 역할을 기대하거나 일 잘하는 한명에게 일감을 몰아주는 경우가 많았다.
| 일부 내용
TLM (Tech Lead Manager) 역할을 만만치 않아서 자신의 일, 위임, 사람 관리 사이에서 균형을 잡는 요령을 배워야 합니다.
그래서 백전노장 TLM 으로 부터 고차원적인 멘토링과 지원을 받아야 하는 게 보통이죠.
놀라움의 연속이다.
멘토가 필요한건 신입사원 뿐만 아니라 파트장, 팀장도 멘토가 필요하다는 말이기 때문이다.
나도 직책이 변경되었을때, 갑작스레 늘어난 책임과 업무에 갈팡질팡 했었기에 더욱이 공감이 갔다.
그 시절의 나에게 멘토가 있었다면 어땠을까. 지난날의 과거지만 반추해보게 된다.
| 일부 내용
자존심 버리기의 마지막은 간단하지만 많은 엔지니어가 실천하지 못하는 일입니다.
바로 '실수 했다면 사과하기' 입니다.
나는 그렇게 생각한다. 살면서 진심으로 사과할 '기회' 가 몇번이나 있을까.
때로는 잘못을 인지했음에도 시간이 흘러버리거나, 때로는 형식적인 사과를 한다. 하지만, 실수를 인지하고 이를 사과할 수 있는 기회가 주어진다는건 과거와 현재는 바꾸지 못하더라도 미래의 태도는 바꿀 수 있을것이다.
나는 사이드 프로젝트를 진행하며 중간 점검 단계에서 잘못을 지적 받은적이 있다. 팀 중간 피드백(문서) 이었었는데 다소 직설적인 단어 사용으로 팀원들에게 의도치 않은 상처를 주었다. 이 과정에서 잘못을 지적 받고 작성 의도를 해명하고 용서를 구하는 일례의 과정이 나를 한단계 더 성장 시켰다고 생각하며, 실무를 하며 겪었던 수많은 상황들이 머리속을 스쳐갔다. 처음이었던것 같다. 어떤 경험을 통해 실무를 하며 쌓여있던 마음속 응어리가 풀어졌던것은.
그렇기에 나는 이것을 기회라고 생각한다.
( 감사하게도 팀원분들은 너그럽게 이해해주시고 사과를 받아주셨다. )
| 일부 내용
테크 리드로서 가장 실천하기 어려운 일을 뽑으라면 '내가 하면 20분이면 끝날 일을 세 시간씩 메달려 있는 주니어 팀원 지켜보기' 를 빼놓을 수 없습니다. 스스로 배울 기회를 주는 일은 훌륭한 리더십에서 빠질 수 없는 요소이지만 특히 처음에는 매우 고통스럽습니다.
윽... 뼈가... 부서진것 같다.
( 나는 아직도 주니어다... )
| 일부 내용
행복한지 확인하기
리더로서 팀의 생산성을 장기적으로 더욱 끌어올리려면 팀원들이 행복해하는지를 확인하는 데도 시간을 써야 합니다.
당연하게 생각하면서도, 막상 일을 시작하면 기대하지 않는것 같다.
팀원일때는 '행복은 각자가 챙기자' 가 주였다.
다음에 실무에서든 사이드 프로젝트에서든 팀을 이끌 기회가 있다면, 번아웃과 피로 누적을 피하는 방법과 팀원들의 심리적 안정감 그리고 행복한지 확인하기 를 머리속에 인지한 상태에서 여러가지 방법을 시도해 봐야겠다.
책에서는 1 on 1 면담, 지저분 하고 표 안나는 일을 고르게 분배, 대체 휴가등 많은 방법을 소개해줬다.
| 일부 내용
처음 관리자가 되었을때 조직 차원에서 벌어지는 무질서와 뭐 하나 계획대로 돌아가는게 없는 모습에 몸서리 쳤습니다.
그래서 이 조용하던 회사에 갑자기 무슨일이 벌어진 것인지 다른 관리자에게 물었죠.
어리숙했던 저에게 신경질적인 웃음과 함께 돌아온 대답은 이랬습니다. 회사는 원래부터 혼란스러웠다고, 다만 전임 관리자가 팀원들을 혼란으로부터 보호해주고 있었을 뿐이라고 말이죠.
갑작스러원 관리 인원의 퇴사와 동시에 파트장으로 승진하고 들어간 첫 회의가 기억난다.
아무 준비 없이 들어간 회의에서 나는 심연을 보았다...
이번 5장에서는 '팀 이끌기' 를 주제로 한다. 실제 실무를 경험하거나 사이드 프로젝트를 경험한 사람이라면 누구나 공감이 가고 도움이 될만한 내용들이 적혀있다. 더불어, 내가 생각한 선 밖의 새로운 생각들 또한 책을 통해 읽어 볼 수 있어 적용해볼 기회가 있다면 시도해보고 싶다.