메이커에게 중요한 일을 맡기려면, 중요한 일을 할 수 있는 환경을 만들어줘야 합니다

설레임이 붕괴되는 순간

스타트업에서 일을 하다 보면 “세상을 바꾸자”는 말은 매우 설레는 말입니다.

우리가 스타트업에서 일하는 이유는 다양하겠지만, 가장 중요한 것은 나와 제품과 회사의 성장을 통해 만들어낼 임팩트(Impact)가 아닐까 생각합니다. 그래서 리더십(Leadership)이 가진 미션과 비전, 그리고 그것을 달성하기 위해 우리가 해야 할 액션아이템(Action Item)들을 들으면 그 순간 벅차오름이 느껴집니다.

물론 그 설레임이 현실적으로 계속 가기는 어렵습니다. 저 역시 주니어 때는 거의 설레임 중독자로, 새로운 설레임과 더 큰 임팩트를 찾아다녔으니까요. 하지만 가장 경계해야 할 점은 설레임이 사라지는 것이 아니라, 붕괴되어 현타로 다가오는 순간입니다.

KTLO(Keep The Lights On)성 업무에 파묻혀 매일 야근하며 열심히 일했는데, 돌아보면 “내가 뭘 했지?” 싶은 순간. 그때가 가장 큰 현타가 오는 순간이 아닐까 합니다.

사람은 이정표가 필요합니다

우리는 네비를 찍고 가면서도 중간중간 제대로 가고 있는지 확인하죠. 리더십이 구성원을 평가할 때도 결국 이 사람이 무슨 프로젝트를 했나를 주요 이정표로 활용합니다.

저는 대기업부터 중견기업, 스타트업부터 빅테크까지 여러 회사를 경험했고, 다양한 동료들과 협업했습니다. 그 과정에서 제가 찾은 원칙은, 동기부여에 필요한 건 멋진 말이 아니라 언행일치라는 것입니다.

중요한 사람이라면, 중요한 일을 할 기회를 충분히 줘야 합니다. 가장 노동집약적인 IT 산업에서(언젠가는 AI에 의해 자본 혹은 토큰 집약적인 산업으로 바뀔 것 같지만), 한 명 한 명의 영향력이 큰 스타트업에서는 더욱 그렇다고 생각합니다.

KTLO를 한 줄로 세웁니다

가장 단순하면서도 효과가 좋았던 방법은 KTLO를 한 줄로 세우는 것입니다.

1. 메이커(Maker)가 그때그때 태그되어 “이거 해주세요”를 받지 않도록, 요건은 정해진 창구로 받습니다.
2. 요건이 접수되면 PO가 중요도를 먼저 판단합니다. 중요도를 판단하는 프레임워크(Framework)는 많으니, 가장 적절한 것을 선택하면 됩니다. 그리고 구성원의 업무 히스토리, 성향, 지금 진행 중인 업무 등을 고려해서 할당합니다. 특히 KTLO는 구성원 리소스(Resource)의 최대 20% 수준에서 관리하며, 플래닝(Planning) 때 버퍼(Buffer)로 미리 잡아둡니다.
3. 나머지 80%는 OKR 달성을 위한 일에만 사용합니다.
4. 단, 진짜 중요한 요건이 너무 많아지면 메이커에게 “알아서 챙겨주세요” 하지 않고 PO가 여유를 만들어야 합니다.

아래는 토스뱅크에서 이걸 실제로 어떻게 운영했는지에 대한 이야기입니다.

토스뱅크에서: 창구 만들기

토스뱅크에서는 요청사항을 접수할 수 있는 채널과 워크플로우(Workflow)를 슬랙에 만들었습니다. 그리고 메이커 직접 태그를 지양한다는 원칙을 세웠습니다. 물론 개발자분들끼리 서로 태그해서 논의하는 것은 예외였습니다.

원칙만 세운다고 바로 지켜지지는 않습니다. 그래서 이 과정을 안착시키기 위해, 초기에는 이렇게까지 했습니다. 우리 팀 개발자가 태그당하면 제가 알림을 받게끔 오토메이션(Automation)을 설정했고, 요건이 개발자분에게 직접 전달되면 쓰레드에 나타나서 요건은 저를 태그해 달라고 부탁드렸습니다.

물론 이건 굉장히 부담될 수 있는 방식입니다. 그래서 구성원들께 미리 공유하고, 안착될 때까지 단기적으로만 그렇게 했습니다.

토스뱅크에서: 여유 만들어 오기

요건이 전부 진짜 해야 하는 일일 때도 있습니다. 그럴 때 PO가 할 수 있는 건 여러 가지입니다. 일정을 조정하든지, 리소스를 조정하든지, “이번에는 빡세게 하자, 그 대신 끝나고 쉬자” 하고 구성원의 동의를 구하든지. 가능한 방법을 찾습니다.

토스뱅크에서 서민금융으로 선순환을 만들기 위해 햇살론뱅크를 론칭하자고 했을 때, 스쿼드에 조인해주신 메이커분들이 기존에 하시던 정기적인 업무들이 있었습니다. 토스뱅크는 사람이 부족했기에 한 분 한 분이 많은 업무를 가지고 계셨습니다. 하지만 햇살론뱅크의 한도는 계속 줄어들고 있었고, 우리가 목표를 달성하기 위해서는 빠르게 출시해야 했습니다. 그래서 저희 팀은 2달 내에 개발을 완료하는 것으로 일정을 얼라인(Align)했습니다. 정말 말도 안 되는 촉박한 일정이었습니다. 하지만 저희는 선순환을 진짜로 만들고 싶었습니다. 그래서 기존에 하던 업무들은 “알아서 잘 챙겨주세요” 대신, 크런치 모드(Crunch Mode)로 일해야 하는 시점에는 다른 PO분들을 만나 당분간만 저희 메이커분들이 하고 계시던 업무를 가져가 달라고 부탁드렸습니다. 다른 스쿼드(Squad)의 도움을 받아 집중할 수 있는 환경을 만든 거죠.

무엇이 좋아지나

단기적으로는 컨텍스트 스위칭(Context Switching) 비용이 줄어듭니다.

아시다시피 메이커가 작업을 중단했다가 다시 시작하면 예상보다 큰 비용이 발생합니다. 개발자분들이 한 번 개발을 시작하면 새벽까지 쭉 작업하는 것도 그래서입니다. 밤에 일하는 게 좋아서가 아니라(물론 그런 분도 있습니다), 중단했다가 다시 시작하면 이전에 작업했던 것들을 다시 학습하는 비용을 또 지불해야 하기 때문입니다. 그 비효율을 다시 겪고 싶지 않은 것이죠.

중장기적으로는 “나는 중요한 일을 할 기회를 받고 있다”는 걸 메이커가 느낄 수 있습니다. 말이 아니라 일의 배분으로 보여주는 겁니다.

이후에 제가 어떤 제안을 하면, 메이커분들이 제 이야기에 더 귀 기울여 주셨습니다. 존중에 기반한 신뢰를 빠르게 얻을 수 있는 방법인 거죠.

당연한데, 잘 안 되는 것

어떻게 보면 당연한 이야기입니다. 그런데 PO/PM/서비스기획자로 일하다 보면 내 코가 석 자라 이걸 놓치곤 합니다. 당장 급하니까 그냥 태그해서 “확인해 주세요” 합니다. 하지만 그게 쌓이면 메이커와 점점 벽이 생기고 멀어지게 됩니다.

저도 그런 경험을 했고, 메이커분들과 갈등을 만든 적도 있습니다. 우아한형제들에 다닐 때는 “성재님은 왜 항상 라이더 편만 드세요?“라는 강한 피드백을 받은 적도 있습니다. 그래서 제 나름대로 프레임워크를 만들었습니다.

가장 고리타분한 것이 가장 빠릅니다

톰 소여는 울타리 칠을 친구들이 서로 하겠다고 나서게 만들었죠. 일을 스스로 하게 만드는 방법은 여러 가지지만, 가장 고리타분해 보이는 존중과 신뢰가 생각보다 가장 빠른 길이라고 생각합니다.

빠름의 정의를 어떻게 내리느냐에 따라 다르겠지만, 제품팀은 한 번의 이터레이션(Iteration)으로 목표를 달성할 수 없죠. 여러 번의 이터레이션을 돌려야 하고, 목표에 도달하기까지의 시간을 고려하면 결국 이게 가장 빠른 길이었습니다.

최근에 PO로서의 탁월함에 대해 쓴 글에 나온 필리아(Philia)도 이 글과 일맥상통합니다.

여러분은 어떻게 생각하세요? 여러분의 팀에서는 메이커가 중요한 일에 집중할 수 있도록 어떤 환경을 만들고 계신가요?