[일간 애자일#681](4/9) “팀장님을 직장 내 괴롭힘 가해자로 고소할래요!” 등

  • 매일 애자일, 린, 조직문화, 협업, 리더십, 자기계발 등과 관련된 새로운 소식을 공유드립니다.
  • 소감, 동의, 반론 등을 댓글로 남겨주세요. 활발한 소통을 기대합니다.
  • 지난 기사는 [여기]에서 보실 수 있습니다

“팀장님을 직장 내 괴롭힘 가해자로 고소할래요!”

지나치게 떼쓰는 팀원 어쩌나..

홍팀장 산하에 유독 자기 주장이 강한 팀원이 한 명 있다. 일할 때 본인 의견을 소신있게 표현하는 게 아니라, 개인적인 부분들에 대해 유독 그렇다. 예를 들면, 중요한 팀프로젝트 발표를 코앞에 두고 담당자인 본인이 휴가를 쓰겠다거나, 한참 바쁜 시기에 2박3일 교육을 보내달라거나, 고생되는 업무는 본인이 맡지 않으려고 버티는 경우들이 자주 있다.

일일이 설명하고 안 된다고 말하며 부딪히는 것도 서로 스트레스라, 홍 팀장은 그간 웬만하면 팀원 본인이 원하는 대로 내버려두었다. 하지만 올해 시작된 프로젝트에서 본인 역할을 다하지 않아 다른 팀원들을 힘들게 만드는 걸 보니 더 이상 두고볼 수 없게 됐다. 홍팀장은 해당 팀원과 면담일정을 잡고 그 동안의 일에 대해 이야기를 나누었다.

“팀장님, 지금 저 괴롭히시는 거예요?”

대화 도중 팀원이 입술을 꼭 깨물더니 갑자기 “괴롭히는 거냐”고 되물었다. 그러더니 “지금 저를 부당하게 괴롭히시는 것 같아요. 저 팀장님을 직장내 괴롭힘 건으로 고소할 수도 있습니다”라고 말했다.

그 말을 듣는 순간, 홍팀장은 눈앞이 캄캄해졌다. 팀 내에서 원만히 협업하라고, 함께 일하는 타 팀원들도 배려하자고 말하던 자리에서 갑자기 뜬금없이 직장내 괴롭힘이란 단어가 왜 나오는가! 혹시 면담 중에 홍팀장 스스로 강압적인 태도나 언행이 있었는지를 돌아봤지만, 평소 홍팀장의 리더십평가결과를 보더라도 그런 타입은 아니었다. 팀장으로서 해야 할 말을 하고도 일종의 협박을 받았다고 생각하니 화도 났지만, 한편 팀장의 자리가 한층 감당하기 무겁고 힘겹게 느껴졌다.

원문: https://bit.ly/39SC1ha


대기업 임원하다 작은 스타트업에 온 이들이 욕먹다 끝나는 이유

이직을 하면 새로운 회사에 적응하는 것이 만만한 일은 아니다. 문화적인 변화가 주는 부담감이 적지 않다. 개인적으로도 그랬던 것 같다.

잉글랜드 프리미어리그에선 잘 나가던 축구 선수가 스페인 프리메라리가로 이적하면 기대 이하의 성적을 보이는 경우가 종종 있는 것처럼 기업도 마찬가지지 싶다. 특히 회사 규모가 다를 경우 변화의 충격은 더욱 클 수 있다.

큰 회사가 다니다 작은 회사 들어간 사람들, 특히 임원급들이 의외로(?) 고전하는 경우가 많은 것도 이와 무관치 않을 것이다.

실리콘밸리 유력 벤처 투자회사인 안드레센 호로위츠 공동 창업자인 벤 호로위츠가 쓴 책 ‘하드씽’을 봐도 대기업 임원은 스타트업과 물과 기름 같은 사이일 가능성이 높다. 저자는 대기업 임원 영입에 부정적이다.

이유는 이렇다.

여기서 가장 중요한 사실은 대기업 임원이 하는 일과 작은 회사의 임원이 하는 일이 너무도 판이하다는 점이다. 옵스웨어를 매각한 뒤 휴렛패커드에서 수천 명의 직원을 관리할 당시 나는 무지막지하게 많은 일들에 시간을 쪼개서 매달려야 했다 말 그대로 모든 일들이 나를 필요로 했다.

협력 관계나 매각을 논의하는 중소기업들이 나를 찾았고 사내 직원들이 내게 이런저런 승인을 받으러 찾아왔고 다른 부서에서 내게 도움을 요청했고 고객들도 내가 관심을 기울여 주길 원했다. 당장 생각나는 건 이 정도지만 이건 빙산의 일각에 불과하다. 나는 현재 돌아가고 있는 일이나 거래들을 조율하고 최적화하는데 하루의 대부분을 보내야 했다. 내가 하는 일 대부분은 시급한 것이었다.

사실 대기업 임원으로 오래 있어 본 베테랑이라면 누구라도 한 분기에 새로운 프로세스를 셋 이상 추진하는 것은 지나친 욕심이라고 말할 것이다. 결과적으로 대기업 임원은 빈번한 방해 요소들과 더불어 진행하는데 익숙해지기 마련이다. 그러나 신생 기업에는 회사를 저절로 움직이게 하는 관성이라는 것이 없다. 임원이 주도적으로 움직이지 않는 한 그 어떤 일도 일어나지 않는 것이다. 창업 초기의 임원들은 하루에 8~10개 프로젝트를 챙겨야 한다. 그러지 않으면 회사가 돌아가질 않는다. 임원 자신이 전투적으로 움직이지 않으면 회사가 정체되기 십상이다. 그뿐 아니라 신생기업에 대기업 임원을 영입하면 2가지 위험한 부조화가 발생하게 된다. 첫째는 업무 방식의 부조화다. 그 임원은 이메일이 도착하기를, 전화가 울리기를, 회의 스케줄이 잡히기를 기다리는 데 익숙해져 있다. 그러니 작은 회사로 왔다고 해서 기다리지 말라는 법도 없을 것이다. 만일 그 임원이 자리에 앉아 무언가를 기다리고만 있다면 다른 직원들은 그를 이상한 눈초리로 쳐다볼 것이다. 그리고 저 인간은 대체 온종일 뭐 하는 거야?” “왜 그렇게 많은 스톡옵션을 받는 거지?”라고 수군거릴 것이다.

둘째는 업무 기술의 부조화다. 커다란 조직을 운영할 때 필요한 기술과 회사를 새로 만들어 키워 나갈 때 필요한 기술은 완전히 다르다. 대기업 임원은 대개 복잡한 의사 결정, 우선순위 확정, 조직 설계, 프로세스 개선, 조직 내 소통 등에 능숙해야 한다.

반면 이제 막 시작한 회사에서는 설계할 팀도 없고 개선할 프로세스도 없으며, 사내 소통도 비교적 단순하다. 하지만 신생기업의 임원은 수준 높은 채용 시스템을 관리하는데 뛰어나야 하고 자기 분야에 대한 탁월한 전문성을 바탕으로 품질 관리를 직접 책임질 수 있어야 한다. 여기에 아무것도 없는 상태에서 프로세스를 만드는 법 또한 알아야 하며 새로운 프로세스를 추진할 때도 높은 창의성을 발휘해야 한다.

원문: https://bit.ly/3dNYw7P


‘프로젝트’ 방식에서 ‘제품 관리’ 방식으로··· CIO들이 전하는 이야기

프로젝트 대 제품 관리

프로젝트 관리와 제품 관리 방식 사이에는 몇몇 차이점이 있으며, 중복되는 부분도 있다. 프로젝트는 새 ERP 시스템 구현 같은 ‘빅뱅’ 이니셔티브, 수동 데이터 업무를 RPA로 교체하는 것 같은 주요한 프로세스 변경 등에 적용되는 경향이 있다.

반면 제품으로 관리하는 방식은 디지털 비즈니스 역량이나 가치 흐름, 규정한 고객 세그먼트에 가치가 있는 고객 지향형 제품에 적용된다. 이를테면 무접촉 트랜젝션을 촉진하는 워크플레이스 애플리케이션 등이 내부 제품이며, 고객이 브랜드로부터 상품을 구입할 수 있는 모바일 애플리케이션은 외부 제품이다.

전통적인 프로젝트 관리는 리소스와 시간을 기준으로 프로젝트 생애 동안 자금을 제공한다. 제품으로 관리하는 방식도 생애 동안 자금을 제공하지만, 그 기반은 비즈니스 니즈(필요사항)이다. 프로젝트는 지정한 고정된 날짜에 끝나지만, 제품은 ‘퇴역’ 할 때까지 계속 개선된다. 프로젝트는 변화를 회피하지만, 제품은 필요에 따라 변화를 수용한다. 프로젝트는 편차나 불일치를 기준으로 추적하지만, 제품은 비즈니스에 제공한 가치를 기준으로 평가한다.

개발의 경우, 대부분 프로젝트가 여전히 폭포수 방법론을 사용한다. 비즈니스 부서가 사업 명세 요건을 작성, IT가 완료하도록 넘겨주는 방식이다. 이에 반해 제품은 IT와 비즈니스 부서 직원들로 구성된 팀이 애자일 소프트웨어 개발 방식을 이용해 만드는 경우가 많다.

한편 진화하는 제품 방식의 경우, 소유권 문제가 생산성에 부정적인 영향을 주는 발목을 잡는 요소가 되기도 한다. 대부분의 프로젝트 관리 모델은 비즈니스 이해관계자가 프로젝트를 지휘한다. IT에 주문을 하고, 납품 주기를 결정한다. 그러나 제품 중심 모델에서는 반드시 그런 것이 아니다. 소유권을 점차 공유하는 모델이기 때문이다.

액센츄어(Accenture)의 기술 전략 및 자문 담당 매니징 디렉터인 다이애나 버손에 따르면, 일부 상황에서는 제품 소유자가 현업 부문에서 IT로 재배치되는 경우도 있다. 중요한 비즈니스 노하우와 제품 지식을 이식하기 위해서이다. 그녀는 “IT와 비즈니스 사이의 경계는 더 이상 중요하지 않다”라고 말했다.

소유권이 원하는 비즈니스 성과를 달성하는 데 있어 그리 중요하지 않은 요소로 보일 수 있다. 그러나 프로젝트 관리 체계에서 일하는 데 익숙한 직원들 사이에 혼란을 야기한다. 이 밖에도 제품 관리로의 변화라는 여정에는 위험과 함정이 가득하다. 에퀴닉스의 웨이글은 “많은 사람들이 이런 어려움을 겪고 있다. 다른 CIO들도 유사한 우려를 표명했다”라고 말했다.

원문: https://bit.ly/3fVEwmo


고민을 아무에게나 털어놓으면 안되는 이유

여러분은 고민이 생기면 어떻게 하시는 편인가요? 저는 곧바로 친구나 지인에게 털어놓는 편입니다. 저를 소중하게 여기는 사람에게 제 고민을 털어놓으면 그들은 진심으로 공감해주고 필요한 조언을 해주기 때문입니다. 여러분도 저처럼 고민이 생기면 빠르게 친구에게 털어놓으시나요? 아니면 혼자 최대한 안고 있다가 부분적으로만 풀어내곤 하나요?

아마도 몇몇은 고민을 털어 놓았다가 오히려 기분이 상하거나, 약점이 잡히고, 소문이 나는 등 부정적인 경험을 했을 수도 있습니다. 이는 고민을 털어놓을 때 꼭 알아야 할 기술을 쓰지 않았기 때문에 발생하는 일이랍니다. 오늘은 알아두면 평생 도움이 되는 ‘고민 털어놓기의 기술’에 대해서 다루어보겠습니다. 이번 글은 조지선 선생님의 글 「내 고민을 남에게 털어놓아도 될까?」를 참고했습니다.

누군가는 고민을 털어 놓는게 아무 의미가 없다고 주장할 지 모르지만, 많은 연구들에 따르면 고민을 털어 놓았을 때 확실히 기분이 나아지는 효과가 있습니다. 여러분의 경험도 이와 다르지 않겠지요. 나의 부정적인 감정을 누군가에게 나누면서 조금은 경감되고, 상대방의 공감과 위로로 힘이 나곤 하니까요.

그러나 심리학자 버나드 리메의 연구에 따르면, 사정을 타인에게 호소한다고 해서, 부정적인 감정상태가 호전되는 건 아니라고 합니다. 고민을 털어놓음으로서 일시적으로 감정이 나아지지만, 부정적인 감정을 발생시키는 문제가 사라지진 않았기 때문입니다.

또한 남에게 과도하게 고민을 털어놓았을 경우, 사람들이 당신에게서 더 멀어지도록 만들기도 합니다. 수천 명의 중학생들을 7개월간 관찰한 실험에 따르면, 속마음을 친구들에게 지나치게 털어놓았을 때 다양한 위험 즉, 이상한 소문과 가십거리의 대상이 되고 왕따로 이어지는 경우가 있다고 합니다. 중학생들을 대상으로 한 실험이지만 우리도 일상적으로 이와 비슷한 결과를 종종 보기도 한다는 데에서 성인에게도 해당되리라고 이해할 수 있습니다.

과도하게 나의 이야기를 털어놓는 것은 위험할 수 있다.
앞서 말씀드린 두 실험에 따르면, 고민을 털어 놓는 것은 큰 효과도 없을 뿐더러 오히려 자신에게 악영향을 끼칠수도 있는 것으로 보입니다. 하지만 이는 말씀드린 것처럼 고민 털어놓기의 기술을 몰랐기 때문입니다. 이제 고민을 털어놓기에 앞서 알아야 할 기술 6가지를 알려드릴게요.

원문: https://bit.ly/2Q8NAJU


뛰는 MVP 위에 나는 MLP(MINIMUM LOVABLE PRODUCT). 성장하는 제품 만들기 1편

근래 스타트업 업계를 중심으로 국내에 그로스 해킹(Growth Hacking) 개념이 들어서면서 애자일, AB 테스트, MVP와 같은 갖가지 방법론도 활발하게 사용되고 있습니다. 특히 MVP(Minimum Viable Product; 최소 기능 제품)는 아무리 작은 조직이라도 사용자에게 맞는 제품을 빠르고 정확하고 경제적으로 구현할 수 있다는 점에서 많은 회사의 선택을 받았습니다. 그러나 성공한 MVP가 늘 성공한 제품이 되는 건 아닙니다.

최소 기능 제품, MVP는 어떤 문제를 해결하는 제품을 만들기 위해 가설을 제시하고 사용자와 시장에서 실제로 작동하는지 확인하고 피드백을 받는 순환과정으로 구성됩니다. 이상적인 방법론입니다. 가설 형식의 제품을 제시하니 제작과 수정이 기민하고, 실제로 써볼 사람들이 방향을 잡아주니 틀릴 일이 없습니다. MVP는 완벽한 것처럼 보입니다. 아이러니하게도 MVP의 큰 특징 중 하나는 불완전성입니다.

‘MVP는 제품 형태일 필요도 없다.’1) Jim Brikman(Y Combinator) 이 말은 제품을 구축하는 방법론 MVP의 막강한 경제성을 보여주는 말입니다. 사진, 동영상, 프레젠테이션, 어떤 것이든 사용자가 기능을 이해할 수 있는 형태이기만 하면 됩니다. 그렇게 해서 수용 가능한 제품을 도출해내는 것이 MVP의 역할입니다. 그런데 위 말을 잘못 받아들여 MVP를 부족한 기능의 제품을 단순히 빠르게 내놓는 것으로 해석하는 경우가 많습니다. MVP가 증명해야 하는 건 제품이지 기능이 아닙니다. 스타트업이 망하는 가장 큰 원인은 자금 문제도, 직원 문제도 아니라 시장에 제품에 대한 니즈가 없는 경우입니다.2) CB Insights, 2019 결국 올바른 가설을 갖고 MVP를 사용해야 제대로 된 인사이트를 얻을 수 있는 것입니다. 그러나 이 올바른 가설을 가리키는 방향성은 MVP에서 찾을 수 없습니다. MVP는 가설을 증명하는 방법일 뿐이니까요. 그럼 어디서 찾을 수 있을까요?

MVP의 구조에서 오는 한계도 있습니다. MVP는 수용할 수 있는 제품을 만듭니다. 그리고 사용자는 수용할 수만 있다면 어떤 제품이든 사용할 수 있습니다. 꼭 내 제품이 아니더라도 말입니다. Facebook, Lime, YouTube. 새로운 제품의 개척자 퍼스트 무버(First Mover)가 아닌 영악한 모방자인 패스트 팔로워(Fast Follower)가 승리자가 되는 구도는 이미 우리에게도 익숙합니다. 사용자가 없다면 제품은 성립하지 않습니다. MVP로 ‘먹히는 어떤 것’을 찾아낼 수는 있지만, ‘내 제품’을 사용해야 하는 이유를 찾아내기에는 부족합니다.

원문: https://bit.ly/3ad9zH1


[일간 애자일#638](1/28) 사람들이 착각하는 MVP에 대한 오해 등

  • 매일 애자일, 린, 조직문화, 협업, 리더십, 자기계발 등과 관련된 새로운 소식을 공유드립니다.
  • 소감, 동의, 반론 등을 댓글로 남겨주세요. 활발한 소통을 기대합니다.
  • 지난 기사는 [여기]에서 보실 수 있습니다

사람들이 착각하는 MVP에 대한 오해

Jason Fried의 ‘Validation is a mirage’를 읽었다.

위 아티클의 핵심 메시지는 ‘제품이 출시되기 전까지 검증할 수 있는 것은 없다.’이다.

많은 사람이 Jason에게 제품 출시 전에 검증을 통해 성공하는 제품을 만드는 방법에 대해 물어보는데, Jason은 이를 파이에 비유해 설명한다. 한 조각의 파이를 먹으면 전체 파이를 평가할 수 있겠지만. 제품은 파이와 같지 않으며 모든 것들이 결합하여 전체를 이루어야 검증 가능한 상태가 된다는 것이다.

지극히 베이스캠프 다운 글이라는 생각이 드는 글이다.

제품 업계에 베이스캠프가 갖는 영향력에 비해 국내에선 의외로 모르는 사람들이 많아 간단히 소개하자면, 베이스캠프는 협업 소프트웨어 Basecamp와 최근 빠르게 성장 중인 이메일 서비스 Hey를 운영하는 시카고에 위치한(하지만 원격으로 일하는) 소프트웨어 컴퍼니로 그들만의 기업 문화와 제품 철학을 담은 Rework, It doesn’t have to be crazy at work, Remote 등의 책을 내기도 했다. 코파운더인 DHH(David Heinemeier Hansen)은 Ruby on Rails의 Original Author이기도 하다.

다시 Jason의 글로 돌아가면, ‘검증은 신기루’라는 제목 때문에 이 글은 마치 MVP(Minimum Viable Product)를 부정하는 것처럼 보인다. 아니나 다를까 트위터 타임라인에 이 글에 대한 여러 사람의 목소리가 갑론을박 하고있다.

그런데 사실 글의 내용을 제대로 살펴보면 Jason은 린 스타트업의 MVP의 컨셉을 부정하지 않는다. 그가 부정하는 것은 오히려 MVP에 대한 사람들의 잘못된 기대라고 볼 수 있다.

  • “How do you validate if it’s going to work?”
  • “How do you know if people will buy it to not?”
  • “How do you validate product market fit?”
  • “How do you validate if a feature is worth building?”
  • “How do you validate a design?”

Jason은 위 질문에 모두 You Can’t이라고 답했다. 그러면 부정한 게 맞지 않냐고? 아니다.

여기서 바로잡아야 하는 것은 MVP가 아니라 잘못된 질문이다.

원문: https://bit.ly/2M0RPFT


PM, PO에 관한 9가지 질문들

시작하며.
스타트업 IT 조직에 속하신 많은 분들과 PM에 대한 이야기를 하면 늘 궁금해하시는 질문들이 있습니다. 9가지 정도를 제 맘대로 간략히 추려서 짧게 설명드리는 글입니다.

  1. PM과 PO는 어떻게 다른가요?

A) 간단하게 정리하자면.

Product Manager = Business의 주요 이해관계자와 상호 작용할 책임이 있는 사람 & 전략 수립
Product Owner = 개발팀과 상호 작용하고 Back-log를 관리하는 사람 & 전술적 역할 수행

※ INSPIRED의 저자 ‘Marty Cagan’ 또한 이 두 직군을 거의 동의어로 대하는 것이 그리 이상하지 않았다고 회고합니다. 이 둘의 구분을 명확히 해야 될 필요성이 없는 경우가 대부분 이기도 했구요. 또한 마티 케이건 스스로도 PM 제품 관리자는 동시에 PO 제품 소유자가 되는 것이 필수적이라고 말하기도 합니다. 그러나 조직 내 비즈니스의 단계가 나아가며 조직 전체의 볼륨이 커지는 경우, 첫 번째 PO는 곧 PM의 역할을 수행하며 다수의 PO를 조직화하여야 합니다. 이를 통해 고도화된 제품을 유기적으로 연결시키는 작업을 PM이 전략적으로 만들어 갈 수 있게 됩니다.

  1. PO와 PM을 나누는 경계가 있을까요?

A) 생각보다 많은 조직에서 이 직군의 명칭을 두고 혼란스러워합니다.

조직의 규모에 따라 PO와 PM 모두의 역할을 수행할 수 도 있으며, PM과 PO의 역할이 딱 나눠지기도 합니다. 두 직무는 책임을 지는 범위가 다릅니다. 그렇기에 이 둘을 나누는 질문을 한 가지로 압축하자면 아래와 같습니다.

PO와 PM을 나누는 핵심 질문 TIP)
조직에서 개발팀과 함께 back log만 관리하고 있습니까? > PO
아니면, 실제로 고객과 비즈니스의 어려운 문제를 주요 이해관계자와 함께 조율하며 해결 중이십니까? > PM

….

원문: https://bit.ly/3ppIdmd


팀장 월급엔 ‘싫은 소리할 의무’도 포함돼 있다

팀원들의 강점을 찾아내어 칭찬하고, 동기 부여를 통해 부족한 점은 스스로 개선하도록 돕는 게 팀장의 역할이다. 칭찬에 인색한 리더들도 있지만, 잘하는 걸 잘한다고 말해주는 건 그래도 쉬운 일이다. 문제는 부족한 점을 개선하도록 이끄는 것이다. 누군가 자기가 잘 못하는 걸 콕 집어서 “넌 이런 점이 부족하다”고 말하면, 대부분의 사람들은 민망해하거나 좌절한다. 때로 화를 내는 이들도 있다. 이성적으로 생각할 땐 사실을 겸허히 받아들이고 노력하면 되는 일인데, 이게 참 안 된다.

본인의 오랜 직장 경험상 비슷한 감정들을 느껴 온 팀장들은, 싫은 소리를 할 때 부담을 느끼게 된다. 가능하면 부정적 피드백을 최대한 자제하고자 한다. 어쩔 수 없이 얘기해야 할 시점이 오면, 상처받지 않게 간접적으로 표현하려 애쓴다. 결국 팀원은 팀장이 무슨 말을 하고 싶은지를 정확히 이해하지 못하고, 왠지 모를 불편한 면담분위기에 기분만 상한 채 자리로 돌아간다.

요즘 사람들은 과거에 비해 감정적으로 솔직함을 훨씬 더 선호한다. 마음이 좀 아프더라도, 있는 그대로의 팩트를 알고 싶어한다. 빙빙 돌려 말하면 오히려 오해가 더 깊어진다. 얽히고 설킨 암호를 해석을 하다 보면, 말하는 사람의 처음의 취지와는 다른 결론으로 이어진다. 그러니 문제 상황을 정확히 짚어 피드백을 하는 게 백배 낫다. 물론 이때 감정은 빼고 말해야 한다.

어떤 팀장들은 말한다. “그런 식으로 전달하는 건, 좀 비인간적인 거 아닌가요?” 하지만 냉정히 말해, “팀원이 상처받지 않게 싫은 소리 하는 방법”이란 없다. 원래 싫은 소리는, 어떤 말을 갖다 붙여도 기분 나쁘다.

필요한 순간에 싫은 소리 하는 걸 두려워할 필요가 없다. 본인이 혹시 나쁜 리더인지 걱정할 필요가 없다. 팀장의 월급에는, “회사와 팀을 위해 싫은 소리를 해야 하는 역할”에 대한 보상이 포함되어있다. 잘못된 일을 바로잡으며 팀원의 행동을 개선시키는 건 팀장의 피할 수 없는 핵심 업무다. 인격적 모독을 하거나 상처를 주는 극단적 단어들은 당연히 피하되, 할 말은 해야 한다. 만약, 그렇지 못하고 있다면, 당신은 팀장의 역할을 제대로 수행하지 못하고 있다는 뜻이니까.

원문: http://bit.ly/36jJzaH


테일러리즘을 다시 생각해본다

“측정되지 않는 것은 관리되지 않는다”는 피터 드러커의 말은 오늘날 경영현장에서 가장 많이 쓰이는 격언이 아닌가한다. 그는 그의 저서 <내일을 지배하는 것, 1999>에서 테일러를 일컬어 “그의 과학적 관리법과 그 뒤를 잇는 IE(산업공학)이야말로 세계를 변화시킨 미국의 지혜”라고 극찬했다.

우리가 성과를 관리하기 위해서 작업의 표준화, 작업표준, 표준시간, 전문화된 스탭 조직 등을 갖추는 것은 누구나 알고 있는 상식이지만 또 그게 잘 갖추어진 회사도 드물다. 또는 이를 오용하여 수백개의 KPI를 만들기만하고 지키기도 힘든 지표 관리를 하는 조직들도 있다.

성과관리에 대해 다시 생각해보자. 우리가 성과를 관리해야 하는 목적과 이유는 무엇인가. 테일러가 작업 표준을 만들어 관리한 것은 결국 모두가 더 효율적으로 일하고 생산성을 높이기 위해서다. 오늘날엔 그러한 그의 가치와 철학보다는 초시계로 측정하는 것만 남아있는 것은 아닐까. 우리가 ‘성과 관리’에서 필요한 것은 센서가 아니라 업무 시간의 절감과 생산성의 개선이라는 점을 생각해봐야 한다. 관리를 위한 관리, 평가를 위한 측정 이런 것은 100년전의 그가 생각하던 모습도 아닐 것이다. 오늘날 “성과 관리”라고 이루어지고 있는 수많은 행동들이 결과적으로는 성과에 악영향을 미치고 있는 것은 아닌지 돌아보아야 한다.

원문: https://bit.ly/3iTnWD9


자신을 빠르게 성장시키는 ‘회고’

회고는 자주 할수록 좋다

많은 사람은 ‘경험’을 통해서 배운다고 말합니다. 하지만 실제 우리가 배우는 것은 ‘경험’ 그 자체가 아니라 경험 후 스스로에 대한 ‘회고’를 통해 배우게 됩니다. 그렇지 않으면 반복되는 경험 속에서도 우리는 필연적으로 똑같은 실수를 하고 맙니다. 결국 ‘성장’을 위해 조금은 귀찮지만, 반드시 자신을 ‘회고’하는 작업이 필요합니다.

우리는 매년 1월 1일이 되면 지난해를 회고하고 새로운 해를 계획합니다. 회고에서 가장 중요한 점은 기존의 일들을 하나둘 톺아보는 일인데 1년 치를 하나하나 되돌아보는 일은 여간 쉽지 않습니다. 그러다 보니 어느덧 회고는 귀찮아지고 대충대충 지나가 버리게 되거나 새로운 계획 세우기에만 시간을 쏟게 됩니다. 그래서 우리가 잘한 점 잘못한 점을 보다 분석적으로 살피기보다는 개괄적으로 훑고 넘어가 버리게 됩니다. (물론 회고를 아예 하지 않는 것보다는 나을 겁니다)

머리에 남기지 못하는 회고와 개선을 위한 대책을 세우지 못하는 회고는 결국 내년에 같은 실수를 반복하게 만들 확률을 높일 뿐입니다. 게다가, 1년마다 ‘성장’의 단추를 끼우는 일은 5G 시대에 너무 더딘 일이기도 합니다. 그래서 회고의 부담을 덜기 위해 1주일 단위로 회고를 하는 것이 가장 좋습니다.

1주일은 기억하기도 돌아보고 회고하기도 쉽습니다. 저는 현재 TickTick 을 통해 돌아보는 작업을 진행합니다. 특히 Summary 기능이 있어서 기존에 끝내거나 끝내지 못한 업무들을 한눈에 볼 수 있어 편리합니다.

또한 캘린더 또는 Day One에 기록해두었던 일기들을 돌아보며 잘했던 점, 아쉬웠던 점 그리고 개선할 점들을 적어 다시 Day One에 회고를 적어 둡니다. 한 주간을 나름의 점수로 표현하는 것도 좋은 방법입니다. 이를 통해 매주 회고를 통해 한주 한주 자신만의 기준을 만들 수 있습니다.

원문: https://bit.ly/2NIvYU4


[일간 애자일#595](11/18) 연말 평가 결과 수용하나요? 등

  • 매일 애자일, 린, 조직문화, 협업, 리더십, 자기계발 등과 관련된 새로운 소식을 공유드립니다.
  • 소감, 동의, 반론 등을 댓글로 남겨주세요. 활발한 소통을 기대합니다.
  • 지난 기사는 [여기]에서 보실 수 있습니다.

연말 평가 결과 수용하나요?

평가결과를 수용하지 못하는 가장 큰 원인은 면담과 피드백의 부족이다. 아직도 많은 기업들이 평가결과를 본인에게 공개하지 않고 있다. 평가에 대한 불만 증가의 원인으로 공개 자체를 하지 않는다. 이런 회사의 공통점은 평가를 보상과 승진의 수단으로 볼 뿐, 육성의 차원으로 생각하지 않는다. 목표를 부여하고 평가를 하는 이유는 조직과 구성원의 역량을 강화하고 성장시켜, 회사가 지속 성장하도록 성과를 창출하는데 있다. 어떤 마음가짐으로 일에 임하고, 어떻게 일을 해야 하며, 좋은 성과를 창출하기 위해 어떤 절차를 가져가는 것이 효과적인가 고민하고 실천하게 해야 한다. 현재 조직과 구성원의 수준을 알려줘 한 단계 올리기 위한 목표를 수립하고 실천하도록 지도하고 코칭해줘야 한다. 관심을 갖고 관찰한 기록을 중심으로 강점과 보완점을 제시하여 본인이 깨닫도록 해야 한다. 정규적, 비정규적으로 개별 면담 등 다양한 방법으로 피드백을 해줘야 한다. 문제는 이러한 활동을 전혀 하고 않다가 연말에 머리 속의 간직된 기억을 중심으로 평가를 하니 수용도가 높을 수 없다. 평가자들은 업무 지시와 보고 과정에서 충분히 면담했다고 한다. 하지만, 구성원은 이를 면담이라고 생각하지 않는다. 지시 받았다고만 생각한다.

면담과 피드백은 최소 월별 일자를 정해 일관성과 지속성을 가지고 진행하는 것이 옳다. 월간 업적과 역량 실적과 계획, 잘한 일, 제언 및 개선 사항, 조직장에게 하고 싶은 말을 중심으로 먼저 구성원이 이야기하도록 해야 한다. 그 월이나 주에 했던 업적과 역량 실적과 계획에 대해서만 대화를 나눠야 한다. 면담과 피드백은 가능한 20분 이내 마무리 짓는 것이 좋다.

평가자로서 나는 어느 수준인가?

1. 나는 직장의 목표, 상사의 목표, 나의 목표와 직원의 목표를 잘 알고 있다.

2. 나는 구성원의 역량 수준을 고려하여 면담을 통해 남은 기간 목표를 조정해 준다.

3. 나는 목표설정과 중간 과정에 대한 피드백을 중심으로 남은 기간 목표달성에 매진하게 한다.

4. 나는 목표달성 여부를 피드백하고 기록하고 있다.

5. 나는 구성원의 목표, 달성 수준과 내용, 진척율을 명확하게 알고 있다.

6. 나는 구성원이 원하는 바를 알고, 장점과 보완점을 제시해 주고 있다.

7. 나는 면담과 피드백을 통해 구성원이 무엇을 해야 하는가를 분명히 제시했다.

8. 나는 구성원에 대해 수시로 상사에게 이야기하며 조언을 받는다.

9. 나는 팀의 내년도 사업계획 뿐 아니라 어떻게 달성할 것인가 설정해 놓았다.

10. 나는 현재 내년도 팀원 개개인의 성과와 역량에 대한 목표를 갖고 있다.

원문: https://bit.ly/32TcH73



과정이 공정해야 결과에 수긍한다

리더가 연말 평가에서 승진 예정자에게 후한 점수를 주는 이유는, 그에게 1년 동안 별다른 지원이나 관심을 주지 못했다는 ‘마음의 빚’에 있다. 결국 리더가 이런 마음을 바꿔야 한다. 방법은 쉽다. 진급 대상자는 연초부터 특별 관리를 하면 된다. 크게 세 가지 방법이 있다.

1. 승진 예정자가 남들보다 더 나은 성과를 낼 수 있도록 공격적 목표를 세우게 하자. 조직의 오랜 문제를 풀어낼 수 있도록 과제를 주거나, 실적을 높일 수 있도록 상향된 목표를 주는 식이다. 일단 지향점 자체를 높게 잡는 게 중요하다.

2. 목표 달성을 위해 리더가 적극적으로 지원을 해야 한다. 말로만 “잘해봐!”라고 하는 건 지원이 아니다. 2개월에 한 번 정기적 미팅을 통해 진척 상황을 체크하거나, 조직이나 리더가 지원할 사항은 없는지 꼼꼼히 확인해야 한다. 다른 구성원들이 불공평하다고 느끼지 않겠냐고? 아무것도 하지 않은 채 때가 됐으니 승진시켜주는 리더와, 승진 예정자가 더 나은 성과를 내도록 지원하는 리더, 구성원들은 두 사람 중 누구를 더 믿고 신뢰할까? 답은 너무 쉽다.

3. 평가 가산점을 받을 수 있는 수명 업무의 기회를 주는 것이다. (수명 업무: 계획에 없었으나 즉시 착수하고 실행해야 하는 업무) 승진은 리더 혼자 노력한다고 가능하게 만들 수 있는 게 아니다. 리더의 상급자도 이 직원의 ‘공’을 느낄 수 있도록 수명 업무를 적극적으로 내려주는 것이 좋다. 기회를 주는 것과 특혜를 주는 것은 다르다는 사실을 잊지 말자.

자, 이렇게 리더가 관심을 갖고 지원을 해줬는데도 목표를 달성하지 못했다면? 그 직원에게 승진의 기회를 줄 수는 없다. 바로 이게 공정한 성과평가다. 승진 시기를 놓친 구성원에게서 올 불만은 어떻게 감당하느냐고? 이렇게 기회를 주고 지원을 해줬는데 목표를 달성하지 못해서 기회를 놓쳤다면, 누가 미안해할까? 이것이 리더의 진정성 있는 특별 관리가 필요한 이유다.

원문: https://bit.ly/3nAWWd4


유니콘들의 MVP는 이렇게 달랐다

유니콘의 MVP에서 나타나는 공통점은 다음과 같은 4가지로 정리해 볼 수 있을 듯합니다.

1. 혁신적인 아이디어가 있을 때, 모든 것이 완벽하게 갖춰진 제품을 만들어서 배포해야 한다는 생각은 하지 않습니다. 반복적이고, 점진적인 방법으로 사용자 경험과 피드백을 반영하면서 핵심가치를 꾸준히 보여주는 방법으로 접근합니다.

2. 성공적인 스타트 업의 대부분은 핵심가치에 최대의 초점을 맞추고, 그 외 기능은 최소한으로만 제공하였지만, 그 사실을 정확하게 잘 구별하는 타겟 사용자층에게 접근했습니다.

3. 타겟 사용자에게 MVP를제공하면서 사용자 피드백을 최우선으로 제품에 반영하였습니다.

4. 성공적인 제품 로드맵은 항상 MVP에서 시작과 검증에서 비롯됩니다. 필수를 먼저 제공하고 시간이 지남에 따라 점진적인 방법으로 사용자가 원하는 기능을 채워가면서 완성도를 높입니다.

원문: https://bit.ly/2Uz3hZJ