(사내에 공유한 글을 일부 수정했습니다.)

안녕하세요. 올해로 6년차 개발자가 된 리니어입니다. 해가 바뀔 때마다 ‘아니 내가 어쩌다가 O년차가 됐지 큰일났다’ 싶은데요. 이제는 명실상부 팀 내 고인물이 됐고, 작년에는 짧게나마 파트 리더도 맡으면서… 조금 더 본격적으로 큰일났음을 실감했습니다.

주니어일 때도 어떻게/뭘 해야 좋은 주니어 개발자가 될까 생각하면 막막했는데, 시니어로 가는 길목에 서니 (아직까진 제가 그 길목에 있다고 믿습니다) 어떻게/뭘 해야 좋은 시니어 개발자가 될까 하는 더 큰 질문에 부딪히게 됩니다. ‘기술 기반이 좋아야 한다’ ‘리딩을 할 줄 알아야 한다’ 등 이야기는 많이 듣지만, 요구사항이 너무너무 불투명한 기획서를 받은 기분입니다. 이걸 어디서부터 시작해야 하지?

작년 말부터 이 고민이 시작돼서 이것저것 시도해 보고 있는데요. 며칠 전 SNS 에서 발견한 책이 읽다보니 제법 괜찮아서 소개할 겸 내용 일부를 가져왔습니다.

개요

  • 이 책은 1:1 멘토링에 대한 가이드부터 테크리드, 팀원 관리, “여러 팀” 관리, “매니저”를 관리하는 팁까지 다루다가 마지막 챕터는 CTO 에 이릅니다. 두둥.
  • 저는 당장 도움이 될 거 같은 1~3 장 까지만 읽어 봤고 나머지 챕터는 건너뛰었습니다.
  • 저랑 비슷한 연차가 아니셔도, 인턴/신입사원의 멘토가 될 기회(위기) 를 얻은 주니어 개발자 분들에게도 도움이 될 내용이라 생각합니다.

멘토링

  • 인턴이 회사가 찾는 인재가 아니어도 멘토를 좋아하게 만들어야 합니다. 그래야 학교로 돌아가서 친구들에게 자기 경험을 좋게 전달하니까요. 인턴의 경험은 결국 채용에 영향을 미칩니다.
  • 멘토는 인턴 프로젝트에 아이디어를 내지 않는 것이 좋습니다. 인턴에겐 너무 어려운 주제가 될 수 있기 때문에.
  • 그렇다고 프로젝트를 안 주면 인턴은 기간 내내 방황하다 돌아갑니다
  • 신입 개발자가 절반 기간 안에 끝낼 만한 걸 주는 게 좋습니다. 인턴 기간이 2달이라면, 신입 개발자가 한달만에 할 과제를 줍니다.
  • 경청
    • 듣는 동시에 뭐라고 대답할지 고민하고 있는 건 경청이 아닙니다.
    • 들으면서 딴 짓하는 것도 마찬가지입니다.
  • 의사소통
    • 리더쉽을 배우는 초반에 보통 알게 되는 사실인데, 모든 사람은 자기 의도를 상대방이 정확히 이해하게 말하지 못합니다.
    • 그러므로 멘토는 복잡한 설명을 몇 번이나 다르게 말할 수 있어야 합니다.
    • 멘티 눈에 멘토는 힘을 가진 사람이기 때문에 잘 이해를 못했어도 긴장해서 질문을 안 할 가능성이 높습니다. 멘티가 이해할 때까지 시간을 써야 합니다.
  • 피드백
    • 멘티가 자기 작업을 팀원들에게 발표할 기회를 줍니다. 자기 작업이 가치있는 일이라고 여기도록
  • 멘토와 멘티가 미팅을 할 때는 미팅 주제와 질문을 미리 정하고 들어갑니다. 이때 주제를 정하는 주체는 멘티입니다. 멘토가 정해버리면 멘티는 준비할 시간이 부족할 수도 있습니다.
  • 솔직한 충고, 꼭 필요한 조언을 해줄 전문성이 없다면 멘토를 거절하는 것도 방법입니다. 현재 업무량, 휴가 계획 등을 이유로 댈 수도 있고, 꼭 적합한 이유가 없어도 괜찮습니다.
  • 멘티의 질문은 새로운 사람의 눈을 통해 조직을 관찰하는 시작점이 됩니다
  • 시니어가 되면 안 좋은 습관이 종종 생기는데, 그 중 최악은 잘 이해되지 않거나 자신의 의견에 동의하지 않는 사람과 논쟁하려는 경향입니다. 신입, 주니어와 업무를 수행하려면 그들이 이해하는 방식으로 경청하는 게 중요합니다.
  • 멘토링 관계를 오용하지 맙시다. 멘토든 멘티든 경력은 길고 IT 바닥은 좁으니까.

테크리드

  • 이 책에서 테크리드는 2~10명 규모를 책임지는, 관리와 개발을 병행하는 역할을 말합니다. 직급의 개념보다는 모든 개발자가 시니어 수준이 되면 맡게 되는 몇 가지 책무로 정의합니다.
  • 기술은 시니어 개발자의 역할입니다. 팀에서 가장 경험 많거나 실력 있는 개발자 != 테크리더의 역할
  • 테크리더의 핵심 도전 과제는 균형 잡기
    • 어떻게 하는지 잘 알고 내가 즐기는 것 (코드 작성) 과 어떻게 해야 하는지 모르는 것 사이의 균형
    • 익숙한 걸 선호하는 건 지극히 자연스럽습니다.
  • 프로젝트 관리에서 계획을 세우는 건 중요합니다.
    • 그러나 계획을 얼마나 완벽하게 수행했는지, 사전에 모든 세부를 다 파악했는지, 장차 벌어질 일을 예측했는지가 중요한 게 아니고
    • 실제 업무를 시작하기 전에 얼마나 깊이 있게 생각했는지가 중요합니다.
  • 시간을 들여 설명하길 주저하지 마세요. 기초적인 개념과 동기를 설명하는 자리를 만드는 건 시니어/주니어 가릴 것 없이 도움이 됩니다.
  • 경력 트랙은 원할 때 언제든 전환할 수 있는 것입니다. 어떤 선택도 영원한 건 없고, 모든 역할은 장단이 있습니다.
    • 시니어 개발자가 될 것이냐, 테크리더가 될 것이냐 고민에 대해선 책의 80p ~82p 가 눈물날 정도로 잘 설명하고 있습니다.
  • 혼자서 재미있는 작업을 전부 하고 있다면 당장 멈추기. 다른 팀원을 배려하는 의미에서라도 혼자 늘 감당하면 안됩니다. 물론 시간 여유가 있다면 때때로 재밌는 것도 해봅니다.
  • 기술결정 주도하기. 모든 걸 혼자 결정해서도 안되지만, 모든 걸 팀원에게 맡겨서도 안됩니다. 직접 결정할지 / 누군가에게 결정을 위임할지 / 팀원 전체가 모여 결정할지 그건 테크리더가 정해야 합니다.
  • 다른 사람에게 발언 기회를 주고, 경청한 다음, 그 사람의 말을 반복해보는 연습이 필요합니다. 매니저가 되느냐 마느냐의 문제가 아니라, 의사소통과 경청을 잘 못하면 더 이상 성장하기 어렵습니다.

1:1 미팅

할일목록 점검 방식

  • 이 방식의 기본 전제는 ‘의미없는 미팅으로 시간을 낭비하지 말기’ 입니다.
  • 함께 토론할 만한 것인지, 이 시간이 의미가 있는지 따져봐야 서로 에너지 낭비를 하지 않습니다.

팀원의 이야기를 듣는 방식

  • 두서없이 진행되면 그냥 불평을 쏟아내는 고민 상담 자리가 되기 쉽습니다.
  • 공감을 잘하는 팀장은 팀원과 비정상적 방향으로 가까워질 수 있습니다. 팀원의 하소연을 반복적으로 듣는 시간이 되면 의미가 없습니다.

비공식적인 피드백과 코칭을 주는 방식

  • 딱히 할 얘기가 없다면 분기에 1번 정도도 괜찮습니다.
  • 동료를 모욕하고, 꼭 필요한 회의에 불참하고, 부적절한 언어를 사용하는 등 문제 행동에 대해서는 1:1 미팅까지 기다리지 말고 바로 피드백해야 합니다. 때를 기다릴수록 피드백하기 어렵고 효과가 떨어집니다.
  • 칭찬도 마찬가지로 바로 하는 게 낫습니다. 필요한 사람이라고 인정받는 건 누구나 좋아합니다.

핵심

  • 어떤 방식을 쓰든, 팀원의 인간적인 모습을 이해할 여지를 남겨두기. 사생활을 캐물으라는 게 아니고 인간적인 관심을 보이라는 뜻
  • 가족, 친구, 취미, 반려동물 같은 가벼운 이야기로 시작해도 되고, 팀원의 경력을 듣고 장기적인 목표를 묻는 것도 괜찮습니다
  • 반드시 기술이나 보상 등으로 대화 주제를 한정할 필요가 없음
  • 매니저가 공유 문서에 미팅 노트를 (내용, 요점, 할일) 작성하고 팀원에게 공유하는 것도 방법입니다. 맥락 이해에도 도움이 되고, 언제 무슨 피드백을 받았는지 기억하기 쉽고, 나중에 성과 평가 작성할 때 참고도 됩니다.