한 달 전쯤부터 회고글을 쓰려고 생각을 했지만 이런 저런 일이 주위에서 생기고 다른 일들이 우선 순위가 높다보니 이제서야 쓰게 되었다. 글은 개인적으로 앞뒤로 시간적 여유를 두고 쓰는 것을 선호한다. 이런 저런 생각들이 떠오를 수 있는 시간이 필요하고 그것들이 얼기설기 엮여 글로 나타나기 때문이다.
하지만 지금은 더 늦어지면 몇 달 동안 느꼈던 것들이 바래질 거 같아서 더 미루면 안될 거 같다고 생각했고 조금은 희미해졌지만 몇 달 동안 느끼고 생각한 것들에 대해서 정리해보려고 한다.
여유, 휴식 이상의 의미가 있다.
어느 순간 또 다시 정신 없이 일을 마무리 하기 위해서 몰두하고 있는 모습을 보았다. 그 기간 동안에 팀의 비전과 방향성을 생각하고 내가 지금 하고 있는 일에 의미를 부여하는 것이 정말 힘든 것 같다. 그래서 이전에도 종종 ‘코딩하는 기계’가 된 것 같다고 느꼈던 걸지도 모른다.
정신 없는 와중에 짬을 내어 <소프트스킬> 책을 읽었다. 오래 전에 샀었던 책인데 꼭 한번은 다 읽어보고 싶었다. 이 책을 다시 읽게 된 것은 우연히 청소하면서 다시 발견하면서부터였다. 청소를 끝내고 의자에 걸터 앉아서 책을 읽기 시작했다. <소프트스킬> 책은 엄청 깊은 내용을 담고 있는 책이라기 보다는 ‘개발자 백서’와 같은 느낌이다. 개발자로서 재테크는 어떻게 하면 좋을지, 혹은 개발자로서 집중하고 싶은 시간을 만들고 싶으면 어떻게 하면 좋을지 등 여러 가지 팁들에 대해서 알려준다.
뽀모도로에서 얻은 교훈
잠깐만 보자고 했던 것이 어느새 150페이지를 넘게 읽고 있었던 것 같다. 기억에 남는 것 중 하나가 집중을 하기 위한 테크닉으로서 ‘뽀모도로‘라는 기법이다. ‘뽀모도로’는 테스크를 30분 단위로 나누어 25분동안은 주위에서 무슨 일이 일어나든 지금 하고자하는 테스크에 집중을 해서 처리를 하고 남은 5분은 편안하게 휴식을 하는 방법을 말한다. 이렇게 하나의 30분 단위를 ‘1 뽀모도로’라고 하는데 4 뽀모도로를 끝내면 20분에서 30분 사이의 조금 긴 휴식을 취할 수 있게 해준다.
처음엔 ‘이게 뭘까?, 이게 될까?’하면서 시작했던 것 같다. 25분동안씩만 집중을해서 내가 이전에 했었던 일의 양을 쳐낼 수 있을까 의심이 되었다.
뽀모도로는 지금까지도 하고있다. 약 한 달 정도 기간동안 한 것 같은데 뽀모도로의 강력함은 다음과 같다고 생각한다.
5분의 휴식동안 ‘지금 내가 어떤 일을 하고 있지? 다음에 내가 해야하는 일은 어떤 것이지?’라는 질문을 던질 수 있게 여유를 준다. 이를 통해 나는 좀 더 넓은 시야를 가지고 일을 할 수 있었던 것 같다. 지금 하는 일과 다음에 해야하는 일 사이의 관계를 생각할 수 있었고, 일을 하는 과정에서 놓친 것은 없었는지 스스로 돌아볼 수 있게 해준다.
두 번째는 집중 시간 사이사이의 휴식시간 덕분에 나를 지치게하지 않고 좀 더 오랫동안 일하게 해준다. 4 뽀모도로를 끝내고 긴 휴식시간을 주는 것도 위와 같은 이유라고 한다. 5분의 휴식은 직접 해보면 좀 더 체감이 되겠지만 짧다. 뽀모도로를 만든 사람도 4 뽀모도로를 끝낼 때즈음이면 사람이 지친다는 것을 알고 다시 일을 집중해서 할 수 있도록 긴 휴식시간을 줬다고 한다.
사람을 성장시키고 같은 방향을 향해 달리고 싶다면 여유를 줘야한다고 생각한다. 같은 팀원들이 성장하는 것을 보고 싶지 않다면 그들에게 많은 일을 주고 끊임 없이 문제를 해결하는 것을 지켜보면 된다.
팀 구성원들과 같이 우리의 비전과 방향에 대해 대화하기 위해서 그들에게 비전과 방향에 대해 평소에 충분히 느낄 수 있고 개개인이 그것에 대해 자유롭게 생각할 여유가 필요한 것 같다.
좋은 제품팀은 어떤 것일까
나는 지금 스타트업 회사에서 일을 하고 있고 회사가 달성해야할 중요한 과업 중 하나는 좋은 제품을 만드는 것이다. 좋은 제품을 만들 수 있는 요소 중 하나는 좋은 팀이라고 생각한다. 이번 회고 기간 동안에는 좋은 팀이란 것은 어떤 것인지 나 스스로에게도 질문을 많이 던지고 주위 사람들에게도 종종 물어봤던 것 같다. 정답이란 것이 없는 질문인 것은 알지만 다른 사람들은 어떻게 생각하는지 진심으로 궁금했다.
먼저 내가 했던 생각들에 대해서 정리해보려고 한다.
여기서 좋은 팀의 ‘좋은’이라는 것이 매우 추상적이고 정의하기가 어렵다. 나는 일단 좋은 팀이란 팀을 구성하는 개개인이 똑똑하고 퍼포먼스가 뛰어나다고 했을 때 그 팀을 좋은 팀이라고 말하기는 어렵겠다고 막연하게 생각했다. 왜냐하면 일이라는 것은 혼자하는 것이 아니라 같이 하는 것이기 때문이다.
그렇기 때문에 ‘사람 간의 어떤 것’이 좋은 팀을 구성하는 요소로 들어가야할 거 같았다. 개개인의 퍼포먼스가 전부가 아니라면 다른 것은 개개인을 연결하는 ‘사람 사이’가 남았다고 생각했다.
사람 사이의 어떤 것
‘사람 사이’를 구성하는 것은 개개인들의 다른 사람에 대한 대한 배려, 관심, 이해 그리고 이타적인 마음을 가질 수 있는 것들을 포함하는 것이라고 생각한다. 이런 것들이 없다면 팀은 딱딱한 회색 기계처럼 변하고 한 순간 어떤 압박이 개인이 담을 수 있는 한계치를 넘어버리면 그 기계는 연기를 내며 고장날 것이다.
기계에게 신뢰 따위는 없다. 유기적인 어떤 것도 존재하지 않는다.
제품팀 구성원들은 좋은 제품을 만들기 위해서는 관련된 기술적인 지식들을 많이 알고 고객들에 대해 자세히 아는 것도 중요하지만 ‘사람 사이의 어떤 것’을 중요하게 여기지 않는다면 그것은 반쪽짜리 제품팀이 아니라 그냥 일개 개발자, 기획자, 세일즈맨 혹은 다른 직무를 맡고 있는 사람이라고 생각했다.
<인스파이어드> 에 대한 리뷰를 꽤 미뤄왔다. 작년에 이 책을 다 읽고 정리글을 쓰겠다고 회사에 떠들었는데 어물쩡 넘어가버렸다. 그래서 이 회고글을 기회로 삼아 잠깐 얘기를 한다면 <인스파이어드>는 좋은 제품을 만들기 위해서 개개인이 어떻게 해야하는지 자세하게 설명했던 것 같다. 하지만 지금 생각해보면 팀원들 사이의 유기적인 요소들에 대한 언급은 없었던 거 같아서 아쉽다.
우연히 만난 행운, <테크니컬 리더>
트위터에서 정말 우연히 NPS Problem에 대한 글을 봤고 이 글에서 <테크니컬 리더> 책을 발견했다. 정말 행운은 우연하게 찾아오는 것 같다. 왜냐하면 <테크니컬 리더> 책은 나에게 꽤 깊은 감동을 주었기 때문이다.
이번 글에서 이 책 내용 전체에 대해서 얘기할 것은 아니고 (이 책에 대해서 이야기 하려면 다른 글 한 편을 더 빼야 마땅하다.) 위에서 언급한 ‘사람 사이’에 대해서 생각해볼만한 챕터가 있어 관련 내용에 대해서만 이야기해보려고 한다.
업무 중심의 리더 vs 사람 중심의 리더
소개할 챕터의 시작은 다음과 같은 질문으로 시작한다.
해야 할 일이 있고, 그 일의 성공이 위협받고 있는 팀을 책임지고 있을 때 나는 a. 일을 사람보다 중요하게 생각한다. b. 일보다 사람을 중요하게 생각한다. c. 사람과 일 사이의 균형을 맞춘다. d. 그 상황에서 도망간다. e. 위의 네 가지 모두 아니다.
이 질문은 리더가 흔히 만나는 딜레마를 표현하고 있다. 일이 확실한 결과를 내야 하거나 기한을 맞추지 못하면 자신만이 알고 있는 안좋은 일이 일어나는 상황이다.
모든 사람들이 초과 근무를 해야하거나 일을 끝내기 위해 필요한 일은 뭐든지 하도록 행동한다면, 사람보다 일을 우선으로 생각하고 있는 것이다.
사람들과 그 업무가 얼마나 중요한지 공유하고 있고, 그렇게 함으로써 사람들이 스스로 그 일을 어떻게 할 것인지 결정하도록 행동하고 있다면, 일을 완수했더라도 일보다 사람을 우선으로 생각하고 있는 것이다.
그리고 어떤 일화를 통해 ‘사람보다 일을 우선으로 생각하는 리더’와 ‘일보다 사람을 우선으로 생각하고 있는 리더’에 대해서 소개해주고 있다. 이 책에서 주고 있는 교훈을 정리하면 다음과 같다.
사람을 배려하지 않는 리더는 아무도 따르지 않는다. 하지만 사람 중심 스타일의 리더가 더 나은가하면 꼭 그런 것도 아니다. 아무리 사람들을 배려한다 하더라도 실제로 제시하는 것 없이 그런 척만 한다면 사람들을 붙잡을 수 없을 것이다.
사람과 일은 분리될 수 없다.
우리가 하고 있는 일 중에서 사람들의 미래 가능성을 희생하면서까지 정당화할 수 있을 만큼 중요한 일은 거의 없다고 생각한다. 사람들을 희생시키지 않고서 그 일을 할 수 있는 방법이 없다면 아마 그 일은 해서는 안될 것이다.
만약 일보다 사람을 우선으로 생각한다면 프로젝트가 성공을 거둘 수 있는 기회를 잃을 수도 있지만, 그 프로젝트가 끝나고 잊혀진 뒤에도 사람들은 오랫동안 남아 있을 것이고, 다른 프로젝트를 진행하면서 사람들의 인생에 계속 영향을 미칠 수 있을 것이다.
그렇다면 당장의 실패가 성공을 거둘 수 있는 기회를 잃는 것이 아닐 수도 있다.
저자는 복잡한 기술 업무에서 업무와 사람을 분리하는 것은 옳지 않다고 말한다. 일이 계획대로 진행되지 않을 때 사람들의 적응성만이 일을 헤쳐나갈 수 있다고 보고 있다.
또한 일이 복잡한 경우에 계획이 항상 어긋나지 않는다고 단정할 수 있는 사람은 없기 때문에 사람을 먼저 고려하지 않을 수 없다.
위의 질문의 정답은 e라고 생각하고 있다고 저자는 말한다. 일이 복잡할 때 사람이 먼저인지 일이 먼저인지 선택할 수 없기 때문이다. 사람과 일을 분리하는 것 자체가 불가능하기 때문이다.
저자가 했던 말을 빌리면 일은 언제나 사람과 연관이 있다. 우리는 관념적인 이로움을 위해 일하는 것이 아니라 어떤 사람을 이롭게 하기 위해 일한다.
다시 말해 우리는 세상의 어떤 평화를 위해 일하는 것이 아니라, 어떤 사람이 평화로운 삶을 즐길 수 있도록 하기 위해 일하는 것이다. 그 사람이 고객일 수도 있고 관리자일 수도 있고 우리 제품팀의 구성원일 수도 있으며 경영진일 수도 있다.
사람과 일을 구분할 수 있다고 믿는 것은 착각이라고 말한다. 그것은 사실 한 그룹의 사람들과 다른 그룹 사람들 사이의 선택을 부정하기 때문이다.
예를 들어 “주주들이 배당을 불만스러워 하고 있기 때문에 여러분의 아이디어를 실행할 수 없습니다.”라고 말하는 것보다 “예산을 지켜야 하기 때문에 여러분의 아이디어를 실행할 수 없습니다.”라고 말하는 것이 더 쉽다.
이렇게 스스로에 의한 왜곡때문에 문제를 올바로 정의할 수 없게 된다. 그리고 다른 사람들이 이 문제를 해결할 기회를 뺏는다. 그렇기 때문에 업무의 배경에 사람이 있다는 것을 간과하면 절대 올바른 문제 해결을 할 수 없는 사람이 된다.
문제 해결형 리더로 성공하려면, 모두가 사람이라는 사실을 가장 중요하게 생각해야 한다. (중략) 만약 당신이 리더라면, 사람에 대한 것이야말로 당신의 일이다. 그 외에 해야 할 가치 있는 일은 없다.
<테크니컬 리더>
결국은…
<테크니컬 리더>와 이전에 내가 생각했던 것처럼 사람 사이의 무언가가 중요한 것 같다. 그것은 배려일 수도 있고 다른 무언가가 될 수도 있다. 배려라는 것도 사실 추상적이고 배려하는 대상이 어떤 사람이냐에 따라 배려의 구체적인 항목이 천차만별로 달라진다.
어떤 사람에게는 금전적인 보상이 될 수 있으며 다른 사람에게는 나와 끝까지 같이 갈 것이라고 믿음을 보여주는 것이 배려가 될 수도 있다.
이것은 한 가지 정답이 있는 것이 아니라 상대방과 지속적으로 진솔한 대화를 통해 풀어나가야하는 것 같다. 이를 위한 구체적인 방법으로는 <테크니컬 리더> 책에 소개되어있는데 이는 다음 포스팅에 기회가 된다면 정리를 하겠다.