[일간 애자일#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


글쓴이: 정의의소

Agile Coach, Organizational Change Coach @Samsung Electronics 팟캐스트 MC : 새꿈사 (새로운 조직문화를 꿈꾸는 사람들)

답글 남기기

아래 항목을 채우거나 오른쪽 아이콘 중 하나를 클릭하여 로그 인 하세요:

WordPress.com 로고

WordPress.com의 계정을 사용하여 댓글을 남깁니다. 로그아웃 /  변경 )

Google photo

Google의 계정을 사용하여 댓글을 남깁니다. 로그아웃 /  변경 )

Twitter 사진

Twitter의 계정을 사용하여 댓글을 남깁니다. 로그아웃 /  변경 )

Facebook 사진

Facebook의 계정을 사용하여 댓글을 남깁니다. 로그아웃 /  변경 )

%s에 연결하는 중