[HBR 독후감] 애자일 이야기

HBR 한국판이 있습니다. Harvard Business Review라는 꽤 유명한 경영월간지인데, 필자는 지난 15년간 개발자 출신 IT 컨설턴트였던지라 띄엄띄엄 여력이 있을 때마다 한글판을 사서 보곤 했습니다. 그런데 어느 때부터인지 한국판은 격월간으로 나오고, 또 대형 서점에 가보면 눈에 안 띄는 매대로 점차 밀려나고 있음을 확인할 수 있었습니다. 직원을 부르지 않고 찾으려면 상당한 탐색 노하우(?)가 필요할 정도입니다.

좋은 내용이 많은데 읽히는 사람이 없다는 사실을 확인했으니 제가 흥미를 느껴 읽고 느낀 부분에 대해서라도 소개해서 유익한 내용에서 얻은 영감을 많은 분들이 업무 현장에서 활용하실 수 있기를 기대하며 글 연재를 시작합니다. 첫 시작은 3/4월 통합본에 나오는 애자일 관련 기사 소개 혹은, 해당 기사 여섯 편을 읽고 느낀 바를 정리했습니다.

 1. HR, 애자일을 도입하다

무려 간판 성격의 기사 제목이 이렇습니다. 여러분이 서비스 회사 소프트웨어 개발자^[1]라면 자부심을 가져도 좋을 것 같습니다. 기사 말미에 있는 강조 문단을 먼저 소개하겠습니다.

IT업계가 HR에 주는 교훈 IT업계에서 애자일 방법론을 가장 먼저 도입한 기업은, 애자일을 대규모로 적용하는 데 다른 기업들보다 몇 년 앞서 있다. 그런 점에서 IT업계 종사자들이야말로 애자일 인재관리 방법을 기업 전체에 적용하기 위해 분투하는 관리자와 HR 리더에게 좋은 길잡이가 돼 줄 적임자가 아닐까?

조금 더 기사 내용에 대해 소견을 공유하겠습니다. 경영의 핵심이기도 하고 많은 분들이 보수적인 사람들이 모여있다고 말하기도 하는 인사(HR) 영역에서 애자일에 관심을 갖는 이유는 이렇습니다.

"속도가 업계의 새로운 트랜드"가 됐다. - BMO 린 로저 최고변화책임자

개인적으로 기사 중에 가장 흥미로운 내용은 '더 자주, 더 많은 사람에게, 더 많은 성과 피드백'을 다루는 내용입니다. 통상 전통 기업의 피드백은 관리자가 마치 시험점수 알려주듯이 직원에게 통보하기 마련인데요. 마치 감시자 같은 그런 피드백이 아니라 코칭과 같은 식으로 개별 훈련 방안와 업무 제안을 해주는 것이 하향식 피드백의 한 예입니다. 실천을 위해서는 '섬기는 리더십' 역량을 가진 관리자가 필요하다는 어려운 제약이 있습니다. 한편, 다음과 같은 상향식 피드백도 다뤄집니다.

애자일 조직은 직원들이 팀 리더에게 보내는 '상향' 피드백을 중요하게 여긴다. 그러나 직원들이 경영진에 대한 자기 생각을 말하는 데 익숙하지 않기 때문에, 각별히 노력해야 한다.

2. 저성과자, 어떻게 관리해야 할까?

아래는 해당 기사를 읽다가 펜으로 잡지에 쓰며 창작한 팀원 평가함수입니다. 평가 방법(How to)가 결과(return value)는 제가 알 수 없지만, 저자들(제이 A. 콩거, 앨런 H. 처치)에 따르면 세 가지 변수로 팀원 평가를 한다고 합니다.

팀원 평가 함수 정의

• 자기 업무에 맞는 역량을 갖췄나?
• 업무에 필요한 추진력과 새로운 기술을 익히려는 의지를 갖고 있나?
• 상사는 물론이고 팀원들과 건설적인 사내 관계를 맺을 수 있나?

기사 저자는 HBR 독자들을 향해 이렇게 말합니다.

좋든 싫든 저성과자를 해고하는 기술을 연마해야 한다. 다른 사람이 당신의 일을 대신해서는 안된다.

머리로는 이해하지만, 싸늘한 느낌이 드는 것은 어쩔 수 없습니다. 그외에 두 가지 더 흥미로운 내용이 있었습니다. 하나는 대인관계기술이 부족한 사람을 제대로 평가하지 않으면, 그와 함께 일하는 다른 직원이 속으로 이런 생각을 할 수 있다는 것입니다.

내가 이 사람 밑에서 얼마나 의욕을 잃고 일하는지 안 보이나?

다른 하나는 저성과자에게 알맞은 업무를 찾아주어 그들에게 활기를 찾아주는 일이 필요한데, 그럴 경우 딜레마가 기다리고 있다는 것입니다.

딜레마는 이들이 싫어하거나 할 수 없는 일을 누구에게 주느냐다.

3. 승진 면담의 기술

승진 면담 노하우를 다룬 기사도 있습니다. HBR은 대학 이름이 들어간 브랜드의 잡지이지만, 상당히 실용적인 내용을 다루고 있습니다. 기사 중에서는 승진을 요구하기 위해 기억해야 할 내용을 잘 정리한 점검표가 눈에 띕니다.

• 내가 원하는 자리를 생각하고, 이 자리가 조직 및 지속상사의 목표에 부합하는가를 생각하라.
• 나의 성취를 분명하게 보여주고, 내가 어떤 영향력이 있는지 지표가 되어 줄 메모를 작성하라.
• 가끔씩 상사에게 승진에 대해 피드백과 조언을 구하라.
• 승진 요청을 하면 한 번에 결정될 것이라고 생각해서는 안 된다. 지속적으로 대화를 이어 나가는 것이 중요하다.
• 외부에서 받은 이직 제의를 무모하게 이용하지 말라. 사내 관계에 부정적 영향을 끼칠 확률이 높다.
• 바로 승진되지 않는다고 해서 실망하지 말라. 인내심을 가져라.

실적 이력서 쓰기 사례가 공유되어 있는데, 나 스스로도 따라할 자신이 없는 내용을 소개하고 싶지는 않아 생략합니다.

4. 회사를 그만두는 진짜 이유

도입부에 '직장이 아니라 상사를 떠난다'^[2]는 말을 합니다. 진짜 회사를 그만두는 이유는 다른데 있는데 많이들 오해하고 있다는 연구 결과를 소개합니다. 그리고, 관리자들이 인재를 붙잡아 두기 위해서 기억해야 할 세 가지 주안점을 제시합니다.

• 즐거운 업무를 구상하라
• 보이지 않는 강점 찾기
• 일과 삶의 균형잡기

첫번째 주안점 관련해서는 아래 내용이 눈에 띕니다.

직원들이 어떤 일을 좋아하는지 관리자가 잘 모르는 경우가 많다. 퇴사 인터뷰를 통해 뒤늦게 알아낼 뿐이다. <중략> '엔트리 인터뷰'를 구상했다. 입사 첫주에 신입사원과 마주 앉아서 지금까지 가장 좋았던 프로젝트, 회사에서 가장 열정을 발휘했던 순간, 어떤 것에 완전히 몰입했던 상황, 퇴근한 뒤 의욕을 갖고 하는 일 등에 대해서 이야기를 나눠보는 것이다. 관리자는 대화를 통해 얻은 정보를 바탕으로 신입사원을 처음부터 세심하게 챙길 수 있다.

두번째 주안점 관련해서는 아래 내용에 색칠을 하며 보았습니다. 관리자가 방향을 제시하며 직원들의 탐색 과정을 도와야 한다는 맥락에서 인용한 연구 결과입니다.

연결된 사회에서는 정보를 찾고 공유하는 일이 업무의 대부분을 차지한다. 지식노동자들은 정보를 검색하는 데 자기 시간의 4분의 1이상을 할애한다는 연구조사도 있다.

세번째 주안점에서는 필자가 팀장 시절부터 실천하려고 노력했던 내용이 가장 눈에 들어왔습니다.

탁월한 상사는 방패를 만들어 직원들을 나쁜 환경에서 보호한다.

직원 경험 함께 만들기

글로벌 회사 IBM^[3]의 저력을 확인할 수 있는 내용입니다. 내용 자체가 혁신적이라고 보긴 어렵지만, 공룡회사가 저렇게 할 수 있다는 사실 자체가 놀라웠습니다. HR 부서에서 직원 경험을 함께 만들려는 노력을 한다는 일 자체가 이상적으로 들립니다. 다시 말해, 우리나라의 기성 기업에서 가능한 일일까 싶다는 생각이 든다는 것이죠. 경험을 함께 만든다는 말은 어떤 점에서는 XP의 Pair Programming^[4]에 비유할 수 있는 멋진 행동입니다. 상세한 내용은 오히려 그들의 솔루션과 특수성과 강하게 연결되어 있어서 응용하기 수월치는 않아 보입니다.

애자일 팀 실험에 나선 은행

ING 소매금융업무의 사례라는데, 우리나라 은행과 비교하긴 매우 어렵습니다. 2006년에 유럽에서 했던 자바 컨퍼런스에 참여한 일이 있는데, 그때 먼저 말을 건 개발자가 있었습니다. 그는 스웨덴 은행에서 일했는데, 당시는 상당히 진보적 프로그래밍 기법이었던 Dynamic Proxy를 은행업무에 적용하려 한다고 말해 깜짝 놀랐습니다. 그들과 우리의 은행 문화가 다름을 알았고 잊고 살았는데, 그들의 사례는 놀랍습니다. 너무 넘사벽의 이야기라 보편성을 띈 아래 이미지만 찾아 공유합니다.

출처: HBR Korea 웹사이트

주석

[1] 외주 개발을 주로 하는 개발자라면 HBR에서 언급하는 애자일과는 거리가 있는 생활을 하고 있을 가능성이 높습니다.

[2] 최근 저와 협력관계로 잠시 일을 하셨던 한 중간 관리자도 퇴사를 하셨는데, 제가 짐작하는 이유는 상사인 듯 합니다. 안타까운 일입니다. 하지만, HBR 내용을 보니 비단 우리나라 기업만의 문제가 아니라는 안도감(?)을 줍니다.

[3] 한국 IBM은 조금 다른 듯합니다. 많은 숫자는 아니지만, 제가 경험했던 한국 IBM 직원 전원은 혁신과는 상당히 거리가 있고 대체로 권위적인 태도와 성향을 갖고 있었습니다.

[4] 부연 설명이 필요할 수도 있겠다는 생각이 듭니다만, 독자님들 중에서 소프트웨어 개발자가 아닌 어떤 분이 설명을 명시적으로 요구하시면 그때 이를 설명하는 글을 쓰겠습니다.