brunch

브런치북 눈 떠보니 스타트업 매니저 05화

라이킷 19 댓글 1

You can make anything
by writing

C.S.Lewis

계정을 잊어버리셨나요?

by 데이빗beta Oct 18. 2021

자유가 아닌 자율성을 주려면

자율성의 양면성

3주짜리 짧고 굵은 대기업 프로젝트를 리드한 적이 있다. 그런데 클라이언트는 3주가 너무 짧다고 생각했는지 첫 미팅에서 프로젝트 기간을 며칠 더 늘려달라고 부탁했다. 3주에서 며칠은 꽤 큰 비중이었다.

당시 우리 회사 대표님은 미국에 계셨기에 내가 대답할 수 있는 문제인지 고민이 되었다. 하지만 당황하면서 대표님한테 물어봐야 한다고 말하면 내가 전문 컨설턴트가 아닌 허수아비처럼 보일 것 같았다. 그리고 이 대기업 부서와는 처음 프로젝트를 해보는 것이기에 돈을 조금 더 아끼거나 버는 것보다 우선 신뢰를 얻는 것이 중요하다고 생각했다. 이 프로젝트에서 신뢰를 얻으면 추후에 더 큰 프로젝트가 들어올 가능성이 있기 때문이다. 클라이언트가 기간을 늘리자는 이유도 합리적이었다.

나는 과감하게 그 자리에서 클라이언트의 요청을 수락했다. 이 모든 판단을 그 자리에서 내가 내렸다.

이렇게 할 수 있었던 이유는 여러 가지가 있다. 우선 내가 회사 돌아가는 시스템을 잘 알고 있었다. 현재 상황에서는 프로젝트 기간을 늘려도 크게 문제가 되지 않을 것을 알고 있었다. 회사 정보가 투명하게 공유되고 있었기에 다음에 어떤 프로젝트가 있고 누가 무엇을 하는지 다 알고 있었다.

그리고 즉석에서 결정해도 대표님은 나의 결정을 존중해주실 것이라는 믿음과 신뢰가 있었다. 기간보다 프로젝트를 성공적으로 끝내는게 더 중요했다.

다시 말해 정보의 투명한 공유 덕분에 정확히 상황을 판단할 수 있었고, 신뢰가 있었기에 즉석에서 결정을 내릴 수 있었다. 감사하게도 나에겐 이만큼의 자율성이 주어졌었다.

그 결정 덕분에 클라이언트도 내가 그만큼의 의사결정권이 있다는 것을 알게 되었고, 나를 더 신뢰하는 계기가 되었던 것 같다. 프로젝트는 성공적으로 끝났고 서로 만족할만한 결과를 냈다. 프로젝트가 끝난 후에도 그 부서는 지속적으로 우리에게 프로젝트 의뢰를 했으며, 우리를 다른 부서에도 추천해주기도 했다.

이렇듯 자율성이 있으면 더 순발력 있게 창의적으로 생각할 수 있으며 결국 그 열매는 회사에 돌아간다. 실제로 자율성이 직원의 생산성과 만족도를 높인다는 연구 결과도 많다.

그렇다고 자율성이 무조건 좋은 것은 또 아니다. 회사가 직원에게 무한한 자율성을 주는게 좋지 않을 수 있다는 것도 경험했다.

IT 업계에선 조직문화에 관해 유명한 Jeremiah Lee의 'Spotify의 스쿼드 모델은 실패했다.'라는 글이 있다. (스쿼드: 제품 매니저, 디자이너, 엔지니어 등의 다기능 직군이 모여있는 의도적으로 작은 목적 조직) 당시 너도 나도 유명한 스쿼드 형태의 조직을 도입했다가 낭패를 보는 경우가 적잖이 있었다. 우리도 그중에 하나였다. Jeremiah가 지적한 내용 중 일부를 그대로 겪었다.

가장 큰 문제는 너무 많은 자율성에 있었다. 서로 협업하는 방식이 정해지지 않은 채로 모든 것을 자율에 맡기다 보니 오히려 혼란만 가중되었다. 해야할 일의 범위가 명확하지 않아 결정할 사안이 너무 많았고, 결과적으로 누구도 결정을 할 수 없게 되는 아이러니한 상황이 되었다.

누가 어떤 권한이 있으며, 커뮤니케이션을 어떤 식으로 해야 하는지에 대한 규칙 없이 무한의 자율성을 주자 자율성이 제대로 동작하지 않았다. 오히려 이 자율성을 통제하려는 규칙이 생겨야만 했다. 이것은 문제를 더 복잡하게 만들었다.

그래서 Basecamp라는 스타트업은 스쿼드의 단점을 보완하는 모델을 만들었고, Shape Up이라는 문서로 공유되고 있다. 핵심은 자율성을 주지 말자가 아니라 자율성의 적정선을 찾는 것에 있는데, 각 팀이 해결할 수 있으면서도 충분히 도전적인 문제를 리더십에서 미리 논의하고 분배한다. 이렇게 하면 팀 간 불필요한 커뮤니케이션이 줄어들고 해당 문제에만 집중할 수 있게 된다.

정답이 아닌 플랜 B

대학원 때 안 되는 연구를 계속 붙잡고 일 년 동안이나 있었다. 결과는 당연히 좋지 않았다. 만약에 그때 누군가 방향을 틀어 주었으면 어떨까.

내가 못하는 것을 붙들고 있는 것이 아니라 잘하는 것을 해볼 수 있도록 방향을 다시 설정해주었으면 어땠을까. 왜 처음 시작한 것을 끝까지 완성해야 한다고 생각했을까.

인생엔 플랜 B도 있어야 한다. 그런데 경험이 없는 사람은 스스로 플랜 B를 만들지 못할 수도 있다. 어떤 대안이 있는지 모르기 때문이다. 그래서 리더의 도움이 필요하다.

어떤 매니저는 이미 답을 가지고 있고 팀원은 그것을 이뤄내기 위한 수단으로 생각하는 경우가 있다. 그 정답에 따라 팀원을 평가한다.

이렇게 하면 의도하지 않더라도 권력이 매니저 자신에게 집중된다. 매니저가 평가 권한을 가지고 있으면서도 본인이 원하는 바가 있기 때문이다. 팀원으로써는 따라야 할 수밖에 없는 상황이다. 이런 환경에서 팀원은 자율성을 가지고 창의적으로 일하지 못한다.

내가 팀원일 때, 디자이너인 내가 과감하게도 매니저에게 웹사이트 개발을 해보겠다고 했다. 그 매니저는 내가 하고 싶은 것을 할 수 있게 허락해주고 지원해주었다.

하지만 상황이 그렇게 잘 흘러가진 않았다. 나는 능숙한 개발자보다 개발 속도가 훨씬 느렸기 때문이다. 프로젝트 도중 내가 매니저에게 마감일을 못 맞출 것 같다고 했을 때, 매니저는 그 상황을 계속 파악하고 있다가 돌이킬 수 없는 마지막 타이밍에 전문가를 고용하여 제시간에 일을 마무리했다.

매니저는 나에게 자율성을 주면서도 플랜 B를 준비하고 있었다. 정말 감사했다.

이때의 경험을 교훈으로 삼아 내가 프로젝트를 리드할 때 비슷한 상황을 무사히 넘길 수 있었다. 우리는 최종 발표를 위해 스토리보드 그림을 그려야 하는 작업이 남아 있었다. 같이 일하던 동료는 전문 일러스트레이터는 아니었지만 본인이 그림 실력도 늘릴 겸 해보고 싶다고 했다. 나는 당연히 해보라고 했다.

하지만 마감일이 다 되어가는데 동료는 그림을 제시간에 끝내지 못한 상황이었다. 때는 금요일 오후였고, 차주 초까지 마무리를 해야 하는 상황이었다. 그때 나는 전화를 돌려 그 일을 잘할 수 있는 프리랜서를 구했고, 그 일러스트레이터는 요청하지도 않은 주말에 그림을 다 그려주셨다.

내가 일러스트레이터 분을 미리 구해놓은 것은 아니었지만 (그것 또한 시간 낭비라고 생각했다.), 동료가 익숙하지 않은 일을 할 때 실패할 수도 있다는 생각을 미리 하고 있었기에 그 상황이 그렇게 당황스럽지는 않았다. 프로젝트는 다행히 성공적으로 끝났다.

위임

사이드 프로젝트할 때 다른 회사와 협업한 적이 있다. 내가 웹사이트의 한 페이지를 만들기로 했고, 상대방이 궁금할까봐 완성되지 않은 중간 과정을 공유했다. 그런데 대뜸 그 회사 사람 중 가장 높은 사람이 엄청나게 디테일한 피드백을 보내왔다.

나와 만나본 적도 없는 서로 모르는 사이인데 정말 예의라고는 하나도 없이 이게 왜 잘못되었고 이렇게 고쳐야 한다느니 하는 말을 했다. 안면식도 없는 나에게 자신이 하고 싶은 말을 편하게 다 했다.

나는 단지 잘 진행하고 있다는 차원에서 안심시키려고 보낸 것이지 그런 구체적인 피드백을 요청한게 아니었다. 중간 산출물이기에 아직 개선점이 많다는 것은 내가 더 잘 알고 있었다.

돈 받고 하는 일도 아니었는데 그나마 남아있는 의지까지 꺾였다. 그 사람의 배려 없는 행동 때문에 열심히 하려던 일도 하기가 싫어졌다.

그런 일을 겪어서인지 나는 당사자가 요청하지 않는 이상 가능하면 피드백을 주지 않는 편이다. 다른 글에서 다루겠지만 대신 누구나 자연스럽게 피드백을 요청할 수 있는 분위기와 환경을 만들었다. 마이크로 매니지가 사기를 꺾을 수 있기에 의도적으로 최대한의 자율성을 주는 방법을 택했다.

맡겼으면 완전히 믿어야 하고, 믿지 못할 것이면 일을 애초에 주지 않거나 그 사람이 감당할 만큼 떼어 주는게 좋다고 생각한다. 만약 결과물이 좋지 못하더라도 책임은 내가 진다.

자율성을 주었을 때 두 종류의 사람이 있다. 자신의 일을 스스로 계획하며 정말 날개를 다는 사람이 있다. 누가 알려주지 않아도 스스로 할 일을 정하고 그에 맞춰 열심히 일한다. 이런 사람은 매니저가 관여를 거의 하지 않아도 되어, 매니저는 회사 일이나 다른 동료를 돕는데 시간을 더 활용할 수 있다. 나도 내 매니저에게 그런 사람이 되기 위해 노력한다.

반면에 그렇지 않은 사람도 있다. 이게 나쁜 것은 전혀 아니다. 전 메일침프(Mailchimp)의 매니저였던 Aarron Walter에 따르면 사람은 둘로 나뉘는데, 농부(farmer)와 사냥꾼(hunter) 타입이 있다고 한다.

어느 한 타입이 더 나은 것이 아니라 서로 다른 성향을 가진 사람들이다. 농부는 제한사항이 있음에 감사하고 현재 제품을 최상의 상태로 개선하는데 탁월한 사람이다. 사냥꾼은 더 많은 자유와 시도를 원하며 완전히 새로운 일을 해내는데 탁월한 사람이다. 사람의 성향에 따라 어느 정도의 자율성을 주어야 하는가도 결정될 필요가 있다.

자율성은 채용관과도 연결되어 있는데, 회사에 짧은 경력의 사람들만 너무 많다면 그들에게 회사가 원하는 만큼의 자율성을 충분히 부여하지 못할 것이다. 부여할 수 있는 자율성의 범위가 너무 좁아진다. 그러면 탑다운 명령이나 마이크로 매니지 경영을 해야 하고, 당사자는 사기가 떨어지는 악순환이 반복된다.

예전에 같이 일했던 경력이 많지 않은 동료는 나와 같이 일하면서 나에게 배울 기회가 없었다고 말했다. 그래서 무조건 많은 자율성을 주어야 한다는 일관된 태도를 가지고 있던 내가 틀렸음을 최근에야 깨달았다. 매니저는 개개인의 특성을 파악하고 각 사람에게 맞는 자율성을 주어야 한다.

최종 결정권

내가 피드백을 주더라도 최종 결정권은 당사자에게 있다고 생각한다. 내가 맞다고 생각해도 끝까지 내 의견을 관철시키지 않는다. 두세 번까지는 내 의견을 얘기하지만 당사자가 계속 반대하면 논쟁의 여지가 여전히 남아 있더라도 그 사람의 의견을 일단 존중한다.

내 의견을 끝까지 주장하면 의도하지 않게 나의 '지위'를 사용하는 것이고, 상대방에게 무력감을 줄 수 있다. 이런 상황이 가끔 발생하면 괜찮겠지만 반복되면 상대방은 무력해진다. (이런 상황 때문에 데이터 기반 의사 결정을 하는게 좋다고들 하지만, 모든 결정을 데이터에 기반하여 할 수는 없다. 이미 가진 지식에 기반하여 논리적으로 빠르게 풀어야 할 문제가 훨씬 더 많다.)

만약 팀 동료가 내린 최종 결정이 실패해도 괜찮다. 그가 실패의 아픔을 느껴도 괜찮다. 그런 환경 속에서 자신의 선택에 대한 결과를 온전히 받아들이는 자율성이 길러진다고 생각한다.

매니저가 할 일은 결과에 대한 책임을 짐으로써 동료가 실패해도 안전한 환경을 만드는 것이다. 어차피 매니저가 모든 것을 알고 다 제어할 수 없다. 그렇게 노력해봐야 되지도 않고 서로 지치기만 한다. 나는 동료에게 자율성을 주되 큰 실수만 하지 않게 막자는 생각을 가지고 있다.

팀은 단기간에 만들어지는 것이 아니라 장기적인 안목으로 봐야 한다. 지속 가능한 문화가 좋은 팀을 만든다. 리더는 의사 결정이 (decision-making) 아니라 팀 동료의 의사 결정을 도와야 (decision-managing) 한다.