이번 달부터 엔지니어링 팀의 매니저를 맡게 됐습니다. 소프트웨어 엔지니어에서 엔지니어링 매니저가 되면 무엇이 달라지는지에 대한 글을 쓰고 몇 주 만이네요. 아무도 미리 말해주지 않았던 건, 모든 일이 다 급해 보인다는 점입니다. 새로운 팀, 새로운 회사, 그리고 제가 오기 전부터 쌓여 있던 할 일 목록까지. 한꺼번에 다 할 수는 없으니, 먼저 세 가지부터 제대로 하기로 했습니다.

팀원 알아가기

#

모든 팀원과 1:1을 잡고 있습니다. 스프린트 얘기가 아니라 그 사람 자체에 대한 시간으로 만들려고 합니다. 커리어에서 뭘 원하는지, 요즘 뭐가 답답한지, 내일 당장 바꿀 수 있다면 뭘 바꾸고 싶은지. 이 자리에서 제 역할은 대부분 입 다물고 듣는 겁니다. 신뢰는 첫 주에 쌓이지 않지만, 첫 주에 잃을 수는 있거든요.

일하는 방식도 사람마다 다릅니다. 구체적인 방향을 원하는 사람이 있고, 맡겨둘 때 제일 잘하는 사람도 있죠. 이걸 반대로 대하면 서로 힘들어집니다. Camille Fournier의 “The Manager’s Path"가 이 부분을 잘 다룹니다. 결국 공감하고 제대로 듣는 게 매니지먼트의 대부분이더군요.

왜 지금 이런 모습인지 이해하기

#

프로세스든 좀 이상해 보이는 아키텍처든, 다 과거 의사결정의 흔적입니다. 뭔가를 바꾸기 전에, 그동안 뭘 시도했고 뭐가 실패했고 회사가 진짜로 중요하게 여기는 게 뭔지 알고 싶습니다.

어느 회사나 의사결정이 실제로 어떻게 굴러가는지에 대한 암묵적인 규칙이 있습니다. 이걸 빨리 파악할수록 팀을 위해 해줄 수 있는 일이 많아집니다. Andrew Grove가 “High Output Management"에서 말하듯, 큰 그림을 스스로 이해하지 못하면 팀의 일을 거기에 맞출 수도 없습니다.

코드 읽기

#

이제 팀에서 코딩을 제일 잘할 필요는 없지만, 아키텍처와 아픈 부분, 기술 부채가 어디 묻혀 있는지는 알아야 합니다. 그래서 코드를 읽고, 배포 파이프라인을 들여다보고, “일주일이 통째로 생기면 뭘 고치고 싶어요?“라고 팀원들에게 물어보고 다닙니다. 이 질문의 답이 보통 가장 솔직한 로드맵입니다.

부수적인 효과도 있습니다. 프로세스만이 아니라 일 자체에 관심이 있다는 게 팀에 전해집니다.

그다음엔 비켜서기

#

기반이 잡히면 할 일은 단순합니다. 맥락을 만들어주고, 목표를 공유하고, 기술적인 판단은 팀에 맡기는 것. 매니저의 일은 모든 PR을 승인하는 게 아니라, 팀이 필요한 걸 갖추고 올바른 방향을 보고 있는지 확인하는 겁니다. Gene Kim의 “The Phoenix Project"도 같은 얘기를 합니다. 스스로 결정하는 팀이 위의 승인을 기다리는 팀보다 빠르게 움직이고 더 좋은 소프트웨어를 만듭니다.

신임 엔지니어링 매니저에게 도움이 되는 책

#

본문에서 언급한 세 권을 한곳에 모아 둡니다.

그 밖에 신임 엔지니어링 매니저가 읽을 책을 물으면 자주 언급되는 책으로 Will Larson의 “An Elegant Puzzle"과 Lara Hogan의 “Resilient Management"가 있습니다. 앞의 책은 팀 규모, 계획, 조직 설계 같은 시스템 쪽을 다루고, 뒤의 책은 팀원 알아가기, 기대치 분명히 하기, 잘 소통하기 같은 사람 쪽을 짧고 실용적으로 다룹니다.

여섯 달 뒤에 어떻게 됐는지 다시 써보겠습니다.