리더가 되었고 권한과 책임이 커졌다. R&D팀의 팀장이 되면서 조직에서 나에게 기대하는 일의 목표가 잘 개발하는 것에서 성과를 책임지는 것으로 옮겨졌다.
그러던 중 '낙관적으로 구상하고, 비판적으로 계획하고, 다시 낙관적으로 실행한다.'라는 구절이 눈에 들어왔다. 어떤 한 사람이 낙관적이기도 하면서 비판적일 수 있나? 하는 근본적인 질문이 들었지만, '아 내가 지금 그렇게 되려고 노력하고 있구나' 하고 공감 됐다. 나는 조직을 위하여 E와 I의 스위치를 온오프 하는 나름 사회화가 된 INTJ 유형인 것 같다. 흔히 개발자라고 하면 상상되는 캐릭터에서 소통을 꺼리지 않는 쪽으로 쪼끔 발전한 느낌을 떠올리면 된다.
이는 원래 성격의 영향도 있겠지만 결국은 성과를 책임져야 하는 역할이기 때문인데, R&D팀의 특성상 도전적이고 성과를 예측하기 어려운 선행 연구적 업무가 많다. 그럴 때면 어떤 사람들은 '그게 되겠어?', '위에서 또 이상한 거 시키네', '진짜 그거 해요?'와 같은 냉소적인 반응을 보이곤 한다. 나 자신은 어찌어찌 셀프 모티베이션은 할 수 있어도, 리더가 되면 팀의 성과를 달성하기 위하여 어떻게든 팀원들을 어르고 달래서 한 방향을 보도록 유도하고 사기를 끌어올려야 한다. 어떨 때는 개발자로 입사한 게 아니라 감정노동 서비스 포지션으로 입사한 것으로 착각하게 될 때도 있다. 이 책에는 그러한 때에 어떻게 열정을 다시 들이붓고 성과를 낼 수 있었는지 쓰여 있었다.
현실에서 어떤 한 사람이 낙관적인 특징과 비판적인 특징을 동시에 지니기는 어렵고, 그러한 동료를 만난다는 것은 행운일 것이다. 대체로 낙관적인 사람은 낙관적인 편이고, 비판적인 사람은 비판적인 편인 경우를 많이 보았다. 이러한 경우 성과를 위하여 이 들을 같은 팀으로 배정하여 협업을 시키곤 한다. 주의할 점은 이때에도 이 들을 팀으로 단순히 물리적 결합을 시켜놓고 알아서 잘해봐라고 하면 생각보다 성과가 나지 않는다는 것이다. 누구를 리더로 시켰을 때 성과가 나는가? 누구에게 어떤 역할을 주어야 하는가?
개발자 조직은 어느 정도 경력이 쌓이면 커리어 패스를 IC(Individual Contributor) Track으로 갈지 Manager Track으로 갈지 선택해야 하는 시점이 온다. 이전에는 개발 잘하고 경력이 쌓이면 그 사람이 리더가 되는 경우가 많았는데 그러한 경우 다양한 부작용들이 나오곤 했다. 개발자로서의 역량이 매니저로서의 역량과 다르기 때문일 것이다. 스타트업에서는 시간이 금이다. Time to Market을 해야 하는 상황에서 적절한 팀 편성이 안 되는 오판을 몇 번 반복하면 이미 경쟁사 제품이 저만치 앞서 있는 현실을 마주하게 된다. 이 책에서는 어떤 사람에게 어떤 역할을 부여하는 것이 좋은 선택인지를 제안하고 있다. 책을 읽고 현업에서의 나의 경험과 존재하지만 부유하던 생각들을 정리할 수 있는 좋은 기회였다.