okky - 개발조직 관리, 나만 이렇게 힘든거야?
2023. 12. 19. 부제 : 화성에서 온 팀장, 금성에서 온 팀원
한국에서 꽤 오래된 개발자 커뮤니티 사이트인 https://okky.kr/ 와 인연이 닿게 되어서 한 시간 반 정도 강연을 하게 되었다. https://okky.kr/articles/1479127
작년 한국 생활을 정리하는 와중에 시간이 맞아서 거들어 보겠다 했던 시간이었고, 주제는 매니저의 입장과 시각에서 어려움들과 몇몇 소소한 팁들을 전할 수 있으면 하는 생각이었다. 다소 자극적인 내용으로 제목이 정해졌고, 누가 참여할 지를 전혀 모르는 상황에서 어디까지 준비를 해야 하는가에 대한 챌린지들이 있었다.참가비가 3만원 정도 하는 zoom을 이용한 유료 세미나의 형태였고, 평일 오후 8시인데도 도합 30분 정도 되시는 분들께서 시간을 맞춰 주시며 이야기를 들어 주시고, 여러 질문들을 해 주셨다.
(updated) https://www.youtube.com/watch?v=pQEUqoZRKpw
매니저의 시각에서 주변의 기대와 할 일들 등을 나누어 보았다.타산지석, 역지사지, 동병상련 등이 전하고 싶었던 메시지이고, 내용들보다 실제 사례들을 청중들이 많이 듣고 싶어하던 거 같았고, best practice 중에서는 위임과 situational leadership 에 대해 이야기를 좀 더 듣고 싶어 하셔서 okky.kr 에 보충 자료를 올려 놓는 A/S 까지를 했었다. https://okky.kr/articles/1482832#note-1769420
관련해서 Q&A 들이 여럿 있는데, 몇 개 남겨 본다. 경험에 바탕한 개인적인 의견이지만, 혹시 여기 흘러 오신 분들 중 관심 있으신 분들이 계시다면 작은 도움이라도 되면 한다.
Q. 한국이랑 미국이랑 많이 다른가요 ?
A. 미국은 해고가 자유롭습니다. Performance를 올리라는 주문은 당연하고, performance 이외의 안건이 고려되지 않도록 교육 받습니다.
A. 일이 주어졌을 때 이후에 진행되는 모습 등에 대해서는 별 차이를 못 느꼈지만, 일이 주어지게 하는 과정에서 ‘자발적'인, ‘공격적인' 면에서 차이가 많습니다. 이것들이 모여 분기 별 성과들을 모으게 될 때 양적인 면에서 차이가 많다는 개인적인 견해입니다. E.g. 네카라쿠베
Q. 나도 매니저를 평가하나요 ?
A. 상위 매니저에게 고자질(?)의 개념으로 정보가 취합됩니다. 다만 매니저가 하는 일의 일부에 대해 나의 피드백이 올라가는 것이기에 생각만큼 영향력을 기대하지 않는 게 좋습니다.
Q. 진짜로 미국의 프로젝트 관리는 우리보다 나은가요 ???
A. 프로젝트 관리, 프로덕트 관리 모두 아주 강력한 CS 배경을 가진 사람들이 운영을 해서 훨씬 자연스러웠습니다. 프로젝트의 경우 한국에서 좋은 TPM 이 관리를 해서 좋은 경험이 있는데, 미국의 G 사의 경우 디자이너와 PM 들도 PR을 주고 받고 리뷰하고 하는 등 기술 장벽이 전혀 없었던 게 도움이 되었습니다. 상대적으로 한국에서는 의사 소통에 시간이 더 들었던 경험이고, 배우려는 의지도 차이가 많이 난다는 느낌이었습니다.
Q. 리더는 팀관리, 일관리, 목표관리, 문화개선에도 더 관심을 두고 발전시키느라 개발 스킬 향상이 더딥니다. 어떻게 해야 하나요? 괜찮은건가요?
A. 개인적인 의견으로 ‘괜찮다'는 견해입니다. 회사의 입장에서 더 중요한 일을 하고 있는 것이고, 회사에서 주어진 역할과 동떨어진 개발 스킬 향상은 무의미하다는 생각입니다. 저는 거꾸로 팀원들로부터 도움을 받았던 경험들도 좋았습니다.
Q. 개발자 관리에 성공적이었던 케이스, 실패했던 케이스
A. 과제를 잘 이루어 결과를 내어서 각 멤버들을 프로모션까지 시켰을 경우를 성공적이었다 생각하고 있습니다. 주어진 윈도우 안에서 프로모션 시켜서 다른 팀으로 박수 치며 보내는 게 좋은 사이클이라 생각하고 있고, 반대로 제가 생각하기에 실패라고 생각하는 건 과제가 잘 진행이 됨에도 배신을 당한 경우들도 몇 번 있었는데, 제가 마음의 상처를 받아 과제 진도가 더디게 나갈 경우 이에 해당하겠습니다.
Q. 팀원들에게 어떻게 동기부여를 할 지
A. 정답은 없겠지만, 크든 작든 impact 를 정의하고 공유하는 것들을, 그리고 그것이 중요하다는 공감대를 얻어 오는 방법이 도움이 되었습니다. 당신이 지금 하는 것들이 이런이런 의미로 돌아온다.. 그리고 보스가 혹은 고객이 어떤 것을 원한다는 것을 계속 impact로 정의하는 것이 자그마한 도움이 되었습니다.
Q. 개발 조직의 스케일을 키워나가는 방법이 궁금해요.
A. delegation을 할 / 맡길 사람들을 여럿 준비시키고 거기에 사람들을 붙이는 모습이 교과서적이겠습니다. 중복된다 싶을 정도로 여러 명을 준비시킨 후에 사람과 과제를 재분배 여러 번 하면서 좋은 기억들이 있습니다.
Q. 개발조직 리더의 가장 중요한 역량
A. 회사의 impact 와 과제를 align 시키고, 결과에 의미를 부여하는 역량이라 생각합니다. 하지 말아야 할 일들을 정리해서 걷어 내고 가진 자원을 집중할 곳을 찾아서 진행하는…
Q. 스타트업에서 새로운 사업을 할때 개발자들은 어느 시기 부터 참여를 하면 좋을까요?
A. 일부러 늦게 참여하는 이유가 있을까요 ? 최대한 한데 어우러져 만들어야 하는 조직이지 않을까요 ?
Q. 리뷰, 피드백을 할때 반드시 시키는 기준(철학)이 있을까요?
A. 일과 증거로만 이야기한다. SBIT 등이 감정적이지 않게 되는데 도움이 되고, calibration 이후 피드백의 경우 여러 사람들의 의견이 모아진 것이라는 생각으로 접근합니다.
Q.리더를 하는 경험이 개발을 계속하고 싶어하는 개발자로서 어떤 장점이 있다고 생각하시나요?
A. 회사에서 개발이든 리더든 임팩트를 만드는 게 목표여야 한다고 생각합니다. 코드를 짜는 것, 사람들의 동의를 구하는 것, 필요 없는 것을 지우는 것 모두가 의미 있어야 할테고, 임팩트와 관련 없는 ‘좁은 의미'의 개발은 월급 주는 고용주에 대한 도리가 아니라 생각합니다.
Q. 좋은 개발 조직을 위한 "마음수양" 방법이 궁금합니다.
A. 저도 좀…. ㅠㅠ
