잘 굴러가는 팀으로 일하기

프로덕트 디자이너의 짧은 회고록

 이 글에서는 사업 조직(팀, 스쿼드 등)이 효율적으로 작동하려면 구성원으로서 무엇을 어떻게 하면 좋을지, 피해야할 것들은 무엇이 있는지 회고를 통한 개인적인 takeaway를 공유하고자 합니다. 무엇보다 중요한 건, 절대적으로 옳은 방식이란 없으며 각기 다른 구성원으로 이루어진 하나의 팀은 유기체로서 끊임없이 변화하고 계속 진화한다는 것입니다.

---

대부분의 조직에서 사람들은 성취한 성과를 집단의 구성원으로서 평가받습니다. 대부분 개인이 단독으로 수행할 수 있는 범위 이상의 업무를 진행하기 때문입니다. 그래서 우리는 집단이라는 맥락을 벗어날 수 없고 끊임없이 소통하며 상호작용 해야합니다. 이게 잘 되는 팀이 흔히 '잘 굴러가는 팀'이 되는 것이겠지요.

그렇다면 '잘 굴러가는 팀'이 되기 위해 우리가 늘 유념해야 할 것들은 무엇일까요?

---

명확한 가이드가 없는 자율성은 자율성이 아니다

체계과 프로세스 구축의 필요성

 제가 속해있던 팀은 그야말로 자율성을 '뿌리는' 팀이었습니다. 주도적이라는 명목 하에 어떤 일을 하든 제재가 없었고 특별한 지시사항도 없었지요. 저에게 주어진 지시사항은 단 하나였습니다. '파트 간 잘 협업해서 UX를 개선해보아라'. 덕분에 저는 제 입맛대로 업무를 진행할 수 있었고 일정에 쫓기지 않고 유동적으로 작업을 해나갈 수 있었습니다. 처음에는 주도적으로 무슨 일이든 할 수 있을 것만 같았습니다. 이렇게 자유롭게 일을 진행한다면 아쉬울 게 없겠다는 기대감도 가지게 되었어요. 하지만 이게 정말 맞는 방향인지에 대한 의구심이 끊임없이 들었습니다. 이 태스크가 정말로 지금 필요한 과제인지, 비즈니스 방향성에는 부합하는 것인지 명확하지 않은 채로 일을 진행하고 있었던 탓입니다. 기획을 들고가서 피드백을 요구해도 '없다'는 답만 돌아왔어요. 유일한 피드백은 '일단 그대로 진행하라'는 것이었습니다. 그렇게 진행하고 나면 늘 개발을 앞두고 제 기획은 뒷전이 되어버리곤 했습니다. 당장 다른 운영 개발이 시급하다는 이유에서요. 돌이켜보면 저는 너무나도 쉽게 앞으로 나아갔고 너무나도 쉽게 길을 잃었습니다. 그것은 사실 자율성을 가장한 방임과 방치에 가까웠던 것이었습니다.

 이러한 경험을 통해 저는 아래 3가지를 깨달았습니다.

파트 간 협업이 어떻게 이루어져야 하는지에 대해 공동으로 공유되는 프로세스가 있어야한다.

구성원에게 자율성만을 부여하는 것은 파트 간 업무 프로세스와 속도의 파편화를 초래할 수 있다.

기존의 waterfall 방식이 주는 명시적인 프로세스가 필요할 때가 있다. 이는 우선순위를 조율하는 기준이 되기도 한다.

따라서 기존의 관료적인 waterfall 방식처럼 비즈니스 방향성이 명시된 상태에서 팀(스쿼드) 내에서의 업무 분배가 고려되어야 합니다. 사업 방향성이 헤드나 팀 리더급에서 정해지면 이를 실무 구성원들이 주도적으로 진행할 수 있도록 전사적으로 공유하고 Role-driven과 Rank-driven 방식이 병행되어 의사결정이 이루어져야 한다는 것이지요.

---

Role-driven(역할 기반)과 Rank-driven(위계 기반)

이분법적 구분이 아닌 병행

 스타트업이 아닌 대부분의 기업들은 탑다운, 워터폴과 같은 Rank-driven 방식이 탄탄하게 잡혀있는 경우가 많습니다. 위에서는 '명확한 지시'를 내리고 아래에서는 '빠르게 수행'하는 식으로요. 하지만 때로는 '명확한 지시'는 내리지 못한 채 뚜렷한 방향성 없이 '아이디어는 바텀업'으로 제시하길 원한다는 패착이 있는 것 같습니다.

  제가 일했던 회사는 기본적으로 Rank-driven이 자리잡은지 오래된 곳이었습니다. 그리고 자율성 보장이라는 명목 하에 '일단 아이디어 좀 내봐'라는 식으로 굴러가곤 했던 것이지요. 위에서도 언급했듯 이 자율성은 곧 또다른 장애물이었습니다. '자율성 보장'이 언제나 Role-driven은 아니라는 뜻입니다. 그것은 그저 때때로 non-waterfall이었던 것이지요.

 Role-driven은 각각의 구성원, 실무자들이 모두 책임감을 가지고 각각의 프로젝트를 운영하는 형태입니다. 그러려면 내부적으로 충분한 시간을 들여 최선의 솔루션을 도출할 수 있어야하고 구성원들 사이의 소통이 원활하고 고민이나 의견을 충분히 표현할 수 있어야합니다.

 이때 중요한 것은 흔히 집단 활동에서 발생하는 사회적 태만(링겔만 효과)을 경계해야 한다는 점입니다. 그러려면 팀 구성원이 너무 많아서도 안되고 공통의 목표를 가지되 모두가 공감할 수 있는 목표여야 하는 것이지요.

---

 회사는 동아리도 군대도 아니기 때문에 막연히 구성원들을 풀어두어서도 안되고 역할 기반과 위계 기반 둘 중 어느 한 가지만 채택할 필요도 없으며 그래서도 안됩니다. 때로는 진행되는 프로젝트에 따라 워터폴로 지시 사항이 내려오거나 어떤 태스크들은 바텀업으로 진행되기도 할 것입니다. 그리고 위에서는 구체적인 업무지시를 내리고 아래에서는 지시에 대해 신뢰를 가지고 업무를 빠르게 진행하는 Rank-driven과, 프로젝트가 진행되는 배경과 현황을 명확하게 공유하고 실무자는 충분한 고려를 통해 솔루션을 도출하는 Role-driven이 함께 운용되어야 팀이 효과적이고 효율적으로 돌아갈 수 있을 것입니다.

누구든 뻔히 알고 있는 이야기지만 이렇게 시간을 들여 회고하지 않으면 언제나 쉽게 잊혀지는 것들입니다. 하나의 프로덕트를 디자인하고 구성원들과 함께 같은 방향으로 나아가려면 늘 염두에 두어야하는 것들이고요. 이번 브런치를 통해 또다시 머릿속에 담금질을 합니다. 읽어주셔서 감사합니다.