새로운 엔지니어링 매니저가 되면 모든 게 급해 보인다. 먼저 우선순위를 둘 만한 세 가지를 소개한다.
팀을 알아가기#
모든 팀원과 1:1을 잡자. 커리어 목표가 뭔지, 뭐가 답답한지, 뭘 바꾸고 싶은지 물어보자. 내가 말하는 것보다 듣는 데 더 집중하자. 신뢰를 쌓는 건 시간이 걸리는 일이다.
사람마다 일하는 방식이 다르다. 구체적인 방향을 원하는 사람이 있고, 알아서 하게 놔두길 원하는 사람도 있다. 누가 어떤 타입인지 일찍 파악하자. Camille Fournier의 “The Manager’s Path"에서 이 부분을 잘 다루고 있다. 공감과 적극적인 경청이 좋은 매니지먼트의 기본이다.
회사 맥락 파악하기#
왜 지금 이런 상태인지를 이해하자. 이전에 뭘 시도했는지, 뭐가 실패했는지, 회사가 정말로 중요하게 생각하는 게 뭔지.
어떤 회사든 의사결정이 어떻게 이뤄지는지에 대한 암묵적인 규칙이 있다. 이걸 빨리 파악할수록 팀을 위해 일을 더 잘 추진할 수 있다. Andrew Grove의 “High Output Management"에서 좋은 포인트를 짚어준다. 팀의 업무를 큰 그림에 맞추려면 먼저 그 큰 그림을 이해해야 한다.
코드베이스 이해하기#
팀에서 코딩을 제일 잘할 필요는 없다. 하지만 아키텍처, 고충, 기술 부채는 이해하고 있어야 한다. 코드를 읽자. 배포 파이프라인을 살펴보자. 일주일 자유 시간이 있다면 뭘 고치고 싶은지 팀에게 물어보자.
이렇게 하면 두 가지 효과가 있다. 좋은 기술적 판단을 내릴 수 있는 맥락을 얻게 되고, 프로세스만이 아니라 팀의 실제 업무에도 관심이 있다는 걸 보여줄 수 있다.
개발자를 신뢰하기#
이런 기반을 다졌으면, 가장 중요한 건 방해하지 않는 것이다. 맥락을 공유하고, 목표를 알려주고, 기술적 결정은 팀에게 맡기자. 매니저의 역할은 모든 PR을 승인하는 게 아니다. 팀이 필요한 것을 갖추고 있고 올바른 방향으로 가고 있는지 확인하는 것이다.
Gene Kim의 “The Phoenix Project"도 이걸 뒷받침한다. 스스로 결정을 내리는 팀이 위에서 승인을 기다리는 팀보다 더 빠르게 움직이고, 더 좋은 소프트웨어를 만든다.