brunch

You can make anything
by writing

C.S.Lewis

by 성장중독자 Oct 11. 2023

팀빌딩 100% 망하는 방법 #2

타율 1할, 스타트업 실패 전문가의 이렇게 하면 무조건 실패한다.

이전 아티클에 이어서 이번에는 팀 구성, 방출에 대한 내용입니다. 잘 성장하는 팀도 망하게 하는 눈부신(?) 노하우를 지금 확인하세요!

성장중독자와 함께 성장, 스타트업, 제품에 대해 이야기하실 분!



여섯 번째,

테이커의 비율이 높은 팀 구성을 한다.

비율이 너무 높으면 성장하는 팀이 아니라 경쟁하는 팀이 될 가능성이 높습니다.


자기가 성취한 것은 이야기 잘하는데 어떻게 잘할 수 있게 되었는지 노하우 공유가 없다.
회고 때 다른 사람을 평가하는 의견이 많고 자신에게 방어적인 태도를 취하는 사람이 많다.
니일, 내일을 나누고 R&R에 대한 정의를 가능하면 명확하게 하려는 사람이 많다.


실패할 수밖에 없는 이유.

Team Work가 잘 맞아야 한다는 의미는 팀원들의 MBTI나 혈액형 보다 Giver / Taker 성향의 파악이 더 중요합니다.

:  Taker들은 자신을 중심으로 우선순위를 정하는 성향이 있기 때문에 공통의 이익이나 타인을 위해 손해를 감수하려 하지 않습니다. 또한 업무를 조율하지 못하고 자신의 주장을 관철하려고 에너지를 쓰고, 자신의 뜻과는 반대되지만 전체의 의견으로 결정되어 따라야 하는 경우에 납득하지 못하고 비 협조적이 되는 경향이 있습니다. 소수일 때에는 Giver들이 커버를 해 주게 되지만 다수의 비율이 되는 경우에는 업무 진행이 되지 않고 반목이 심해지는 상황이 발생하게 됩니다. 새로운 구성원을 영입할 때 영입의 대상이 되는 팀의 성향 비율이 어떻게 되어 있는지, 새로 합류하는 사람의 성향이 어떤지 미리 따져볼 필요가 있습니다. 



일곱 번째,

경험이 적은 PM(PO)에게 팀 리딩을 위임한다.

새로 구성하는 팀이라도 경험이 적은 사람에게 팀 리딩을 맡기면 절대 안 됩니다.


자기가 무슨 말을 하는지 알고 있는 건가?
이런 것도 일일이 리더에게 물어볼 거면 도대체 역할이 뭐지?


실패할 수밖에 없는 이유.

명시적인 리더로 선임하지 않더라도 제품개발의 중요 의사결정을 하는 비율이 높다면 팀을 리딩하는 포지션이라고 볼 수 있습니다.

:  일하는 문화(방식)에서 PM(PO)가 제품 개발 일정, 범위, 정책, UX/UI 디자인 리뷰 등 넓고 깊은 범위의 의사결정에 관여하는 역할이라면 팀 리더라는 직함이 없어도 실질적으로 그 사람을 중심으로 제품팀이 돌아가게 됩니다. 그런 환경에 경험이 없는 PM(PO)가 stand alone 하게 그 역할을 하길 기대한다면(제품팀의 다른 구성원들이 도와준다는 전제로) 너무 욕심이 크다고 말씀드리고 싶습니다. 



여덟 번째,

팀의 목표, 미션에 맞는 구성이 아니라 레고 블록 맞추기 구성을 한다.

클라 1명, 서버 2명, 디자인 1명, 기획자 1명 이렇게 팀 빌딩을 하면 안 됩니다.


이번에 우리가 뭘 한데요?
B2C 제품을 하나 개발한다고 들었어요. 3개월 내에 승부 봐야 한다고 하던데요?


실패할 수밖에 없는 이유.

새로운 팀빌딩은 그 팀이 해야 하는 일이 아니라 미션, 목표를 먼저 정하고 그것을 잘할 수 있는 사람을 모아야 합니다.

:  일을 하기 위한 필요충분조건의 조합으로 팀 빌딩을 하게 되면 팀이 하나가 되기 위한 Why?를 만들어 주지 못합니다. "그걸 왜 나한테 바라는 거지?", "왜 제가 그것까지 해야 하는 거죠?" 이런 생각을 구성원들에게 들게 만들게 됩니다. 

어떤 목표를 달성하기 위해 새로운 팀이 필요한지, 그 목표를 달성하면 회사에 팀에 어떤 기여를 하게 되는지를 먼저 정의하고 그것을 잘 수행할 수 있는 구성원을 선정해야 합니다.

예상하셨듯이 새로운 팀에 속하게 되는 구성원들에게는 무엇을 만들어야 한다를 먼저 이야기하는 것이 아니라 목표와 그 목표를 달성하기 위한 미션, 그리고 이 목표를 잘 달성할 수 있는 사람으로 선정된 것이라는 내용을 먼저 이야기해야 합니다. 그래야 하나의 목표의식을 가진 '팀'이라는 정체성을 만들기 용이해집니다.



아홉 번째,

방출의 이유를 당사자를 제외한 다른 구성원들이 공감하지 못한다.

방출하는 이유를 같은 팀 구성원들에게 잘 공유하는 것이 필요합니다.


'이번에 000님 왜 그만두시는 거예요?'
'몰랐어요? 그만두는 게 아니라 방출이래요.'
'왜요?'
'공유받기로는 역할이나 기대치에 대해서 여러 번 피드백이 있었는데 잘 안되다고 해요.'
'응?! 000 업무 잘해서 이번에 성과 잘 나오지 않았나요?'
'저도 잘 모르겠어요. 짧게만 공유받아서..'


실패할 수밖에 없는 이유.

구성원의 방출은 팀 사기에 큰 영향을 주기 때문에 불필요한 오해를 최소화해야 합니다.

:  방출에는 여러 가지 이유가 있을 수 있습니다. 이런 이유들에 대해서 적어도 같은 팀에는 명확하게 공유되는 것이 필요하다고 저는 생각합니다. 방출되는 사람을 위해서 에둘러서 모호한 표현으로 방출 사유를 이야기하거나 여러 방출 이유 중에서 일부만을 공유하게 되면 남아 있는 구성원들에게 다음과 같은 혼란을 줄 수 있습니다. 1) 고용의 불안정성 : '나도 그냥 잘리는 거 아냐?' 2) 리더십에 대한 불신 : '왜 방출시키는 거지? 어떤 기준이 있는 건가?' 

리더십은 방출이라는 의사결정까지 힘들고 고통스러운 일이겠지만 방출이 결정되었다면 남아 있는 팀의 구성원들이 최소한의 영향을 받을 수 있도록 신경 써야 한다고 저는 생각합니다. 

누구에게만 방출 이유를 이야기하고 누구는 이야기 안 하는 커뮤니케이션은 더욱 안 좋은 방법이니 투명하게 공개할 수 있는 범위 내에서 커뮤니케이션하시는 선택을 하시길 바랍니다.



열 번째,

구성원을 내보내는 것을 망설인다. (그 이유가 분명한데도 불구하고)

방출을 망설일수록 핵심인재가 이탈하거나 팀의 신뢰가 무너질 확률이 커진다고 생각해야 합니다.


'그래도 힘든 창업부터 함께 고생해 온 사이인데..'
'당장 방출하고 나면 그 일을 대체할 사람이 없는데..'
'이건 그래도 잘하는데..'
'방출은 처음이라 뭐라고 말해야 할지 막막한데..'


실패할 수밖에 없는 이유.

개인의 호불호, 감정적 방출이 아니라 명확한 방출의 이유가 있는 것이라면 빠르게 실행해야 합니다.

:  방출해야 하는 구성원이 있다면 그 구성원으로 인해 발생하는 비효율, 리스크가 있다는 것이겠지요. 그것에 영향을 받는 것은 같은 팀의 구성원, 팀의 생산성, 제품의 성과 더 나아가 회사의 성과에 영향을 줄 수 있습니다. 특히 구성원이 작은 규모의 스타트업일 경우 더욱 두드러지게 됩니다.

이런 비효율과 리스트가 시간이 갈수록 누적되고 있는 상황을 인지하고도 빠르게 실행하지 않는다면 물이 새고 있는 걸 알면서 막지 않는 것과 같다고 생각합니다. 양심의 가책, 개인적인 친분, 방출된 동료의 비난 등이 두려워서 결단의 시간이 길어져서는 어려움이 더 커질 수밖에 없다는 걸 생각해 보시길 바라겠습니다.



제가 경험했던 다양한 실패의 경험을 공유하는 것을 통해서 다른 분들의 학습 비용이 낮아지거나, 현재 어려운 상황에 처한 Product Manager, Product Owner, CEO 분들이 문제를 해결하는데 도움이 되길 바라며 작성합니다.


경험에 의존한 내용으로 검증된 방법론이나 이론이 아닙니다. 편향된 방향으로 기술된 내용이 일부 포함 될 수 있으며, 이로 인해 불편하시거나 이견이 있으신 분들은 편하게 알려 주시면 저의 성장의 기회로 생각하겠습니다.


성장중독자와 함께 성장, 스타트업, 제품에 대해 이야기하실 분!


Cori  Emmalea Rodriguez님의 사진: https://www.pexels.com/ko-kr/photo/1187086/


                    

이전 09화 팀빌딩 100% 망하는 방법 #1
brunch book
$magazine.title

현재 글은 이 브런치북에
소속되어 있습니다.

작품 선택
키워드 선택 0 / 3 0
댓글여부
afliean
브런치는 최신 브라우저에 최적화 되어있습니다. IE chrome safari