회사를 다녀본 분이라면 한 번쯤은 이런 경험이 있을 겁니다.

어느 날 위에서 새 매뉴얼이 내려옵니다.

 

“앞으로 모든 업무는 이 양식대로 진행할 것.”

양식을 받아 들고 한 번 훑어보는데, 황당해집니다.

양식의 칸을 채우려면 평소엔 하지 않던 일을 일부러 해야 하고,

정작 매일 부딪히는 진짜 문제는 양식 어디에도 적을 자리가 없습니다.

그 순간 아래와 같은 생각이 듭니다.

‘이거 만든 사람이 우리가 무슨 일을 하는지 알기는 할까?’

이런 질문이 한 번 나오기 시작하면, 그 시스템은 끝난 겁니다.

사람들은 양식을 채우는 시늉만 하고, 실제 일은 자기 방식대로 합니다.

매뉴얼은 회의에서만 언급될 뿐,

책상 위에서는 아무도 들춰보지 않는 종이가 됩니다.

애써 시스템을 만든 이유가 사라지는 거죠.

저도 이런 장면을 자주 봤습니다.

스타트업에서 실무자로 일할 때도,

대학 다닐 때 경영컨설팅 학회에서 실제 기업 프로젝트를 진행할 때도 마찬가지였어요.

책상에서 정리한 분석은 깔끔한데,

막상 실무자가 받아 보면 적용하기 어려운 지점이 많았거든요.

만드는 것보다 어려운 건, 만든 다음입니다

저희 회사도 1년쯤 전에 헤드쿼터라는 조직을 따로 만들었습니다.

시스템만 고민하는 본사 조직입니다.

 

실무 팀은 매뉴얼대로 안정적으로 굴러가면서 자기 크리에이터의 상한선을 뚫는 데에만 집중하고,

헤드쿼터는 그 운영이 누가 하든 같은 퀄리티로 굴러가도록 시스템을 설계합니다.

만들고 나서 정말 신경 썼던 건 헤드쿼터를 만든다는 결정 자체가 아니었습니다.
 

만들어진 시스템이 실무팀의 신뢰를 어떻게 얻을 것인가.

이게 진짜 어려운 문제였어요.

제가 경험했던 사례들처럼 실패하지 않으려면 결국 신뢰 구조가 뼈대가 되어야 했습니다.

다행히 지금 저희 헤드쿼터는 1년 가까이 큰 잡음 없이 굴러가고 있습니다.

주변에서 "부작용은 없냐"는 질문을 자주 받는데,

그때마다 세 가지 장치 덕분이라고 답합니다.

헤드쿼터가 망하지 않는 세 가지 장치

첫째, 헤드쿼터는 외주가 아닙니다.

외부 컨설팅을 받아본 분이라면 익숙한 그림일 겁니다.

컨설턴트가 매뉴얼을 인도하고 떠난 다음,

그게 실제로 잘 굴러가는지 매일 확인하고 책임지는 건 클라이언트의 몫이 됩니다.

컨설턴트는 다음 프로젝트로 갔으니까요.

헤드쿼터는 그 자리에 남아 있습니다.

회사 안에 영구적으로 자리 잡은 부서고,

시스템이 잘 굴러가지 않으면, 헤드쿼터 인원들은 그 결과를 매일 마주해야 합니다.

지금 헤드쿼터의 메인 인선도 모두 회사에 깊이 묶여 있는 분들입니다.

부대표님은 회사를 시작할 때부터 가장 가까이에서 함께 일해 왔고,

지금은 실무팀 전체를 이끌고 있습니다.

헤드쿼터에 있는 한 팀장도 바로 전까지 광고커머스팀의 팀장이었던 분입니다.

물론 현장 출신만 헤드쿼터에 둘 수 있다는 뜻은 아닙니다.

핵심은 출신이 아니라, 시스템의 장기적인 결과를 끝까지 책임지는 자리에 있는가입니다.

둘째, 헤드쿼터가 일방적으로 시스템을 바꾸지 않습니다.

헤드쿼터의 매뉴얼은 책상에서 한 번에 짜서 떨어뜨리는 식으로 만들지 않습니다.

실무진의 니즈에서 출발해 자라나도록 만듭니다.

실무진이 "이 부분이 불편하다, 이런 게 있으면 좋겠다"고 요청을 올리면,

헤드쿼터가 그걸 받아서 실무 리드들과 인터뷰를 진행합니다.

정확히 무엇이 필요한지, 왜 필요한지, 언제까지 필요한지,

만약 개선되면 어떤 변화가 있을지를 꼼꼼히 들어봅니다.

그 인터뷰를 토대로 만든 개선안을 매주 실무 팀장·리드급들과 얼라인 미팅에서 다시 맞춰 봅니다.

일정이 밀린 건 없는지,

개선하다가 새로 튀어나온 이슈는 없는지,

막상 적용해 보니 어색한 부분은 없는지.

한 주에 한 번씩 같이 들여다 봅니다.

이렇게 굴러가다 보면 매뉴얼은 헤드쿼터가 맘대로 만든 게 아니라 실무팀이 함께 만든 게 됩니다.

실무팀이 안 지킬 이유가 없는 거죠.

셋째, 헤드쿼터의 매뉴얼은 권고가 아니라, 모두가 지켜야 할 의무입니다.

외부 컨설팅으로 좋은 제안이 나와도 회사 안에서 다시 검토를 받고,

누군가가 채택하기로 결정하고, 실무진에게 전파되는 단계를 거쳐야 적용됩니다.

그 사이에 다른 우선순위에 밀리는 일이 흔하고,

결국 적용되지 못한 채 잊히는 권고도 많습니다.

헤드쿼터가 만드는 매뉴얼은 다릅니다.

회사 안에 정식 부서로 자리 잡은 곳에서 나오는 매뉴얼이라, 바로 적용해야할 의무가 됩니다.

다만 이 방식이 매끄럽게 작동하려면

위에서 정한 매뉴얼을 긍정적으로 받아들이는 문화

가 형성되어 있어야 합니다.

저희의 경우 두 가지 조건이 같이 맞아떨어졌어요.

하나는 저희가 이미 위에서 정한 방식대로 일하는 데 익숙한 조직이었다는 점입니다.

자기 방식대로 일하는 것보다 위에서 정한 매뉴얼 안에서 움직이는 쪽이

더 좋은 성과가 나온다는 경험을

저희는 헤드쿼터 조직을 정식으로 만들기 전부터 1년 이상 경험해왔었습니다.

다른 하나는 타이밍이 맞았다는 점입니다.

헤드쿼터가 없었을 때 실무진들은 실무와 시스템 설계 두 가지를 다 짊어지고 있었어요.

헤드쿼터가 그 중 시스템 설계 부담을 가져가 주는 모양새가 되니,

헤드쿼터의 신설은 실무진의 환영을 받았습니다.

*헤드쿼터 조직 신설 이전의 골든웨일즈의 자세한 상황이 궁금하신 분들은, 이전 글 "둘 다 잘하는 사람을 찾으려다, 승진할 사람이 없어졌다"를 참고해주세요.

세 장치의 핵심

세 장치는 하나의 공통된 방향성을 가지고 있습니다.

시스템이 발전하는 게 모두의 이익으로 돌아가는 구조를 만드는 일이요.

헤드쿼터가 결과를 매일 마주하고,

실무진이 기획에 함께 참여하고,

정해진 시스템은 모두가 지켜야 할 의무가 되는 것.

셋 모두 결국 그 한 가지 효과를 위한 장치들이었어요.

저는 이 방향을 보상구조까지 적용했습니다.

골든웨일즈는 분기 평가에서 초과 기여자에게 두 갈래로 인센티브를 지급합니다.

매출 같은 단기 성과는 임팩트 트랙,

회사 시스템을 한 단계 끌어올린 기여는 시스템 트랙.

핵심은 시스템 트랙이 헤드쿼터 전용이 아니라는 점입니다.

실무진도 자기가 낸 개선 의견이

회사 전반의 매출이나 효율을 측정 가능하게 끌어올리면

시스템 트랙 인센티브를 받습니다.

시스템이 살아 있게 하는 건 매뉴얼이 아닙니다

헤드쿼터든 전략기획팀이든,

시스템을 따로 설계하는 조직을 두려는 시도는 대부분 같은 자리에서 멈춥니다.

좋은 매뉴얼은 나오는데,

실무자에게 외면받고, 결국 형식만 남게 됩니다.

골든웨일즈가 거기서 멈추지 않을 수 있있던 비결을 한 줄로 정리하면 이렇습니다.

시스템이 발전하는 게 모두의 이익으로 돌아가는 구조를 만드는 것.

운영 인프라란 결국 이 구조를 짜는 일입니다.

매뉴얼을 잘 쓰는 건 그 다음이고,

동료 의식이나 신뢰는 그 위에서 자연스럽게 자라나는 결과예요.

양식의 칸을 채우다가

'이거 만든 사람, 우리가 무슨 일을 하는지 알기는 할까?'라고 의심이 들지 않는 회사.

저희가 지금도 열심히 만들어 나가고 있는 건 그런 회사입니다.