사일로 효과(Silo effect) 대처법
부서 간의 기싸움 어디까지 해보셨어요?
사일로 효과(Silo effect)의 사일로(Silo)는 곡식 등을 저장해두는 큰 원형 기둥 모양의 창고다. 이 단어에서 유래한 사일로 효과(Silo effect)란 조직의 각 부서들이 각자 이 원형 기둥을 쌓고, 소통하지 않는 현상을 뜻한다. '부서 이기주의'로 번역하기도 한다.
사일로(Silo) 예시조직에선 앙숙일 수밖에 없는 부서들이 존재한다. 대부분 조직 간의 이해관계가 달라서 앙숙이 된 경우다.
재무(돈을 관리해야 하는 부서) VS 영업(돈을 써야 하는 부서)
홍보/마케팅(제품을 알려야 하는 부서) VS 제품(제품을 만들어야 하는 부서)
인사(사람을 관리해야 하는 부서) VS 기타 팀(사람을 뽑아야 하는 부서)
IT 업계로 한정해서 살펴보면, 부서 간의 입장은 이러하다. 재밌는 건, 회사 규모와 상관없이 IT 업계에서는 대부분 갈등의 양상이 비슷하다는 점이다.
기획(우리가 기획한 방향과 정책에 맞게 해주세요!) VS 디자인(그러면 디자인이 너무 구린데요?)
기획(이만큼 만들어야 하는데 이때까지 해주세요!) VS 개발(그러면 시간이 모자란데요?)
디자인(이 디자인이 구현되게 해주세요!) VS 개발(그러면 추가 공수가 드는데요?)
홍보/마케팅(다음 주부터 마케팅 시작합니다!) VS 기획/개발(아니 우리 아직 개발 중인데요?)
영업(거래처에 00 기능 된다고 했는데.. 되죠?) VS 기획/개발(???????????)
처음 스타트업에서 근무를 시작할 때는 부서 간 갈등이 거의 없을 거라고 생각했다. 일단 첫 번째는 한 줌밖에 안되는 회사에서 갈등 있을 것이 있나 싶었고, 두 번째는 다들 오너십이 강하니까 생각을 동기화하기 쉬울 것이라고 짐작했다. 그리고 당연히도, 이 생각은 완전히 틀렸다. 오늘은 두 가지 갈등 사례와 해결 사례를 소개하고자 한다.
갈등 사례 1. 제품을 만드는 팀과 제품을 판매하는 팀 간의 충돌
당시 회사에는 홍보/마케팅/영업을 모두 담당하는 그로스(Growth) 팀이 있었다. 마크는 그 팀의 매니저였는데, 아이디어 뱅크인데다가 여러모로 회사 일에 관심이 많은 타입이었다.
모든 PO들이 해결해야 할 숙제이기도 한데, 제품을 시장에 내놓을 시기와 실제로 회사 내부에서 제품 론칭을 기대하는 시기가 같기란 참 어렵다. 그로스 팀인 마크는 당연히 '제품을 시장에 내놓을 시기'를 한시라도 빨리 확정 짓고 싶어 했고, 가급적이면 홍보/마케팅과 영업에 유리한 시기로 맞추고 싶어 했다.
그러나 제품을 만드는 팀인 우리 팀의 입장은 달랐다. 새로운 기능 개발에 사활을 걸 것인지, 기존 성능 유지 보수에 초점을 맞출 것인지 고민하고 따져보아야 할 지점들이 많았다. 리텐션(Retention; 기존 고객을 유지하는 것)을 생각해야 할 시점이었다. 무조건 새로운 기능을 만드는 것이 유리하다고 볼 수는 없었다.
가장 어려웠던 점은 제품 개발의 우선순위를 결정할 때 마크가 참여하고 싶어 했다는 점이다. 철저하게 PO의 입장에서, 제품 개발 우선순위는 우리 팀 고유의 영역이어야 했다. 제품이 있어야 이 제품을 가지고 판매할 수 있는 것 아닌가. 약간은 월권이라고 느끼기도 했다. 그렇지만 돌이켜 보면 그로스 팀의 입장에서는 영업을 하며 외부 제휴사 고객과 만나는 지점이 많다 보니 이 부분을 우리 팀에 전달하고 싶었던 의지가 컸던 것 같다. 당시에는 나도 조금 민감하게 반응했던 게 사실이다.
해결 사례 1. 입장의 격차 좁히기
생각보다 이 갈등은 꽤 오랜 시간 지속되었다. 매달 C 레벨과의 1on1 때마다 이 얘기가 나왔으니까 말이다. C 레벨은 나에게 조언을 구하기도 했고, 요청을 하기도 했다. 우리는 더욱 소통에 초점을 맞추어야 한다고 판단했다. 그래서 만들어진 것이 제품 관련 미팅(Product meeting)이다. 월 1회 진행하는 이 미팅에서는 제품팀의 PO와 그로스 매니저가 참여하여 한 달 동안의 업무 계획을 공유하고, 이에 맞춘 판매 계획을 의논하도록 했다.
제품에 CS를 반영하기 위한 노력도 있었다. 그로스 팀에서는 CS의 유형과 빈도, 강성 민원 여부를 표로 만들어서 매주 업데이트해주었고, 우리 팀에서는 이 내용을 어떻게 처리할지 건별로 답변을 해주었다. 추가 개발이나 수정이 필요한 부분은 지라 티켓으로 발행해 업무 백로그로 쌓이도록 했다.
무엇보다도 우리가 공동의 목표를 가지고 있는 크루라는 점을 잊지 않기 위해 노력했다. 그로스 팀과 조금 더 자주 스킨십하기 위해 애썼는데, 특히 마크와는 사사로운 DM을 주고받으며 내적 친밀감 쌓기에 집중했다. 그래야 앞으로 업무할 때 불필요한 오해가 발생하지 않을 것 같았기 때문이다. 실제로 우리 팀이 비협조적이라고 생각했던 마크의 오해를 해소할 수 있었다.
갈등 사례 2. 같은 제품을 만들지만 서로 다른 팀 간의 견제
당시에는 회사에 총 3개의 개발 부서가 있었는데, 그중 1개는 우리 팀 외부에 있는 연구 팀이었다. 연구 팀이 제품의 코어를 개발하고, 제품 팀인 우리 팀은 그 코어 개발사항을 반영해 제품에서 구현되도록 하는 업무를 맡고 있었다.
어느 날 연구 팀이 업데이트를 준비하겠다고 당일 아침에 알려왔다. 업무 구조상 연구 팀이 업데이트를 하면 해당 내용을 우리 팀이 다시 제품에 업데이트해야 제품에 반영되는 방식이었는데, 물론 당일에 양 팀이 업데이트를 할 필요는 없지만 굳이 제품 사양을 높이는 일을 미룰 필요는 없으므로 연구 팀 업데이트가 완료되는 대로 우리 팀도 반영할 생각이었다.
문제는 연구 팀의 업데이트가 저녁 8시를 넘긴 시간에 완료되었다는 점이다. 여기서 내가 큰 실수를 했는데, 확실하게 일정을 확인하지 않고 '아 오늘은 업데이트가 없나 보네. 내일 다시 일정을 물어봐야겠다.'라고 지레 짐작하고 퇴근해버린 것이다. 하필 그날 내가 재택근무였던 지라 오며 가며 슬쩍 물어볼 기회조차 없었다. 그래서 저녁 8시가 넘어 업데이트가 완료되었다는 알림을 받은 나는 우리 팀은 내일 업데이트를 하겠다고 슬랙에 답장을 남겼다. 그러자 연구 팀의 매니저인 헤일리가 불같이 화를 냈다.
"우리 연구 팀은 남아서 야근까지 했는데, 이렇게 해도 나서서 도와주는 개발자 하나 없고 엉망이네요."
이 사건 역시도 입사 초기에 있었던 지라 아직도 헤일리의 텍스트가 생생히 기억난다. '엉망'이라는 비난(?)을 받고 난 후 나의 의식의 흐름은 이랬다.
'아, 업데이트 일정을 내가 확인했어야 하는데 내 실수다.'
'그런데 애초에 업데이트가 늦어지면 지연된다고 공유해 줬어야 하는 거 아닌가? 아무리 자율 출퇴근제라지만 9 to 6가 기본 아닌가. 우리 팀이 언제까지 근무할 줄 알고...'
'그럼 헤일리 말은 우리 팀이 계속 무한대기 했어야 한다는 건가?'
'오류도 아니고 마이너 한 성능 업데이트인데 그 팀이 야근한 걸 왜 나한테 화내지? 내가 요청한 것도 아닌데.'
'아 그래서 어쩌라고.'
업데이트 일정이 사전 공유된 것도 아닌 데다가 그 팀이 업데이트를 했다고 해서 반드시 우리 팀이 업데이트를 해야 하는 것은 아니기 때문에 사실 억울한 면이 없지 않았지만, 나는 불필요한 비난으로부터 우리 팀을 지켜야 할 의무가 있었다. 그래서 <이 일은 내가 일정을 확실하게 체크하지 못한 내 책임이며, 지금은 이 일정을 공유 받지 못한 개발자들이 모두 퇴근한 상태이니 내일 출근한 뒤 바로 반영하도록 하겠다. 불편을 드려 죄송하다>는 메시지를 슬랙 전체 채널에 보내두었다.
다음 날, 이번에는 우리 팀 개발자들이 뿔이 났다. 왜 저쪽 팀이 우리 팀 일정에 감놔라 배놔라 하는 것이며, 헤일리 발언은 우리 팀을 존중하지 않는다는 것이다. 어느 정도로 이 일이 심각했느냐 하면, 이번 일로 헤일리가 공개적으로 사과하지 않을 시 무려 퇴사를 하겠다는 충격적인 선언까지 나올 정도였다(...).
해결 사례 2. 할 말은 하되, 해야 할 것 하기
공교롭게도 바로 다음 날 리더 미팅이 있는 날이었고, 헤일리는 다시 한번 이 일을 화두로 꺼냈다. 헤일리는 어제 일에 덧붙여 우리 팀의 개발 속도가 느리다며 지적하기도 했다. 앞으로의 협업과, 우리 팀원들을 생각해서라도 이 일은 분명히 짚고 넘어갈 필요가 있었다. 그래서 <그런 발언은 삼가달라고 요청했고, 우리 팀은 우리 팀만의 계획과 일정이 있음을 존중해달라>고 전했다. 덧붙여 <어제 일에 대해 엄연히 따지면 당일 업데이트를 알려 온 연구 팀에도 책임이 있으며, 시시비비를 가려야 한다>고 언급했다.
그리고 정기적인 업데이트 일정을 정했다. 우리 팀의 정기 업데이트는 매 스프린트(Sprint; 업무 목표를 달성하기 위한 반복적인 업무 주기)마다 1회로 고정하였고, 연구 팀의 비정기 업데이트는 우리의 정기 업데이트 일정에 1-2일 앞선 날로 협의했다. 즉, 연구 팀의 업데이트를 반영하기 위해서는 우리의 정기 업데이트에 맞추어 달라고 요청한 것이다.
불필요한 감정 소모 및 팀원들의 사기 저하를 막기 위해 앞으로 슬랙에서의 공개적인 지적이나 비난은 삼가줄 것을 다시 한번 당부하기도 했다. 특히, 우리 팀 특정 인물의 개발 능력이나 속도를 지적하는 것은 적절하지 않으며 이 부분은 차라리 리더 미팅 때 공유해주십사 전달했다. 그리고 여기서 협의한 모든 내용은 데일리 스크럼을 통해 팀원 모두에게 전달했는데, 앞으로 이런 일이 없을 것이라는 약속을 하고 나서야 모두의 노여움을 풀 수 있었다.
신생 스타트업은 대부분 1개의 단일팀으로 시작한다. 그러다 보니 조직이 커지고, 팀이 생기면서 일어나는 문제들을 간과하거나 빠르게 대처하지 못하는 경우가 많다. 그러나 갈등 문제는 무조건 빨리 해결하는 것이 답이다. 시간을 오래 끌수록 곪을 뿐이다.
오늘은 두 개의 사례만 다루었지만, 사실 스타트업을 재직하는 동안 갈등이 참 많았다. 오히려 큰 회사를 다닐 때보다도 갈등이 수면 위로 올라오기 더 적절한 환경이었던 것도 같다. 하지만 돌이켜보면 갈등을 일으킨 그들의 대부분은 악의를 가지고 있었던 건 아니었다. 그저 우리 팀, 혹은 PO인 나와 입장이 달랐을 뿐이다. 직장 생활에서 이 정도의 잡음과 정치질(?)은 당연한 것이라고 생각하기도 한다.
이러한 부서 이기주의를 해결하는 가장 쉬운 방법은 다른 회사도 아닌 스타트업에, '굳이' 우리 모두가 모였다는 점을 자각하는 것이 아닐까 한다. 우리는 한 크루, 한 동료라는 점을 기억하고 특정 팀이나 누군가를 주적이라며 배척하거나 견제하는 불필요한 감정 소모를 줄일 수 있을 것이다.
지는 게 이기는 것이라는 말을 어릴 때부터 귀 아프도록 듣고 살았는데, 이제야 그 말의 속뜻이 이해된다. 그냥 져주라는 것이 아니고, 애초에 싸움 자체가 큰 의미 없다는 말이 아닐까? 확실히 회사에서의 싸움은 득보다 실이 맞으니 말이다. 다음 조직에서는 이 말을 좀 더 실천에 옮기는 사람이 되어야겠다(제발).
