Feb 222012
 
Pinterest

다소 급진적이지만 재미있는 이야기를 하는 사람이 있어서 공유.

제이슨 프라이드 : 사무실에서 일이 안 되는 이유

 

TED Talks 제이슨 프라이드는 사무실이 일하기에 적당한 장소가 아니라는, 일에 대한 급진적 이론을 말한다. TEDxMidwest에서 그는 (M&M이라 부르는) 주요 문제들을 설명하고, 일이 이루어지도록 하기 위해 세 가지의 제안을 내놓는다. (참고: M&M은 매니저(관리자)와 미팅(회의)를 말함.)

 

필자는 2~3년 전에 제이슨 프라이드가 얘기하는 것을 따르게 되었다. 사실 어쩌다보니 그렇게 된 것이긴 하지만, 무척 흥미로운 경험을 했었다. 그리고 이러한 경험을 정도의 차이는 있지만 업무에 적용시켜 보려고 애쓰고 있다. (물론 국내에서는 여러모로 힘들다. 얼리버드를 선호하는 경향이 있고, 위의 TEDx 동영상에서 언급한 M&M이 만능이라는 인식을 ‘윗 사람’으로부터 지우기 어렵기 때문이다.)

어쨌든, 그 자세한 경험은 시간이 지나서 다소 흐릿하지만, 이로부터 배운 몇 가지와 추가적인 시험(?)과 경험을 바탕으로 도움이 되는 방향으로 간단히 공유해 보고자 한다.

 

1. 서로 다른 사람들

사람들마다  라이프 스타일이 굉장히 다르고, 가치관과 사고방식, 지식과 경험도 다르다. 사는 곳도  대부분 오피스에서는 좀 멀다. (출근을 한다면 출퇴근 시간만 평균 2시간은 너끈히 잡아먹을 것)

일단 사람들이 다 다르다는 것을 인정하고 들어가지 않으면 원격 업무나 ‘자발적인 업무’는 시작되지 않는다.

이런 사람들을 오피스에 모아놓고 근태관리를 하고 뭔가를 (반)강제로 하라고 하면, 서로가 서로를(특히 윗사람이 아랫사람을) 방해 하면서 오피스에 앉아있는 시간은 많은데 일하는 시간은 적은 상황이 되는 경우가 다반사다.

제이슨 프라이드가 얘기하는 것이 넌센스라고 생각하시는 분도 계실 것 같다. 필자가 생각 하기에도 이런 방법이 항상 통한다고 일반화 하기에는 무리가 있다. 업에 따라 오피스에 모여 일하는 것이 필요한 경우도 분명히 있다. 하지만 많은 업이 오피스가 없어도 일이 진행되는데 문제가 없을지도 모르겠다는 생각을 강력하게 하게 되었다. 그리고 ‘소프트웨어 회사’의 경우는 실제로 다양한 성공사례(37signals나 Atlassian이 빠지지 않고 거론되는 곳이다)도 있다. 그 외에도 다양한 곳에 적용할 수 있는 기반이 갖춰지고 있다.

노파심: 오피스에서 일하는 편이 효율이 좋은 경우도 분명히 있고, 또 적지 않다.

수시로 많은 대화, 논의를 통해 아이디어를 전달/공유하고 이를 바탕으로 의사 결정을 빠르게 하기 위해서는 오피스에서 같이 일하는 편이 효율이 좋은 것 같다. 회사/연구실 업무 등으로 따지면 ‘기획 회의’나 ‘프로젝트 선정 회의’ 같은 것. 최대한 많은 사람이 한 자리에 모여 가감없이 생각을 나누고 가다듬고 영감을 얻는 작업. 또는 으쌰으쌰 하는 분위기가 생생한 경우.

2. 기록하기와 기록물 공유, 그리고 기록물 저장(아카이빙)의 중요성

일은 프리하게 자율적으로 하되 일이 잘 진행되기 위해 필요한 것이 있다면  그것은 기록이다. 거창한 문서작업이 아니다. 오히려 기록하는 방식과 그 기록을 공유하는 방식, 그리고 그것을 저장하는 방식에 답이 있는 것 같다.

기록은 보고의 시작이다. 기록은 계획의 시작이다. 기록은 반성의 시작이다. 기록은 평가의 시작이다. 기록은 인수인계의 시작이다.

팀에 속한 사람은 예외 없이 기록하고, 팀원끼리는 가차없이 공유한다.

그러기 위해서 기록은 쉬워야 하고(작성과 공유에 5분 이상이 걸리면 주객 전도), 충분한 정보를 담고 있어야 하고, 거짓이 없어야 하며(설사 거짓이 있더라도 결국은 드러나게 해야 한다), 발생한 문제를 숨기는 것이 아니라 자꾸 드러내도록 해야 한다.

기록이 제대로 되고, 가감없이 공유되면 일반적으로 다음과 같은 일이 일어난다.

다른 사람이 한 일이 많은 것을 보면, 어떤 사람은 미안해 하고, 어떤 사람은 승부욕이 솟는다. 누가 어느 정도 팀에 기여했는지 노출되고, 거짓말도 못 한다. 한 두 번은 일한 척을 할 수 있지만 1주일 이상 ‘척’으로 버틸 수 없기 때문이다. 프로그램 작업은 특히 더 그렇지만 모든 작업 결과는 매 번 의미있는 단위로 나누어 온라인 저장소로 보내고(커밋이라는 용어를 씁니다만), 모든 수정 사항도 마찬가지로 반영한다. 이를 통해 작업하는 모두에게 누가 언제 어떤 일을 어떻게 해서 어떤 결과물을 만들어 냈는지 모두 공유된다. 결과물의 이력은 모두 추적되고, 누구나 최신의 결과물을 즉시 얻을 수 있다. 새로운 팀원이 들어오면 기록물을 던져주어 팀의 분위기와 진행 상황을 쉽게 팔로업할 수 있도록 하고, 팀원이 나가더라도 따로 인수인계 할 일이 줄어든다.

 

스크럼 한 눈에 보기.

 3. 무엇을 기록하고 공유하고 저장하나?

애자일 개발방법론 가운데 하나인 스크럼에서 많은 부분 차용한 기록 방법은 다음과 같다.

  • 팀원(일을 실제로 하는 사람들. 돼지)은

스크럼 방법론에 따라 매일 각자

  • 한 일
  • 할 일
  • 장애물

을 정해진 시간에 간단히 기록한다. 이건 스크럼에서 필수 사항 가운데 하나다. 원래는 회의 주체자(스크럼 마스터)가 팀원들을 정해진 시간, 정해진 장소에 모아 일일회의를 하면서 구두로 5~10분 안팎의 미팅으로 끝내는 일이지만..기록으로 남기는 편이 여러 모로 더 좋은 것 같다.

부가적으로 위의 기록을 하기 전에 일을 시작하기 전의 기분이나 컨디션을 (가능하면) 익명으로 표현한다. 우리는 1~10 사이의 숫자를 썼다. 10은 최고로 기분이 좋다는 의미이고 1은 컨디션 최악이란 뜻으로 사용. 보통은 4~7 정도에서 왔다갔다 한다.

일을 마친 후에는 간단히 회고를 한다.

  • 일을 진행하면서 좋았던 점
  • 아쉬운 점
  • 앞으로의 행동계획

을 남기고 일을 마친 후의 기분을 시작과 짝을 맞춰 기록한다. 생각한대로 혹은 생각보다 일이 잘 진행되면 기분이 좋아지고, 반대의 경우 기분이 나빠지곤 한다.

기본적으로 외부에는 노출하지 않지만 모든 일은 기록하고, 필요한 사람에게 가감없이 공유한다.

근태 관리도 안 하고(사실상 저 기록 자체가 근태관리긴 하지만), 일 하라고 보채지도 않지만 비교적 잘 굴러간다.

  • 프로젝트 결과물의 주인(상사, 매니저, 팀장 등 실제로 일을 하지 않고 관리만 하는 사람들. 닭)은

외부와의 인터페이스가 되어 요구사항을 파악하여 정리하고 무엇이 필요한지 고민하고 이를 바탕으로 달성 가능한 목표를 설정하고, 일의 우선순위를 정하고, 할 일을 수행 가능한 의미있는 단위로 나눈다. 보통은 문장을 만들어 리스트를 만들어 두고 상황에 따라 우선순위를 조정하거나 새로운 일을 만든다. 예상 했겠지만, 모두에게 공유한다. 우선순위에 대해서는 다양한 근거가 있어야 한다. 트렌드 분석, 업계 동향, 멘토와의 대화, 독서, 미래 예측, 팀의 비전, 바뀐 상황 등등. 직감에 의한 것이라도 팀원을 설득시킬 수 있을 정도로 고민의 과정이 드러나야 한다.

보통 스토리로 표현한다. (자세한 것은 ‘사용자 스토리’나  ‘스토리 스크럼’을 검색어로 검색을 좀 해보시길)

  • 충분히 작고: 한 두 사람이 짧은 시간(보통 반나절~ 길어야 2주)동안 무리없이 할 수 있을 정도로…
  • 가치 지향적이면서 독립적이고
  • 누구나 이해하기 쉬우면서 간결하고
  • 테스트 및 측정/평가가 가능해야 한다.

일을 팀원이 할 수 있을 정도로 나누고 가다듬고, 일의 ‘우선순위’를 결정하고… 이에 대해 팀원 모두가 공감 할 수 있도록 하는 것이 필요하다. 동기부여가 된 팀원은 누가 시키지 않아도 일을 한다.

일이 진행되지 않거나 이상하게 흘러가는 이유 가운데 대부분은 팀원이 일의 우선순위를 모르거나, 위에서 내려온 우선순위가 높은 일에 공감하지 못하거나, 목표에 동감하지 않거나, 일이 두루뭉술해서 뭘 해야하는지 명확하지 않거나, 일에 대한 평가가 애매할 수밖에 없어서 잘하고 못함을 객관적으로 평가할 수 없는 경우다.

부록: 닭과 돼지의 우화

  • 닭이 돼지에게 사업 제안 -> 난 달걀을 낳고 넌 살로 베이컨을 만들어 팔자 -> 닭은 사실상 손해볼 거 없으나 돼지는 목숨이 왔다갔다 하는 문제
  • 과연 돼지가 닭의 말을 어떻게 받아들일까? (욕 안 나오면 다행;;;)
  • 닭: 실제로는 일에 참여하지 않는 모든 사람
    • 보스, 매니저, 기획자, 투자자, 고객, 다른 팀 사람, 갑, 실제 일은 안 하는 팀장, 교수 등등…
  • 돼지: 실제로 일을 맡아 해야 하는 모든 사람(팀원)
  • 닭은 자기가 할 일이 아니기 때문에 일을 돕겠다며 쉽게 제안/조언 등으로 관여하고 싶음. 하지만, 아무리 간단해 보이는 일도 돼지가 보기엔 그렇지 않을 수 있음.
  • 실제 업무 미팅은 돼지끼리 주도. 닭은 참관.
  • 닭의 일부는 ‘우선순위’를 정함. 그 외에는 돼지들이 정함(일의 크기 추정, 할 수 있는 일의 양, 마감 등)

4. 어떻게 기록하고 공유하고 저장하나?

좋은 도구가 많다. 유무료 서비스가 다양하게 있는데,

무료 서비스로는 구글독스, 비트버킷, 드롭박스/박스, 트렐로 등이 시작하기도 비교적 쉽고 충분히 유용하다.

몇 년 전에는 팀원의 경우 구글 독스에 문서 하나 남겨놓고 새로운 날이 제일 위에 오도록 기록했다. 온라인 문서의 경우 내용이 많아지면 무거워지는 경향이 있어서 한 달에 한 번 새로운 문서를 만들었다.

매니저/팀장/리더 등의 경우 구글 독스의 스프레드시트를 이용했다. 프로젝트별로 각 스토리를 작성하고 우선순위를 수시로 바꾸고 새로 추가하거나 수정한다.

꼭 구글 문서가 아니라도, 어떤 장치에서도 쉽고 빠르게 기록할 수 있으면 상관 없다. 물론 공유 옵션 등이 있어서 문서의 노출 여부를 결정할 수 있어야 한다. 문서 작성에 대한 이력 관리가 가능하여 ‘누가 언제 무엇을 추가하고 수정하고 삭제했는지’ 확인 가능하면 더 좋겠다. 찾아보면 이런 서비스는 무척 많다.

일의 진행상황은 칸반(Kanban) 기반 서비스가 직관적이고 여러모로 편하다.  필자는 현재 트렐로(Trello)를 이용하고 있다.

문서 작성의 경우 드롭박스나 분산버전관리시스템의 도움을 받는다. 파일의 이력 관리가 가능하고, 끊김없는 공유가 가능하며, 누구나 최신 버전을 갖고 이야기 하여 혼란을 피할 수 있다. 백업은 덤이다.예를 들어 위에서 언급한 트렐로에 대해 필자가 작성한 슬라이드 문서의 경우 파일 첨부의 형태가 아니라 공유 기능을 통해  https://db.tt/c8rEeVXV 처럼 링크를 공유하면 만약 중간에 수정사항이 있더라도 최신의 버전을 확인하게 된다. 링크한 파일의 경우 일부 사람들에게는 공유되어 있는데, 이 경우 필자가 파일 수정을 하면 모두의 파일이 자동으로 최신 파일로 갱신된다.

최종본.doc 최종본_수정.doc 최종본_수정_from아무개.doc 최종본_수정_from_아무개_수정20140215_1308.doc 진짜_최종본.zip  진짜_최종본_final.zip

같은 우스운 파일들이 돌아다닐 이유가 없다.

개인적으로는 워드나 hwp 보다 마크다운이나 그냥 단순 텍스트 파일, 혹은 html을 선호한다. 특히 문서는 ‘예쁘게 만들기’보다 ‘구조적으로 작성하기’에 시간을 쏟는 것이 더 낫다. 문서의 양식에 관심을 둘수록 쓸데없는 곳에 시간이 낭비된다. 조금 급진적으로 나가면, 내가 충분한 권한이 있으면 제안서나 보고서는 마크다운이나 텍스트 혹은 기본 html로만 받겠다-_-;;;

대부분의 문서는 적절한 heading과 list, 들여쓰기, 하이퍼링크, 기본적인 텍스트 강조(볼드, 이탤릭, 밑줄, 취소선) 정도면 충분하다. 디자인적 기교가 필요한 일은 글의 작성자가 아니라 다른 팀에서 스타일시트나 테마, 매크로나 스크립트 등으로 일관 변환하는 편이 생산적이다. 당연히 스타일시트나 테마, 매크로/스크립트 등도 버전관리의 대상이다.

개인적으로 현재 인프라에서 가장 지’양’하는 작업 방식이 작업한 파일을 ‘이메일 첨부’로 처리하는 식이다. 우편->전자우편으로 올 당시에는 이메일이 아주 강력한 업무 보조 도구였지만, 현재는 단도직입적으로 그렇지 않다. 엄청난 시간 낭비, 인지력 낭비를 부추기는 것이 이메일 파일 첨부 방식이다. 시대가 변하면 도구의 사용도 변해야 한다.

Git이나 Mercurial 같은 분산버전관리시스템의 도입은 ‘기록’이라는 측면에 있어서 큰 잇점이 있다. 누가 어느 부분을 언제 추가/수정/삭제했는지 알 수 있다. 권한이 있는 사람은 누구에게 ‘요청’을 할 필요 없이 스스로 필요한 문서를 찾아볼 수 있고, 완전한 최신본을 받아볼 수 있다. 필요한 경우 수정을 ‘요청’하는 것이 아니라 직접 수정하여 반영하는 것도 가능하다. 모든 것은 기록으로 남고, 언제든지 특정 버전으로 되돌릴 수 있기 때문에 부담없이 작업을 진행할 수 있다. 동시에 작업하는 것도 가능하다. 이런 일이 잘 진행되려면 위에서 얘기했든 binary가 아닌 순수한 텍스트 파일 형식으로 문서를 작성하는 문화가 있어야 할 것이다.

클레이 셔키의 TED강연을 이 시점에 추천한다. 현대적인 기록, 그리고 버전관리가 어떤 식으로 이용될 수 있는지 큰 그림을 보자.

http://www.ted.com/talks/lang/ko/clay_shirky_how_the_internet_will_one_day_transform_government.html

 

개인적으로 분산버전관리시스템은 프로그래머 뿐 아니라 이미지 작업이나 문서 작업 등 파일을 다루는 사람들의 기본 소양(?)이 되어야 한다고 본다.

내가 대학교 커리큘럼을 바꿀 수 있는 권한이 있다면 대학교 1학년 1학기는 버전관리와 관련된 수업을 진행하고, 이후 모든 개인 및 팀 과제, 보고서, 논문, 문서 작성 등을 모두 버전관리시스템을 이용하여 텍스트 파일로 받겠다. 기록의 작성, 공유, 보관은 사실 ‘굉장한 연습’이 필요하다. 습관적인 수준으로 몸에 익히려면 짧게는 2~3개월, 길게는 1년 이상이 걸리기도 한다.

5. 회의와 간섭을 최소화

스크럼에서는 스프린트라는 표현을 쓰는데 1~4주 정도 단위로 굉장히 치열한 회의를 주기적으로 한다. 그 외의 회의는 지양한다. 보고 회의가 필요하면 스프린트 회의 시간에 맞춰서 기다렸다 진행하는 식으로.

기본적으로 실제로 일하는 사람을 아무리 사소하게 방해해도 그것이 모이면 엄청난 지연으로 나타난다.

회의 때 만나서 하는 일은

  1. 지난 회의 이후부터 이번 회의 직전까지 했던 일을 실제로 보여주고 목표를 달성했는지 여부를 결정한다.
  2. 다음 회의 때까지 해야할 일을 정하고 달성 가능한 작은 목표를 설정한다.
  3. 전에 했던 일을 회고하고(잘 된 일, 안 된 일), 이를 바탕으로 다음에 더 잘하기 위해 집중할 수 있는 방법을 찾는다. 잘한 일은 더 잘하고, 잘 안 된 일은 개선점을 찾는 것이다.

스프린트 회의에서 팀원은 그간에 작업한 ‘눈에 보이는 성과물’을 모두에게 공개(가능하면 실제로 시연)해야만 하고, 이 작업 결과물로만 팀장 또는 프로젝트에 관심있는 상사에게 평가받는다. 칭찬을 받거나 대차게 까이거나…

리더/팀장/관리자/보스/매니저는 이 회의에서 공개적으로 다음 회의 전까지 했으면 하는 일을 알린다. (3. 에서 평소 일을 추가하거나 수정하고 우선순위를 조정하는 등의 일을 한다고 했다.) 물론 실제로 일을 하는 팀원이 납득 해야 한다. 얼만큼 진행할 것인지도 ‘팀원’이 정하지 리더가 강제로 정하지 않는다.

팀원이 아닌 사람들은 이 회의에서만 의견을 줄 수 있다. 이것이 반영되는 것은 리더/팀장/관리자/보스/매니저가 판단해서 결정할 일이다. 의견은 주되 간섭하지 못한다.

 

다음 미팅 때까지 할 일을 정하는 것은 과거에 한 일의 양을 바탕으로 앞으로 계획된 외부 스케쥴(출장, 휴가, 잡무) 등을 모두 고려하여 돼지들 모두의 동의를 얻어  정한다. 과거에 한 일의 양을 바탕으로 하니까 말도 안되게 부담스러운 일을 하지는 않는다. 돼지들 모두가 동의했으니 적어도 정해진 양은 열심히 수행할 것으로 기대할 수 있다(기록에 다 남는다;;).

할 일은 닭의 일부가 정한 우선 순위에 따라 정해진다. 닭이 새로 할 일을 가져오면 그 일이 왜 추가되었는지 모두에게 설명하고 설득 한다. 새로운 일이 어느 정도 난이도의 작업인지는 돼지들이 지금까지의 경험을 바탕으로 ‘추정’하여 닭에게 알려준다. 닭은 이 ‘추정치’를 참고하여 일의 우선순위를 조정한다. 추정치가 닭의 예상보다 크면 더 작은 일로 나누고, 작으면 작은 일들을 합쳐서 적당한 크기의 일로 합칠 수도 있다.  마감이 결정된 상황에서 돼지가 정한 일의 양이 맘에 차지 않으면 리더가 결정할 일은 두 가지 중의 하나이다. 마감을 미루거나, 일을 작게 줄이거나.

각 일(스토리)은 돼지들이 한 사람이 짧게는 30분, 길어도 2~3일을 넘기지 않는 더 작은 일(태스크)로 작게 나눈다. 작게 잘라진 일은 이후에 그 일을 하고 싶거나 가장 잘 하는 사람이 우선순위를 고려하여 가져가 작업한다. 중복된 작업을 피하기 위해 당연히 누가 무슨 일을 하고 있는지, 일을 하는 단계(할 일, 진행, 검증, 완료)는 어디인지를 공유한다(트렐로 같은 서비스나 비슷한 종류의 온라인 칸반 서비스가 많이 있다).

팀장이라면 일이 진행->검증->완료로 가는 모습을 확인하는 것은 소소한 기쁨 가운데 하나가 될 것이다.

 

회의 끝나고 나면 다음 회의 전까지는 누구도 하기로 결정된 일을 제외한 어떠한 일도 중간에 새로 추가하거나 바꾸지 못한다. 닭들은 조바심 내지 말고 더 깊이, 느긋하게 고민할 수 있는 시간으로 삼으면 되겠다.

이렇게 실제로 일하는 사람에게 간섭할 수 없도록 하기 때문에 팀원들은 핑계거리가 거의 없어진다. ‘하려고 했는데 ㄱ과장이 B라는 일이 더 급하다고 해서 그거 하다보니 못했습니다’ 따위는 통용되지 않는다. 회의때 하기로 정해진 일을 최선을 다해 하고, 회의때 정해진 ‘목표’를 수행하기 위해 팀원이 단합해야 한다. 간섭이 생기면 가차없이 모두 ‘장애물’에 적어놓아(예를 들면 ㄱ과장이 B라는 일이 급하다고 주문해서 신경쓰임. 임원 ㄴ이 진행상황 보고하라고 회의 잡음. ㄷ 부장이 일하는 중에 자꾸 와서 말 걸음. 등등) 일의 진행이 제대로 안 되었을 때 ‘장애물’에 언급된 사람에게 책임을 묻거나 ‘장애물 제거’를 못한 ‘권한이 많은 사람’이 책임을 진다.

불가피한 회의가 있을 경우 스탠딩 회의를 추천한다. 서서 회의를 진행하면 앉아서 진행하는 것에 비해 회의가 더 짧고 굵게 끝난다. 특히 고령의 고직급이랑 같이 회의를 할 경우 회의가 지속될수록 누가 더 빨리 지칠지는 뻔하기 때문에 하나마나한 잡소리가 줄어든다. (개인적으로 ‘회의실’ 의자는 고직급일수록 불편한 의자를 준비해야 한다고 보는;;;;)

 

스프린트 회의 역시 (되도록) 실시간으로 모두 가감없이 기록하여 남긴다. 경험상 충분히 주요 사항을 기록해 가면서 회의를 진행할 수 있다. 프로젝터로 온라인 문서에 회의록을 띄워놓고 회의하는 것도 방법이다. 원격에 있는 사람도 실시간으로 회의 진행을 확인하거나 참여할 수 있다. 발언은 모두 ‘누가’ 했는지도 남긴다. 보통 회의록에 ‘누가’가 빠지면서 책임문제가 불거지곤 한다.

 

6. 기록으로 평가

기록이 남으면, 이를 바탕으로 개개인의 성과가 객관적으로 평가된다. 사적인 감정이 끼어들 틈이 거의 없다.

팀원의 성과 평가는 ‘한 일’로, 리더의 성과 평가는 우선순위의 조정과 설득력(추가적으로는 동기부여와 장애물 제거 능력), 그리고 미래 예측 능력으로 이뤄진다.

리더는 팀원의 ‘기분’에 대한 기록이 팀 전체적으로 안 좋다면 적신호를 감지하고 드러나지 않은 문제도 파악해야 한다. 한 일, 할 일 등을 바탕으로 적당히 동기부여나 치어업(Cheer up)도 시켜야 하고, 작업이 일부에게 너무 몰리지 않도록 조정도 해야 한다. 이런 성과는 스프린트 회의에서 ‘잘 된 일’로 드러나 누가 일을 진행 하는데 실제적으로 도움이 되는지 알 수 있게 해준다. 거꾸로 방해만 하고 쓸데없이 간섭만 하거나 팀 분위기를 흐리는 경우 ‘안 된 일, 나빴던 점’에서 드러나 평가의 기준이 된다.

무임 승차가 완전히 사라지지는 않겠지만 확실히 줄어든다. 실제로 경험해보면 ‘할 일’에 써놓은 일이 ‘한 일’이 되지 않는 상태가 오래 지속되면 당사자는 바짝바짝 피가 마른다. 동료 평가가 ‘감정’이 아닌 ‘성과’를 위주로 이뤄진다. 일을 많이 하는 사람 혹은 잘 하는 사람과 일을 안/못하는 사람이 동시에 눈에 띈다. 리더는 일에 제대로 참여하지 못하거나 성과가 없는 사람을 닥달하는 것이 아니라 문제를 파악하여 필요한 교육을 시키거나 적성에 맞는 일로 돌릴 수 있는 기회를 갖는다. 리더는 문제가 드러나면 ‘좋은 징조’로 봐야 한다. 문제가 없어 보이면 (대부분 리더에게) 문제가 있는거다.

 

조직이 커지면 어찌될지 모르지만… 개인적인 경험으로는 아주 흥미로웠다. 지금도 실험중(?)인데 역시나 흥미롭다.

 

ps. 오픈소스와 클라우드 서비스 만세입니다. 예전에 썼던 글을 누군가의 요청에 의해 수정/보강하여 발행.

Pinterest