6. 수석엔지니어의 가짜노동
연구개발 관리가 아니라 연구개발 그 자체
수석엔지니어 리더가 되자마자 몰려드는 업무에 정신 못 차리던 와중에는 오히려 알아차리지 못 했다.
2년동안 열심히 정신없이 살다보니 보어아웃이 오면서 내가 하는 업무가 가짜노동이 되고 있는 건 아닐까? 라는 의구심에 항상 시달렸다. 가짜노동을 하고 있는게 아닐까 생각하게 된 업무들은 어떤것들이 있을까.
팀원들 이슈 관리
나도 안다, 모든 이슈를 알고 있어야 마음이 편하고, 따라다니면서 같이 해결하고 있는 상황인 것을.
하지만 이건 마음이 편한 일이지, 수석엔지니어만이 해야 하는 업무는 아니다. 워킹메이트나 개발팀/페어를 재구성하는 것이 더 적절한 수석엔지니어의 역할이다.
매일매일 팀원별 협업도구/태스크보드 현황을 모니터링하면서, 모든 이슈에 대해 현황을 파악하고 좋아요라던지 코멘트를 달아주는 시간을 쓰고 있었다면 이제 그만하도록 하자.
그 일을 해야 했던 이유는 필요해서가 아니라, 누가 물어 볼 때 바로 즉답이 가능해서였다. 팀원들이 현재 무슨 업무를 하고 있고, 언제까지 끝내기로 했으며, 어떤 점이 힘든지 정도만 알면 된다. 모든 업무나 이슈의 상세를 알고 내가 같이 해야만 할 이유는 없다.
내가 했던 가짜노동은 일주일에 2-3번씩 팀원들별로 보드를 관리하고, 이슈에 대한 현황 확인, 그리고 코멘트로 끼어들어 업무방향 조정하기 였다. 팀원들의 코드리뷰나 버그관리 시스템 활동도 모니터링했다, 얼마나 많이 개발이슈를 고쳤는지에 대한 통계를 내고는 잘 관리하고 있다며 만족했다. 이런 식의 관리업무는 하기는 편했고 또 정말 일하는 것처럼 보였다.
관리 대신에 내게 주어진 업무에 대해 스스로의 태스크보드를 관리하자.
회의, 그리고 그 회의에 누군가를 데려가기
수많은 회의가 있다, 매일 초대가 오고 그걸 수락해야만 한다. 팀원들도 알아야 하는 회의라고 생각해서 몇명을 골라 늘 참석자로 대동한다.
대부분의 팀원 (그리고 나를 포함해서)들은 회의에서 발언 한 번 하지 못 하고 돌아오는 경우가 허다하다.
회의에 기여하는 바가 전혀 없으며, 팀원들 스스로에게조차 도움이 되지 않는 회의에 참석하는 것은 시간낭비다. 그 시간에 개발 한 줄 더하거나, 이슈 디버깅 몇 분 더 하는 것이 나을 수 있다.
물론 회의에 혼자 가서, 결정된 걸 나만 알고 전파하지 않는 것은 문제다. 그러나 대부분의 회의에서는 의사결정이 한번에 되는 경우는 없다, 다음 회의 혹은 메일로 주고 받자는 얘기 뿐이다.
내가 얼마나 바쁜지를 팀원들에게 과시하려는 목적으로는 회의에 데려가지 말자.
그리고 이 회의가 팀원에게 도움이 될 것이라는 긍휼, 그러나 본인만의 착각, 을 베풀고 뿌듯해하지도 말자.
회의가 필요하면 팀원들 스스로 실무진들과 함께 회의를 준비하고 알아서 참석하고 결론을 내고 온다.
그리고 나한테 오는 회의초대도 가능하면 거절할 것들은 거절해야 한다. 무지성으로 참석하는 회의는 전혀 얻는 것이 없다.
메일 포워딩
'가짜노동' 책에는 이메일 자체, 그리고 그 중에서도 참조 이메일에 파묻힌다는 행위를 부정적인 시선으로 바라본다. 하지만 직장에서는 참조 이메일보다 더 신중하게 작성해야 하는 이메일이 있다고 생각한다.
그것은 바로 FYI, 내가 수석엔지니어가 되고 가장 많이 작성하는 이메일이다.
개인적으로 FYI 라는 메일을 책임/선임엔지니어 때 받으면 FYI에 딸려있는 모든 이메일 본문을 처음부터 읽고, 시간순으로 담론을 재구성해서 현재까지 정리된 내용이 무엇인지, 그리고 문제가 무엇이고 나의 업무에 연관된 부분은 이거구나 까지 파악하는데 최소 몇십분이 걸리곤 했다. FYI 보내는 데는 1초면 충분한데 비해 너무 과도한 시간이다 (FYI를 읽지 않는 팀원도 있다는 것도 모른채)
FYI를 보낼 거라면 본문 요약, 그리고 왜 당신한테 FYI를 보내게 되었는지 정도는 요약해주자, 팀원들에 대한 최소한의 예의라고 생각한다.
그리고 나조차도 FYI라고 받은 이메일을 무시할 수 있으면 좋겠다. 잘 되진 못하더라도 상사나 임원한테 계속 무의식적으로 인지를 시켜줘야 할 것이다.
반대로 수석엔지니어의 진짜노동이라고 생각한 업무는 무엇일까
특허, 논문
전편에서 수석엔지니어가 공부해야 하는 것 중에 하나가 최신트렌드 학습이라고 했다. 그리고 그 결과로 나와야 하는 산출물이 특허나 논문이다. 개발산출물의 형태로 나올 수도 있겠지만, 보통 개발산출물의 경우 회사자산으로 본인이 소유하지 못 하는 경우가 많기도 해서, 수석엔지니어 커리어에 도움이 되는 것은 특허나 논문이라고 생각한다. 회사에서 논문을 쓰는 것이 제약이 많다면 특허를 공략하도록 하자
일주일에 하루나 이틀정도는 관리하는 대신에 본인의 특허를 위해 주제를 찾고, 아이디어를 발굴하고 (이 과정에서 팀원들을 참여시켜도 좋다), 디벨롭하는 과정을 거쳐야 한다.
본인의 팀이 관여하는 프로젝트에 대해 특허를 작성하는 것이 쉽겠지만, 특허는 최신 트렌드를 반영하는 편이 출원하기도 용이하고 또 추후에 다른 커리어를 준비할 때도 도움이 된다.
팀원 역량파악, 성장 돕기
수석엔지니어는 중간관리자로써 여러 HR 소식이나 추천 관련 요청이 많이 들어온다. 이 때 적절한 팀원 (해당 시기에 해당 업무나 추천이 필요한 사람)이 누구인지 파악하고 선출하는 것도 수석엔지니어의 역할이다.
평소에 팀원들 역량파악이 필요한 이유이기도 한데, 사람마다 다 강점이 다르기 때문이다. 업무 별로 잘 할 수 있는 것 같은 사람이 있고, 어떤 업무는 좋아하지 않는 사람이 있기 마련이다.
그리고 너무 본인의 현재 역량에만 매몰되지 않도록, 역량성장의 기회를 항상 주어야 하는 의무가 있다고 생각한다. 직장인으로서 너무 과도한 소명의식 아닌지 가끔 의심하곤 하지만, 팀원들이 잘 되어야 내가 잘 되는 것이라고 생각하기로 하자.
로드맵
실은 가짜노동과 진짜노동 그 사이 어딘가에 있다고 생각하는 업무이다.
개인적으로 로드맵 작성은 중간관리자에게 시키는 전략연습게임 같은 것이지, 수석엔지니어의 역할은 아니라고 생각한다. 팀의 로드맵이라고 하는 것은 팀장이나 임원이 Top-down으로 깊은 고찰 끝에 만들어내는 큰 방향이지, Bottom-up으로 로드맵을 작성하고 팀별 로드맵을 퍼즐맞추기 한 것이 팀의 로드맵은 아니라고 생각한다.
매년 로드맵 작성을 요구받는 입장에서 할 수 있는 최선은, 최신트렌드에 대해 학습한 내용을 적절한 팀원을 선정하여 프로젝트를 계획하는 것이다.
오늘도 출근해서 가짜노동과 진짜노동을 번갈아가면서, 가짜노동을 최대한 줄이기 위해 노력해본다.
쉬운 이슈관리를 하고자 하는 충동을 억제하고, 이메일 FYI를 썼다가 지우고, 회의참석은 최대한 거절한다.
그 사이에 새로운 형태의 업무는 계속 생겨나고, 임원인사 덕에 조직별 업무 현황보고를 해야한다. 가짜노동 하나 줄였는데, 가짜노동이 하나 더 생긴 기분이다.
