실리콘밸리에선 어떻게 일하나요

발췌

메타의 조직문화를 설명하는 대표적인 키워드는 보텀업, 동등함, 공유, 인간중심이다. 비전, 즉 회사의 방향성에 대한 큰 그림은 위에서 정하지만 그 비전을 달성하기 위해 필요한 제품이 무엇인지 정하고, 그것을 만들어가는 과정은 거의 전적으로 직원들에게 일임한다 (…) 하지만 제품 제작과정은 애플만큼 깔끔하지 않을 수 있다는 단점도 존재한다. 많은 사람들의 의견과 다양한 피드백이 오가다 보니 결정 과정이 단순하지 않고 에너지도 더 많이 소비되는 편이다. 하지만 이 과정에서 모두에게 혁신과 변화에 기여할 기회가 주어진다.

• 성장 마인드 셋과 학습 목표

  • 어떤 일에서든 실수나 실패가 발생하는 건 어쩔 수 없다. 특히 경험이 다소 적은 팀과 팀원들이 보텀업 방식으로 일을 하면 회사나 함께 일하는 사람들이 불안함을 느낄 수도 있다. 그래서 더더욱 실패를 정상적인 과정으로 받아들이고, 계속해서 고민하고 시도할 수 있는 환경을 조성하는 것이 매우 중요하다.

  • 이른바 성장 마인드셋 growth minset 문화를 만드는 것이다.

  • 예컨대 새로운 프로젝트를 계획할 때 정량적인 성과 지표 뿐만 아니라 학습 목표learning goal를 세운다. 그리고 결과가 실패로 끝났더라도 초기에 의도한 것을 배우게 되면(즉, 학습 목표를 달성하면) 성공이라 판단한다. 실제로도 이러한 지식 하나 하나들이 모여 훗날 유사한 프로젝트를 진행할 때 회사가 전략을 세울 때 도움이 된다. 실패가 아닌 상당히 가치 있는 공헌인 셈이다. 이처럼 실패를 통한 배움으로 인해 ‘성장했다’고 여기는 개념이 바로 ‘성장 마인드셋’이다.

• 실무자가 주도권을 많이 잡고 일하는 문화일수록 실력과 책임감이 강한 직원을 고용하는 것이 중요하다. 조직이 어느 정도 성장하면 직급이 골고루 분배가 되어야겠지만, 팀을 초기에 구축하는 단계라면 책임감이 강하고 경력이 있는 시니어 직급을 먼저 고용한다. 그들에게 어려운 전략을 맡기고 이후 그 일을 도울 직원들을 뽑는 것이 좋다. 시니어 직원들이 주도적이고 책임감 있는 보텀업 엄무 방식을 몸소 실천할 때 조직 전체에 걸쳐 좋은 문화를 전파하고 유지하는 일이 쉬워진다

• 보텀업 사례: 신입사원의 아이디어로 탄생한 ‘텍스트 필터’ 기능

  • 당시 우리 팀의 목표는 측정 가능한 직표 관점에서는 뉴스피드 상의 게시물 증가였고, 질적 지표 관점에서는 게시물 증가에 따른 장애물 제거(문제 해결 관점)와 목적 달성의 수월함(가치 부여 관점)이었다.

  • 이 사례에서 강조하고 싶은 메시지를 정리하면 다음과 같다.

    • 성장 마인드셋

    • 데이터 기반의 접근 방식

    • (중략)

  • 결과적으로 텍스트를 꾸미는 필터 기능이 탄생했다. 흥미로운 사실은 과거 이와 비슷한 아이디어가 이미 나 말고도 다른 디자이너들을 통해 몇 번 언급되고 시도됐다는 점이다. 나도 나중에 들은 이야기다. 하지만 아이디어를 제시했던 디자이너들은 바로 앱스토어에 출시해도 될 정도의 높은 퀄리티의 프로토타입을 선보이며 사람들의 마음을 사로잡으려 했다. 문제 접근법 자체가 달랐던 것이다. 아무리 같은 보텀업의 방법(가설 내용, 테스트 디자인, 팀을 설득하는 스토리텔링)에 따라 프로젝트의 방향과 성공률이 달라질 수 있음을 나는 이 일을 통해 배웠다.

• 데이터의 궁극적인 목적은 우리가 디자인하고 출시하려는 기능들이 가치가 있을지에 대한 답, 그리고 출시 후 그 기능들이 잘 사용되고 있는지, 문제를 일으키지는 않는지, 어떻게 발전시킬 수 있는지에 대한 답을 얻기 위한 것이다.

• ‘이 세상 모든 것이 가능하다면 어떤 일을 하고 싶은지’를 그려보도록 했다. 리더의 지시와 방향을 기다리는 데 익숙해져 있는 새로운 팀원들에게 이 질문을 던지면 처음엔 그날의 나처럼 눈이 휘둥그레지며 당황하겠지만 결국엔 자신의 생각을 잘 정리해서 가져온다

• ‘기회’를 마련해줌으로써 직원들이 완성된 시나리오perfect scenario를 떠올리고, 이를 리더와 공유할 수 있는 환경을 조성하기 위함이다.

• 2018년 어느 날, 회사의 최고제품책임자(CPO)가 발전 속도가 빨라짐에 따라 놓치기 쉬운 세부요소(UX 디테일, 중복성이나 디자인 패턴 따르기 등)의 중요성을 강조하며 이에 대한 개선을 요구했다. 늘 그랬든 비전에 잡혀지고 난 후 그것을 달성하는 방법은 팀원들 스스로 구상해야 했다.

• 그때 디자이너들이 공통적으로 호소하는 불평 사항 하나가 눈에 들어왔다. 우리가 사용하는 대부분의 앱에는 직원이 코딩 실수가 문제점 등을 발견했을 때 이를 신고할 수 있는 기능이 있는데, 그걸 버그 리포트라고 한다. 신고 내용들은 해결해야 할 업무, 즉 태스크로 자동 전환되어 회사 내의 엔지니어들에게 전달된다. 그러면 엔지니어들은 이 태스크 리스트를 보며 중요도가 높은 것부터 낮은 순서로 하나씩 버그를 수정한다.

• 문제는 상대적으로 덜 심각한 UX 문제들을 우선순위에서 밀려다는 것이었다. 하지만 이제는 디자인 UX도 중요도가 낮은 문제로 취급하지 않겠다는 것이 CPO의 각오였다. 그것을 직원 전체의 참여와 행동 변화로 이끌 제도가 아직 만들어지지 않은 것이 문제였다.

• #sux라는 해시태그를 넣어 이 태스크들만 따로 모아 볼 수 있으며 디자이너들이 퀄리티의 심각성에 따라 우선순위를 높일 수 있도록 한 것이다. 그 해시태그가 담긴 태스크들은 디자이너들에게 바로 전달되어 우선순위를 그 자리에서 표기할 수 있도록 했다.

• 이 제도를 위해서 심각성의 3단계 높음, 중간, 낮음을 각각 정의하고 문서화해 이 기준에 따라 디자이너들을 훈련시켰다. 이렇게 검색팀에서 시작된 이 프로그램이 결국엔 다른 팀들에게도 전파되어 널리 퍼져 나갔다.

• 메타에선 이런 식의 사례가 정말 많다. 조직의 리더가 앞으로 개선되어야 할 심각한 문제들과 도달해야 할 목적지를 정의하고 나면 거기에 어떻게 도달할지에 대해선 업무를 실질적으로 담당하는 현장의 직원들에게 전적으로 맡겼다. 그렇게 업무와 가장 밀접하게 연관된 사람들의 의견을 통해 아이디어와 해결책이 제시되면 그것이 한 조직, 두 조직으로 퍼지고 나아가 더 확장되면서 회사 전체의 제도로 자리 잡았다.

• 사실이 #sux 제도 도입 당시 나의 공식적인 직책인 ‘프로덕트 디자인 팀장’이었고 직원들의 업무 개선을 위해 프로그램을 개발하는 것은 나의 주 업무는 아니었다.

• (…) 훨씬 효율적이기 때문이다. 그런 이유로 메타에서는 이러한 프로그램 디자인 개발도 외부 사용자들에게 론칭하는 제품의 실적 만큼이나 큰 임팩트로 취급한다. 이런 식으로 계속해서 직원들에게 회사 내 문제들을 능동적으로 해결할 수 있는 환경과 동기를 부여한다.

• 팀장의 위치에 오른 뒤 디자이너들에게 필요한 개선점들에 대해 의견을 말할 때면 나는 이렇게 대답하곤 한다. “(…) 근데 혹시 해결책에 대해서도 생각해봤을까요?” 역으로 질문한다. 문제점 제시와 함께 해결책도 같이 생각해볼 수 있는 사고를 길러주기 위해서다.

• sux에는 두 가지 뜻이 함께 담겨있다. ‘sucks(구리다)’의 줄임말인 동시에 검색 디자인 팀에서 시작되었기 때문에 Search의 ‘S’, UX의 ‘ux’를 합쳐 sux가 탄생됐다.

피드백 문화

• COO였던 셰릴 샌드버그가 매년 회사의 전체 팀장들을 대상으로 진행하는 리더십 강의에서 했던 말이다. 문제점들을 발견하고도 침묵하는 직원들이 하나둘씩 생겨나기 시작하면 제아무리 대단한 회사도 무너질 수 있을 만큼 피드백 컬처는 회사의 존폐를 결정짓는 매우 중요한 요소다. 그리고 피드백을 중요성을 알고도 과거 그 많은 회사가 사라진 이유는 그만큼 솔직한 피드백 컬처를 조성하는 것이 어렵기 때문이라고 했다.

• 직원과 직원 간의 의견차이도 마찬가지다. 배경과 관점이 전혀 다른 사람이 처음부터 완벽하게 협업하기란 거의 불가능하다. 이때 협업의 가능성을 높이는 것이 바로 피드백 컬처다. 과정은 다소 어렵지만 모두에게 이상적인 결과를 가져오는 것을 나는 수도 없이 목격했다.

• 무언가 잘못됐다면 잘못됐다고, 또 좋으면 좋다고 말할 수 있다는 자율적인 조직의 분위기가 내 개인의 가치관과도 참 잘 맞았다.

• 피드백의 궁극적인 목적은 단순히 문제점을 제기하는 데 그치지 않고(회사건, 제품이건, 사람이건) 어떻게 하면 더 큰 앰팩트를 달성할 수 있는지에 대한 ‘제안’을 하는 것이다. 그래서 메타에서는 약점weakness이라는 말을 쓰지 않고 대신 성장 영역growth area이라는 말을 써서 모든 피드백을 성장의 기회와 수단이라고 여긴다.

• 좋은 피드백의 다섯 가지 원칙

  • 투명성, 시의성, 공정성, 친절함, 실행가능성

• 담당자는 때로 세부적인 사안에 집중한 나머지 샛길로 빠지거나, 반대로 신경 쓸 부분이 너무 많아 디테일에 소홀해 질 수 있기 때문이다. 그러므로 제3자나 새로운 관점의 피드백은 꼭 필요하다.

• 메타에서 자주 듣는 말 중 하나는 “직원은 회사를 떠나는 것이 아니라 상사를 떠난다.”였다.

• 가장 어려운 피드백은 부하직원이 상사에게 피드백을 주는 것이다. 이것이 제대로 이뤄지지 않으면 앞서 샌드버그가 말했던 회사의 ‘종말’을 가져올 수 있다. 물론 쉽지 않은 일이지만 그렇기에 더욱 중요하다. 상사에게도 눈치보지 않고 피드백을 할 수 있는 좋은 피드백 컬처가 활성화되고 지속되려면 리더가 먼저 꾸준하게 솔선수범을 보여야 한다.

• 임팩트 위주로 피드백한다. 많은 사람들이 피드백을 줄 때 ‘아무개가 무엇을 한다’는 식으로, 즉 행동 위주로 피드백을 하는 경향이 있다. 하지만 임팩트에 포커스를 맞춰 피드백을 주는 것이 중요하다. 예를 들면 ‘아무개의 어떠한 행동(x) 때문에 어떠한 임팩트(y)가 생긴다. 그러므로 그러한 결과가 생기지 않도록 이러저러한 다른 행동(z)을 할 것을 추천한다’라는 식으로 말이다. 이렇게 ‘결과’를 분명히 짚고 넘어간 다음 그 결과를 변화시키기위한 ‘방법’을 함께 이야기해 주는 것이 좋다.

• 피드백을 받아들이는 데도 기술이 필요하다

  • 경청하기

    누군가의 말을 집중해서 쭉 듣기란 의외로 정말 어렵다. 중간에 변명이나 반응을 하고 싶어 입이 근질거려도 이 시간은 ‘피드백을 듣는 시간’이라고 생각하며 꾹 참고 일단 그냥 듣도록 한다.

  • 요점 이해하기

    피드백의 내용을 정확히 이해하기 위해 피드백의 요점을 반복해 생각하면서 자신이 이해한 내용이 옳은지 직접 물어보면서 확인한다. “당신의 피드백을 ~ 라고 이해했는데, 나의 이해가 맞나요?”

  • 감정 정리하기

    피드백을 듣는 동안 떠오르는 여러 감정들에 바로바로 반응하지 않는다. 어려운 피드백을 받다 보면 마음속에서 복잡한 감정들이 일어나기 마련인데 여기에 바로 반응하지 말고 다음과 같이 마무리한다. “정리할 시간이 필요해서 이에 대한 응답은 나중에 준비가 되면 하겠다. 일단 피드백을 줘서 고맙다.”

  • 시간을 갖고 되돌아보기

    어려운 피드백을 받았다면 일단 감정이 가라앉기를 기다린다. 그 후 피드백을 혼자 또는 주변의 도움을 받아 복기해본다. 회사의 HR팀에 부탁을 하거나(HR팀을 신뢰할 수 있는 경우) 멘토를 찾아가 코칭을 받는 방법도 있다.

  • 피드백의 심각성 이해하기

    내가 받은 피드백이 예외적으로 딱 한 번 나타난 것인지, 아니면 주변 사람들 대부분이 인지할 정도로 반복적으로 나타나는 패턴인지 동료들에게 묻고 확인한다. 예컨대 ‘내가 이런 피드백을 받아서 개선할 방법을 찾고 있는데 혹시 당신도 느끼고 있던 점인가’ 하고 물어보는 것이다. 이때 ‘개선하기 위해’ 또는 ‘배움을 위해’라는 의도를 표현하는 것이 가장 중요하다. 그런 의도가 표현되지 못해 상대가 자칫 당신의 질문을 위협으로 받아들이면 솔직한 답을 받기 어려울 수 있다.

  • 의도와 전달을 분리하기

    만일 피드백의 내용이 오해에서 비롯된 것이더라도 나의 의도를 전달하는 방법에 문제가 있었다는 뜻이니 그 역시도 타당한 피드백으로 인정한다. 이를테면 ‘난 그런 뜻이 아니었어!’가 아닌 ‘내 의도가 제대로 전달되지 못했구나. 전달 방법을 개선해야겠다’라고 프레임을 바꿔본다.

  • 혼자 말고 도움을 받으며 개선하기

    감정이 정리되고 개선 방법도 찾았다면 주변 동료들에게 일대일로 또는 공개적으로 개선 의지를 표출한다. 그리고 개선 계획에 대한 피드백을 요청한다. 이런 식으로 많은 사람들의 도움을 받을 수 있으면 개선의 속도도 더 빠를 뿐만 아니라 신뢰도 더 쌓이게 된다.

  • 먼저 습관적으로 피드백 요청하기

    평소에 주변 동료들이나 상사에게 자주 자신의 업무나 언어, 행동 등에 대한 피드백을 먼저 요청하는 습관을 기른다.

• 상사도 칭찬해 주세요

• 프로덕트 퀄리티와 관련된 피드백 ‘어떻게 만드는가?’

  • 디자이너는 미리 참석자들에게 다음과 같은 정보를 제공하고 그에 맞는 피드백을 구한다

    • 디자인 목표

    • 목표 달성을 위한 해결책 옵션(가설들)

    • 지금 고려하고 있는 디자인 옵션

    • 필요한 피드백

  • 디자인 리뷰 항목들에는 프로덕트 씽킹, 사용성, 시각 디자인 등이 있으며 피드백을 요청하는 디자이너는 자기가 가장 필요로 하는 피드백이 무엇인지 정확히 요구해야 할 책임이 있다. 예를 들어 해결책 옵션을 고민하고 있는 시점에서 비주얼 디자인 피드백은 시간 낭비나 다름없다. 또한 이러한 피드백 문화를 잘 정착시키기 위해 신입 디자이너 교육 프로그램을 비롯해 디자이너 커뮤니티에 관련 내용들을 공유하며 발전시킨다.

• 단순히 피드백을 모아 전달만 했을 뿐 나의 억양이나 태도가 실제로 팀과 성과에 미치는 영향(비난이 아닌 임팩트 위주의 설명)을 제대로 전달하지 않았기 때문에 사적인 공격처럼 느껴졌을 수도 있고, 피드백의 가장 중요한 요소인 ‘개선점에 대한 의견’이 빠졌다고 잘못을 시인했다. 그 후 우리는 앞으로 이를 어떻게 개선해야 할지에 대해 함께 이야기를 나눴고 즉각 행동에 들어갔다. 일단 다는 함께하는 팀원들 모두와 일대일 미팅을 하면서 내가 받은 피드백에 대해 공유하고 고마움을 표했다.

• 이번 에피소드는 상사로서 부하직원이 받은 피드백의 타당성을 체크하는 계기가 되었던 사건이다. (…) 그는 기술적인 지식이 강한 엔지니어였지만 프로덕트 씽킹 부분에서는 사용성 관점보다 기술 중심으로 프로덕트를 기획하려는 경향이 강했다. 이럴 때 사용자의 입장에 서서 프로덕트의 전체적인 완성도를 위해 반론을 제기하는 것이 디자이너의 의무였고 마리아가 한 핸동은 옳았다.

플랫 컬처의 원칙

• 플랫 컬처가 성과로 연결되려면 일단 프로젝트를 시작할 때 모두에게 기회와 참여권을 주어 다양한 아이디어와 피드백을 수집해야 한다. 그다음 최대한 객관적인 결정 구조를 통해 목표를 달성한다. 시작할 때는 동등하게 기회를 주더라도 최종적으로는 성과에 직접 기여를 한 사람과 하지 못한 사람은 냉정하게 구분할 필요가 있다. 그래야 업무의 성과도 보장하고 유능한 직원의 동기부여도 계속 유지시킬 수 있기 때문이다.

• 직책을 세분화하지 않는다

  • 메타의 직책 가운데 하나인 PM, 즉 프로덕트 매니저를 예로 들어보자. 실리콘밸리 회사에서는 흔희 프로덕트 전략을 짜는 책임자를 뜻하는 ‘프로덕트 매니저’와 기획 및 실행의 책임자를 일컫는 ‘프로젝트 매니저’가 세분화되어 따로 존재한다. 하지만 메타에서는 프로덕트 매니저를 일컫는 PM이 그 두가지일을 동시에 맡는다.

  • 이렇게 직책을 일반화함으로써 자신의 강점이나 선호도에 따라 공헌할 수 있는 부분을 조금 더 유연하게 정의할 기회를 주는 방식이다. 예를 들어 한 팀에 디자이너가 두 명이 있으면 개인의 강점에 따라 어떤 디자이너는 제품 전략이나 인터랙티브 디자인에 더 집중을 하고 다른 디자이너는 비주얼 부분에 더 집중을 할 수 있다. 공식적으로는 둘 다 같은 책임이 있으니 ‘개인의 선호도와 팀 구성원에 따라 자율적으로 역할을 정의하고 협업하라’는 것이 메타의 방식이다

• 직책의 레벨을 공개하지 않는다

  • 메타도 다른 글로벌 기업들처럼 IC3~7로 시스템상 직급 레벨이 존재한다. 하지만 이를 공개적으로 드러내 사용하지는 않는다. 본인과 팀장만이 서로의 레벨을 알 뿐이다. 시니어든 주니어든 모든 프로덕트 디자이너는 직책이 같고, 모든 소프트웨어 엔지니어로 직책이 같다. 서로의 레벨을 모르는 상황에서 일하기 때문에 더더욱 모두의 의견을 같은 크기로 존중할 수 있는 것이다.

  • 물론 경력이 많고 다양할 수록 업무의 퀄리트가 높을 수는 있다. 하지만 경력이 훨씬 적은 팀원의 아이디어가 더 높은 퀄리티를 보이는 경우도 엄연히 존재한다. 그런 이유로 메타는 개인의 직책이나 경력보다는 객관적으로 합의한 결정 구조에 따라 ‘최선의 아이디어’를 가리는 것이 가장 좋은 결과를 낳는다고 믿는다. 이렇게 직책이나 레벨에 신경 쓰지 않는 분위기를 조성하면 아이디어 자체에 집중할 수 있고 유연하게 협업함으로써 결과적으로 일의 성과도 높일 수 있다.

  • 메타는 개인의 직책이나 경력보다는 객관적으로 합의한 결정 구조에 따라 ‘최선의 아이디어’를 가리는 것이 가장 좋은 결과를 낳는다고 믿는다.

• 리더십의 개념이 다르다

  • 메타에서 PM은 의사결정자가 아니라 사회자에 가깝다. 최종 결정을 내리는 사람이 아닌 팀이 함께 좋은 결정을 잘 내릴 수 있도록 이끄는 사회자라고 보면 된다. 따라서 팀장이 아이디어를 내고 팀원들이 그것을 실행하도록 리드하는 것이 아니라, 팀원 모두의 아이디어를 수집하여 그중에 최선의 선택을 할 수 있도록 그 ‘절차’를 리드하는 것이 PM의 책임이다.

  • 상사의 개념도 마찬가지다. 메타에선 매니저 혹은 팀장이 ‘윗사람’이라는 개념보다는 파트너나 서포터라는 개념이 강하다. 애플의 경우 매니저가 과제의 방향을 지시하지만 메타의 매니저는 직원 스스로 방향을 찾도록 피드백이나 다양한 옵션들을 제공한다. (…) 예를 들어 충분히 매니저가 될만한 경력과 성과를 갖고 있지만 자신의 선택에 따라 실무 영역에서 전문가로 활동하는 직원(Senior IC)은 더욱 자율적으로 일하면서 매니저와 수평적인 파트너십의 개념으로 일을 한다.

• 같은 기회를 주고 의사결정권을 준다는 것은 그만큼 논쟁이나 갈등이 생길 여지도 많다는 뜻이다. 하지만 이런 조직문화를 여러 해에 걸쳐 실ㅈ네로 경험해본 나는 이 플랫 컬처가 여러 면에서 훨씬 더 나은 결과와 과정을 보장했다고 믿는다.

• 플랫 컬처에서는 모두가 PM의 기본 책임인 전략과 리더십을 조금씩 나눠 갖고 있는데, 바로 이 점이 팀 전체를 성장시키고 성과를 향상시키는 요인이라고 할 수 있다. PM에게 전적으로 책임을 지우고 의존하는 것이 아니라 모두가 ‘PM의 모자를 씀wear PM’s hat’으로서 팀원들의 능동적으로 일을 해결하고 다 함께 성장하는 등 여러 이득을 경험하는 것이다.

• 잠재적 문제

  • 목소리 큰 사람이 이길 수 있다. 플랫 컬처에서 종종 문제가 되는 부분은 바로 목소리 큰 사람이 이길 수 있다는 점이다. (…) 단순히 목소리가 큰 사람일 수도 있고, 새로 온 사람보다 이미 회사의 어려운 용어들과 조직구조를 잘 아는 사람의 의견일 수 있다. 또는 쇼맨십과 프레젠테이션 능력이 출중한 사람의 의견일 수 있다. 우리는 모두 인간인지라, 나도 모르는 사이에 암묵적인 편견에 영향을 받거나 시각적인 부분들에 휩쓸려 타당하지 않은 의견을 옳다고 판단하기도 한다. 이런 실수를 피하기 위한 몇가지 팁이 있다. (자세한 내용은 생략)

  1. 정보를 동등하게 제공하기

  2. 충분한 준비 시간 주기

  3. 말보다 글 활용하기

  4. 쉬운 용어 쓰기

  5. 경청 훈련하기

  6. 무의식적인 편견에 빠지지 않도록 훈련하기

• 모든 책임과 기대치를 문서화한다

  • 직책이 일반화되어 있고 개인의 의도에 따라 역할과 기여도를 유연하게 정의할 수 있는 플랫 컬처일수록 기대치를 문서화하는 일이 더욱 중요하다. 각 팀의 PM 또는 팀장은 프로젝트를 시작할 때 구성원의 의견과 의도를 정확히 이해하고 그들의 역할과 책임R&R을 문서로 적어놓아야 한다. 그래야 오해나 생각지 못한 일이 발생했을 때, 언제든지 그 문서를 참고하여 문제를 해결해나갈 수 있다. 문서의 종류는 다음과 같이 두 가지 관점으로 작성할 수 있다.

    • 사람 관점: 각 개인마다 맡은 역할을 구체적으로 문서화한다.

    • 업무 관점: 각 분아냐 역할마다 맡은 사람이 누구인지를 문서화한다.

  • 물론 이 문서의 내용은 언제든 변화하거나 업데이트 될 수 있으므로 그걸 누가 담당해서 기록할 것인지도 정해야 한다. 문서 소유자가 모든 변경 사항을 파악하고 업데이트 하기에는 물리적으로 불가능하니 팀원 모두가 자신의 업데이트 사항을 문서 소유자에게 보고하는 방식으로 하는 것이 좋다.

• 모든 역활과 책염 옆에 반드시 이름을 적는다

  • 업무와 역할을 표기한 R&R 문서에 빠질 수 없는 것이 바로 DRI(Directly Responsible Individual), 즉 각 책임자의 이름이다. 모두에게 업무 참여의 기회가 있지만 결국 끝까지 과제의 완성과 성공을 책임질 한 사람을 정해놓아야 한다. 별 것 아닌 차이처럼 보이겠지만 이름이 있을 때와 없을 때 책임의 의미는 완전히 달라진다. 이름이 있어사 “이 과제가 실패하면 이 사람한테 책임이 있다.” 라는 뜻이 부여되고 (…) 해석되면서 직접적인 평가와 연결이 되고 책임 구조가 강해진다.

• 최종 의사결정권자를 정해 놓는다

  • 팀 모두의 의견을 수집하고 결정을 하다보면 종종 팀 내에서 의견이 반반으로 갈리는 경우가 있다. 이럴 때 대비해서 미리 수습 방안을 정해놓아야 한다. 단일 팀 혹은 협업하는 팀들보다 더 높은 체계에 있는 상사에게 최종 결정을 내릴 수 있는 구조를 만들어놓는 것이다. 뭔가 ‘윗사람에게 보고한다’라는 개념과 가들게 결정권을 팀 바깥으로 옮기는 합리적이고 객관적인 방법이라 할 수 있다. (…)

• 의견이 달라도 계속 지지한다

  • (생략)

• 기여한 만큼 정확히 보상한다

  • (생략) 뒷장에 자세히 다룰 것

• 조직문화에 대한 적합한 리더십을 정의한다

  • 플랫 컬처 안에서 발휘되는 리더십은 일반적인 조직에서 요구하는 리더십과는 그 개념이 조금 다르다고 앞서 이야기한 바있다.

• 주기적인 가지치기를 습관화한다

  • 보텀업과 플랫 컬처처럼 모든 아이디어가 존중되는 문화의 조직에서는 자칫하면 프로젝트 양이 많아질 우려가 있다. 이를 방지하기 위해 주기적으로 프로젝트 가지치기 시간을 마련해야 한다.

    • 중복되는 아이디어, 너무 많은 아이디어 가지치기

  • ‘적은 일을 더 잘하기 Do fewer better’

• ‘구체적’이라는 표현의 기준은?

  • 앞서 프로젝트에 대한 기대치와 역할을 문서화하는 것의 중요성을 설명한 바 있지만 문서의 ‘세부 사항’이 얼마나 중요한지에 대해 대부분의 사람들이 잘 알지 못한다. 나 역시 어떤 사건 후에 이 점을 절실히 깨달았는데 이 깨달음 덕분에 이후 나의 일이 훨씬 더 수월할 수 있었다.

  • 에피소드

    2018년 검색팀 팀장으로 일할 당시 규모가 큰 프로젝트 하나를 맡게 되었다. 그 프로젝트는 굉장히 큰 투자금이 들어갔을 뿐 아니라 뉴스팀, 검색팀, 뉴스피드팀, 광고팀과도 관련된 일이라 협업할 팀의 숫자도 많았고 보는 임원들의 눈도 많았다. 이렇게 규모가 크고 거의 무에서 유를 창조하는 종류의 프로젝트일 수록 이와 관련된 팀원들의 역할과 책임을 분명히 잡아놔야 한다.

    그 프로젝트를 위해서 나는 디자인팀 직원 다섯명을 모아 팀을 만들었다. (…대충 팀원의 강단점에 맞게 역할 문서를 작성했지만 구글에서 새로 온 팀장이 미흡하다고 더 구체적으로 써오라고 함. 그래서 저자가 예시 문서를 보여달라고 했고 그 예시문서는 생각보다 훨씬 더 세부적으로 구성되어 있었음…)

    그(팀장)와 내가 말한 ‘구체적으로’는 엄연히 달랐다. 나는 그 문서를 복사한 다음, 우리 팀 상황에 맞게 R&R 문서를 만들었다. 거기에는 다음과 같은 내용들이 담겨있다.

    • 업무를 쪼개서 각 담당자에게 세부 오너십을 부여한다

    • 각 업무마다 품질을 책임질 총 책임자를 정한다

    • 폴더 밑 문서 정리의 권한을 갖는 문서 소유자를 정한다

    • 회의에서 누가 발표를 리드할 것인지 정한다

    • 누가 회의록을 적고 팀에 공유할지 정한다

    • 이상과 같은 책임과 역할을 매일 혹은 매주 온라인으로 간단히 공유하는 방법을 미리 정한다

    이것은 당시 그 문서의 반의 반도 안되는 내용이다. 실제 문서에서는 정말 한 치의 오해나 혼란도 없도록 내용이 무척 구체적으로 적혀있었다. 게다가 이 모든 것을 업무 위주로 쪼개보고, 사람 위주로도 쪼개어 필요에 따라 볼 수 있는 두 가지 타입의 문서로 분류하기도 했다. 결정적으로 모든 업무 옆에는 각 책임자의 이름을 적어 어떤 일의 책임자가 누구인지 명확히 알아볼 수 있었다

    처음엔 꼭 이렇게까지 해야 하나 하는 생각이 들었던 것도 사실이다. 그러나 이렇게 구체적으로 문서화하고 다니 프로젝트 진행 과정 전체에 걸쳐 역할과 책임에 대한 오해의 소지를 거의 완벽하게 제거할 수 있었다. 모든 프로젝트마다 반드시 생기기 마련인 ‘어? 난 내가 해야 되는지 몰랐는데?’식의 변명이 깨끗이 사라졌다.

    (…) 각 팀원 간의 협업도 훨씬 원활히 이루어졌다. 사소한 갈등으로 인한 문제도 발생하지 않아서 리더로서 팀을 위해 더 효과적으로 시간을 쓸 수 있었다. (…)

    동등하다는 의미의 플랫 컬처가 겉으론 자율적으로 보이지만, 사실 그 안엔 막대한 책임이 있다는 걸 똑똑히 보여준 사례였다. 한 팀으로서 팀의 필요에 맞게, 혹은 자신의 관심사와 강점에 맞게 자기의 역할을 조정하고 프로젝트가 끝날 때까지 그 약속을 지키는 것이 바로 플랫 컬러가 성공적으로 작동하는 핵심 동력이다.

  • 모든 일에 ‘구체적’일 필요는 없다

    • 소수의 인원이 단기간에 걸쳐 빠른 속도로 처리해야 하는 프로젝트라면 충분한 대화를 통해 효율성에 포커스를 맞춰 일해도 좋다.

• 기회는 스스로 만들거나 요구해도 된다

  • 원래 자신이 맡은 영역인데 업무가 잘 맞지 않는 사람들도 있다. 이런 이유로 정해진 직책과 업무에서 벗어나 다른 일을 시도해볼 수 있는 기회를 만들어주는 것도 매우 중요하다.

  • 당시 우리가 진행하던 프로젝트는 꽤나 까다로운 작업이어서 IC4~5 레벨은 되어야 할 수 있는 일이었다. (IC3은 경력 제로 주니어, IC4는 미드 레벨, IC5는 시니어 레벨이다.) 스티브의 레벨은 IC3밖에 되지 않았기에 각자의 레벨에 맞춰 일을 맡겨야 할 책임이 있는 나로선 참 난감했다. (…) 그는 이미 기대치에 비해 두세 배의 속도와 퀄리티로 일하고 있었다. (…) 나는 결국 성과를 내지 못하면 스티브뿐 아니라 나도 함께 책임을 지기로 하고 정확한 프로젝트의 기대치를 정해준 다음, 레벨이 높은 디자인 멘토 두 명을 스티브에게 붙여주었다. 스티브의 PM 파트너에게도 꼭 도움을 주라고 당부했다. (…) 스테브는 1년만에 승진도 하게 되었다.

끝