https://www.youtube.com/watch?v=zF84IMiSP7I
31:04 ~ 1:03:16
Zapier가 점점 커지면서 내가 느낀 건, 엔지니어, PM, 디자이너가 각자의 영역에 점점 더 집중하게 된다는 거야.
그러면 무슨 일이 벌어지냐면, 디자이너는 하루 종일 사용자 경험에만 집중하고,
엔지니어는 코드 품질, 리팩토링, 납기 일정 이런 걸 생각하고,
PM은 비즈니스 임팩트나 숫자 같은 걸 고민하잖아.
근데 이 셋이 뭔가 공통된 우선순위 판단 기준이 없으면, 점점 “우리 vs 걔네” 식의 사고방식이 생겨.
“왜 디자이너는 이걸 원해?”
“왜 엔지니어는 저걸 하려고 해?”
이런 식으로 말이야.
그래서 우리는 개인이 아니라 팀 단위로 OKR을 설정해.
그게 서로 간의 정렬(alignment)을 만들어주는 장치가 되는 거지.
좋다. 근데 그럼 팀원들이 서로 어떻게 체크인해? 데일리 스탠드업 같은 거 해?
팀마다 조금씩 다르게 해. 사실 Zapier의 멋진 점 중 하나는, 팀들이 프로세스를 실험할 자유가 있다는 거야.
각 팀마다 자율적으로 자기 방식대로 운영하게 두고 있어. 대신 혼란을 막기 위한 장치로 OKR을 도입한 거야.
약간 ‘가이드 레일’ 같은 거네?
응, 맞아. 내가 자주 쓰는 비유가 있는데, 회사 전체에서 일관되게 가져가야 하는 것들은 ‘인터페이스’야.
예를 들어, 두 팀이 서로 협업할 땐, “너랑 나랑 어떤 포맷으로 소통해야 하지?”, “어디까지가 네 책임이고, 어디부터가 내 책임이지?” 이런 걸 서로 명확히 알고 있어야 하거든.
그래서 API가 필요한 거지, 실제 소프트웨어처럼. 두 팀 간에 어떻게 연결되고, 누구 영역인지를 알 수 있게.
디자인 쪽도 마찬가지야. 두 디자인팀 사이에 어떤 부분이 누구 소관인지, 그 **소유 범위(scope)**가 명확해야 해.
그리고 우리가 Jira를 이슈 트래킹이나 프로젝트 관리 도구로 사용하고 있어서, 그걸 통해서도 회사 전체가 어느 정도 일관된 구조로 프로젝트를 운영할 수 있어.
그럼 그걸 통해 각 팀의 진행 상황이나, 잘 되고 있는지 아닌지도 볼 수 있는 거네?
맞아. 이게 관찰 가능성(observability)을 만들어줘.
우리 전체 프로덕트 개발 과정을 다 볼 수 있고,
어디서 우리가 잘하고 있고,
어디서 투자를 너무 많이 하고 있거나, 기술 부채를 무시하고 있거나,
이런 걸 다 파악할 수 있게 돼.
그래서 어떤 부분은 **일관성(consistency)**이 꼭 필요하고,
어떤 부분은 팀에 **자율성(autonomy)**을 주는 거야.
그럼 팀은 어떻게 구성돼? 위에서 정해주는 거야? 아니면 사람들끼리 알아서 드래프트처럼 짜는 거야?
음, 대부분은 조직 리더십 레벨에서 방향성을 먼저 정해.
예를 들어 “이런 새로운 기회를 우리가 잡고 싶어” 또는 “우리 제품의 이 영역은 아직 충분히 커버가 안 되고 있어” 같은 게 나오면,
그에 맞춰서 팀을 신설하고 거기에 사람들을 배정하는 방식이지.
지금은 리크루팅 팀도 꽤 잘 구성되어 있어서,
새로 생긴 팀에 필요한 역할을 빠르게 채워넣을 수 있어.
그럼 한번 팀에 들어가면, 그 팀에서 쭉 일하는 거야? 아니면 팀 간 이동도 있어?
보통은 장기적으로 한 팀에 있는 경우가 많아.
하지만 그렇다고 고정된 건 아니야.
실제로 어떤 사람은 다른 팀에서 필요로 하는 전문성이 있어서 옮기기도 하고,
“나 저 분야에도 관심 있어요” 해서 팀을 바꾸는 경우도 있어.
예를 들어 아주 시니어 엔지니어가 새로운 팀에 투입되기도 하고,
그 팀엔 주니어 엔지니어가 새로 들어오기도 하고.
서로 멘토-멘티 식으로 맞춰서 구성되기도 하지.
OKR은 보통 어느 기간 단위로 세워? 분기? 연간? 월간?
연간이랑 월간, 두 가지를 같이 써.
연간 OKR은 “우리가 1년 동안 뭘 이루고 싶은가?”
즉, 전체적인 방향성과 목표를 설정하는 거고,
월간 체크인은 “지금 이 목표를 향해 잘 가고 있는가?”
“이번 달엔 뭘 해야 하나?” 이런 걸 점검하는 거지.
그럼 평균적인 팀 하나가 OKR을 어떻게 관리하는지, 워크플로우를 좀 설명해줄 수 있어?
음, 이건 아직 우리도 계속 실험 중이야. 😅
올해부터 팀 단위로 OKR을 전사적으로 적용하고 있어서, 아직 배우는 중이거든.
2018년엔 경영진 레벨에서 먼저 OKR을 테스트했어.
두 분기 정도 시도해봤고, 그 결과가 좋아서
“아, 이거 효과 있다. 각 팀에서도 도입하자”라고 결정한 거지.
이제 실제로 조직 전체의 개별 팀들이 OKR을 쓰기 시작했는데,
가장 이상적인 형태는 이거야. 물론 아직 우리가 완벽하게 도달하진 못했지만.
먼저, 조직의 리더십 레벨에서 큰 방향성을 제시해.
“우리는 이런 걸 이루고 싶다” 같은 전략적 비전이지.
예를 들어 Zapier의 경우는,
“누구나 쓸 수 있는 생산성 소프트웨어를 만들자”,
“언젠가 수백만 명이 Zapier를 쓰게 하자” 같은 방향이야.
이런 식으로 큰 방향이 정해지면,
각 팀 레벨에서 “그럼 우리는 뭘 해야 하지?”라는 걸 고민해서
목표를 만들어 나가는 거야.
그래서 우리는 톱다운과 보텀업의 중간쯤 되는 구조를 지향해.
즉, 전체 업무의 50%는 위에서 내려오는 방향이고,
나머지 50%는 각 팀이나 개인이 스스로 판단해서 올리는 거야.
왜냐하면 리더십 팀이 조직 전체에서 일어나는 모든 걸 완벽하게 파악할 수는 없잖아.
그리고 사실 OKR 같은 건 “지금 무슨 일을 하고 있는가”를 정확하게 규정하려는 도구가 아니야.
그보다는 “우선순위를 정하고, 힘든 결정들을 할 때 논의의 기준점이 되는 도구”지.
그리고 Zapier에서 우리가 하는 모든 결정이나 프로세스를 문서화하는 이유도,
그 문서가 있으면, 누군가랑 그걸 가지고 논의할 수 있잖아?
“이게 맞는 방향일까?” 하고 누군가랑 토론할 때, 그냥 추상적인 개념이 아니라
실제로 쓰여진 문서를 두고 얘기하면 훨씬 수월하거든.
사람마다 머릿속 생각은 다 다르잖아. 근데 뭔가 구체적인 아티팩트가 있으면,
그걸 기준 삼아 논의하면 불필요한 충돌을 줄일 수 있어.
게다가 그런 문서 없이 논의하면, 대화가 자꾸 삼천포로 빠져.
핵심에서 멀어지고, 결론도 잘 안 나.
혹시 너희가 쓰는 툴 중에 꼭 이건 쓴다 싶은 거 있어?
아니면 그냥 당연히 Zapier 자체를 내부에서도 쓰겠지?
응, 우리도 Zapier 엄청 써.
OKR 관리도 내부 툴로 하고 있고.
근데 내가 기억나는 건, 너희가 초기 시절에 스스로 툴을 많이 만들었었다는 거야.
요즘엔 어떤 툴이 가장 도움이 되고 있어? 직접 만든 거든, 외부에서 쓰는 거든 간에.
음, 내가 초기에 만든 툴 중에 하나가 있는데,
우린 그걸 내부적으로 "Async"라고 불러.
그냥 쉽게 말하면 내부 블로그야.
우리는 슬랙을 가상의 사무실처럼 사용하거든.
좋든 나쁘든 간에, 아침에 출근하면 대부분 슬랙에 먼저 접속해.
업무는 대부분 거기서 얘기하지.
근데 문제는, 팀 규모가 커지면서 슬랙이 너무 시끄러워지기 시작한 거야.
모든 리모트 팀이 겪는 문제지.
“슬랙 어떻게 따라가요…?” 이런 질문 엄청 많아.
그래서 우리는 아주 초기에 **“슬랙은 무조건 다 따라갈 필요 없다”**고 명확히 못을 박았어.
채널은 자유롭게 나가도 된다.
심지어 우리는 슬랙 설정에서 채널 나가거나 들어갈 때 알림이 안 뜨게 해놨어.
사람들이 부담 없이 채널을 빠져나갈 수 있게 말이지.
그거 진짜 괜찮다.
나같은 사람은 차마 못 나가고 그냥 ‘알림 꺼두기’만 하거든. 괜히 눈치 보여서. 😅
맞아. 그래서 우리는 심지어 "슬랙 잘 쓰는 법"에 대한 코스도 만들고 있어.
신입 직원들한테 가르쳐주는 거야. Zapier에서 슬랙은 이렇게 씁니다, 하는 식으로.
이건 진짜 초창기부터 있었던 이야기인데,
우리는 아예 슬랙에 대한 기대치를 “이건 실시간 툴이 아니야”라고 못 박았어.
그럼 질문이 생기지.
“그럼 우리 조직에서 좀 더 깊이 있는 논의나 문서,
혹은 '최종 결과물' 같은 건 어디서 공유해야 하지?”
그래서 내가 만든 게 바로 Async라는 내부 블로그야.
슬랙은 말 그대로 그날그날 대화하고, 결정 내려야 할 걸 빠르게 처리하는 공간이잖아.
그러면 우리가 심사숙고해서 쓴 글, 장기적인 계획, 정리된 결과물은 어디에 올려야 하냐는 거야.
그래서 우리는 모든 직원에게 매주 하나씩 금요일에 '주간 보고'를 작성하도록 했어.
그걸 Async에 올리는 거야. 이게 일종의 회사 리듬, 회사 심장박동 같은 역할을 해.
초기에는 직원이 20~30명 정도였으니까,
누가 무슨 결정을 했고, 뭘 배웠고, 어떤 작업을 하고 있는지 다 읽을 수 있었어.
진짜 좋았지.
근데 팀원이 70, 80, 100명 넘어가니까
포스트가 너무 많아진 거야. 다 읽는데 하루 종일 걸릴 지경이었어.
슬랙이랑 똑같은 문제를 Async에서도 겪기 시작한 거지.
하지만 차이점은 뭐냐면, 이건 우리가 직접 만든 툴이라는 거야.
그러니까 우리가 커뮤니케이션 방식을 어떻게 설계하고 싶은지에 따라
툴을 우리 방식에 맞게 바꿔갈 수 있다는 점이 진짜 크지.
그래서 우리가 처음에 시작한 건,
기본 피드 뷰를 만들어주는 기능이었어.
그게 뭐냐면, 예를 들어 너의 직속 팀원들,
혹은 네가 꼭 팔로우해야 하는 사람들의 글만 큐레이션해서 보여주는 거야.
또 네가 팔로우하고 싶은 사람을 따로 지정할 수도 있고,
커스텀 피드 뷰를 만들 수도 있어.
즉, 너한테 꼭 필요한 정보만 골라서 볼 수 있게 한 거지.
우리는 새로 입사한 사람들이 이 기능을 잘 쓸 수 있도록,
매니저들이 직접 도와줘.
“이 사람은 이 정보 봐야 하니까 이 피드에 추가하세요” 이런 식으로 말이지.
그래서 자연스럽게 각자에게 필요한 정보가
적절하게 정리된 형태로 전달되게 돼.
그럼 이메일은 너희 회사에선 어떤 역할이야?
내부 커뮤니케이션용으로도 쓰는 거야? 아니면 그냥 외부용?
우리 내부에선 거의 이메일 안 써.
그건 진짜 내 꿈이었거든. 😄
내부 이메일은 완전 금지야.
우리는 슬랙과 Async 이 두 가지로 모든 내부 커뮤니케이션을 처리해.
물론 이메일이 아예 없는 건 아니야.
예를 들어 고객 지원은 Help Scout이라는 툴을 써서 이메일로 처리하고 있어.
그리고 고객이나 파트너랑 외부 커뮤니케이션 할 땐 이메일을 써야 하니까,
그럴 땐 당연히 이메일을 사용하지.
근데 사내에서는 슬랙과 Async가 전부야.
우리가 또 하나 사용하는 툴이 있어.
바로 Quip이라는 건데, 이건 좀 더 장기적으로 보존해야 할 문서를 위한 툴이야.
구글독스랑 위키를 섞은 것 같은 툴이라고 보면 돼.
예를 들면, 프로세스 정리 문서나 채용 평가 기준표 같은 건
슬랙이나 Async처럼 금방 사라지면 안 되잖아?
이건 오랫동안 살아 있어야 하고,
언제든지 찾아볼 수 있어야 해.
Async나 슬랙은 일종의 피드 기반이라서
시간이 지나면 뒤로 밀려나거든.
근데 Quip은 그런 정보들을 영구적으로 저장해두는 공간이야.
우리 회사에서 사람들이 좀 놀라워했던 게 있어.
바로 우리가 내부 툴 개발에 얼마나 많은 시간과 리소스를 쓰는지야.
실제로 **개발 시간의 30~40%**는 우리 스스로를 위한 툴을 만드는 데 썼어.
덕분에 10명 남짓한 작은 팀으로도 오랫동안 버틸 수 있었고, 빠르게 성장할 수 있었지.
Zapier도 그래? 내부 툴을 따로 만드는 팀이 있어?
페이스북 같은 데선 이런 팀 따로 있잖아.
응, 작년에 우리는 그런 팀을 만들어서
Async 같은 내부 툴을 스케일업하는 데 집중했어.
근데 최근 6개월 동안은… 사실 나 혼자서 그거 다 만들었어. 😅
내가 일종의 내부 툴 개발 담당자가 된 셈이지.
예를 들어 OKR 기능도 우리가 Async 안에 직접 만들어 넣었어.
우리가 만든 OKR 툴은 좀 특이한데, 포스트와 바로 연결돼 있어.
그러니까, OKR 지표 그래프를 보면
“이때 이 기능을 런칭했어요”,
“이때 이 결정을 내렸어요” 같은 주석이 같이 붙어 있어.
덕분에 시간 흐름에 따라 어떤 일이 일어났는지 맥락이 한눈에 보여.
“지표가 왜 이렇게 움직였지?” 생각할 때 바로 확인할 수 있지.
지금은 좀 더 유기적으로, 각 팀이 필요하면 자체적으로 내부 툴을 만드는 구조야.
예전 초창기엔 우리가 더 많은 시간을 내부 툴에 썼고,
사실 지금도 나는 거기에 더 많은 시간을 쓰고 싶어.
왜냐하면… Async를 만들 때도 느꼈는데,
우리 회사에서 만든 내부 툴들이 나중에 보면 전부 스타트업 아이디어더라고. 😄
예를 들어 Async도 내가 만들면서
“이거 그냥 하나의 스타트업 될 수 있겠는데?” 싶은 거야.
최근에는 Zapier 안에서 내부적으로 개발된 툴 중 많은 게
Zapier 위에 만들어진 앱 형태야.
우리 엔지니어링 팀뿐 아니라
고객지원팀, 프로덕트 디자인팀 사람들도
작은 기능들을 Zapier 앱으로 만들어서
Zapier 자체에 기능을 붙이곤 해.
그리고 그런 작은 사이드 프로젝트들이
Zapier에서 가장 인기 있는 기능이 되기도 해.
그냥 재미로, 혹은 해커톤 때 만든 건데 말이야.
이게 사실 대기업 해커톤에서 가장 많이 나오는 비판 중 하나거든.
사람들이 주말 내내 열심히 만들고 되게 신나 있는데,
그 결과물이 결국 실제 제품으로는 안 나오는 경우가 많아.
근데 우리 회사는 좀 달라.
우리는 해커톤을 할 때도, 그냥 막 아무거나 하지 않고
"이게 진짜 고객한테 도움이 될 수 있을까?"
라는 관점에서 아이템을 선별해서 진행하려고 해.
그렇게 하면, 결국엔 그게 실제 제품에 붙게 되더라고.
그럼 이렇게 전사적으로 리모트로 일하면서
직원들의 사기나 창업자들의 사기를 어떻게 유지해?
즉, 모티베이션을 어떻게 높게 유지하냐는 거지.
아마 우리가 하는 것 중에 제일 큰 게,
연 2회 전사 리트릿(company retreat)이야.
우리는 100% 리모트 회사지만,
직접 얼굴을 맞대는 시간의 가치도 분명히 있다고 생각해.
그 시간을 통해서
서로에 대한 공감(empathy)을 쌓고,
관계를 만들 수 있어.
그리고 나중에 슬랙 같은 텍스트 기반 툴에서 대화할 때도
“아, 저 사람 말투가 원래 좀 그래. 악의 없지.”
하고 생각할 수 있게 되는 거야.
이런 게 없으면,
그냥 짧고 딱딱한 문장 하나에
“왜 이렇게 퉁명스럽게 말하지?” 하고 오해하기 쉽거든.
그래서 우리는 리모트 근무지만,
직접 얼굴 보는 시간의 중요성은 절대 무시하지 않아.
슬랙이나 이메일 같은 텍스트 기반 커뮤니케이션은 감정 전달이 어렵잖아.
특히 긴장된 상황에선 더 그렇지.
그럴 때 가장 먼저 희생되는 게 바로 ‘톤(tone)’이야.
말투나 느낌이 잘 전달이 안 돼.
그래서 우리는 매년 두 번씩 전사 리트릿을 해.
회사 전체를 미국 어딘가—보통은 리조트나 호텔—로 불러 모아.
그럼 그 리트릿은 며칠 동안 해?
일주일 정도 하고, 마지막 금요일쯤 마무리해.
그 기간 동안은 그냥 노는 거야?
아니면 뭔가 구조적인 활동도 있어?
우린 몇 가지 포맷을 시도해봤는데,
전통적으로는 일주일 내내 해커톤을 해왔어.
그리고 이틀 정도는 팀별로 자기들끼리 모여서 일하게 했고.
근데 최근 리트릿에선 좀 다른 시도를 해봤어.
우리는 회사에서 뭔가 바뀔 때마다 항상 설문조사를 해.
"이번 리트릿 어땠어요?" 같은 피드백 받는 거지.
그 설문조사, 이메일로 보내?
아니, 보통 슬랙이랑 연동된 툴로 보내.
물론 이메일로도 가긴 하지.
나도 아직 Gmail 탭은 항상 열어두긴 해. 😅
리트릿 끝나면 설문 보내고,
또 회사 전체 대상으로 연 4회 정도 전사 설문도 해.
내가 작년엔 프로덕트 전반에 대한 설문을 돌렸었고.
이런 식으로 피드백을 많이 모아서,
그걸 바탕으로 우리가 어떻게 더 나아질 수 있을까를 고민해.
그럼 리트릿에서 최근에 새롭게 시도해봤는데,
“이건 진짜 좋았다” 싶은 게 있었어?
응, 이번에 시도한 것 중에서 제일 좋았던 건 “비구조화된 시간”을 만든 거야.
그전까지는 리트릿의 모든 시간을 전부 계획해서 짰거든.
“이 시간엔 이 활동, 저 시간엔 저 회의”
완전 타이트하게 스케줄을 짜놨어.
근데 이번엔 일부러 이틀 오후를 아무 일정 없이 비워뒀어.
왜 이제서야 그 생각을 했냐고? 나도 그게 참 궁금하더라. 😅
아마 리모트 환경에서 일하다 보니,
뭔가 다 프로세스로 설계돼야 한다는 강박이 있었던 것 같아.
그러니까 “사람들이 어떻게 협업해야 하지?”,
“어떻게 연결되게 만들지?” 이런 걸 우리가 모두 설계해줘야 한다고 생각했던 거지.
그리고 매니저 입장에서도,
“우리 팀원들이 뭘 해야 할지 모르면 어떡하지?”
하는 **책임감 같은 게 있었던 것 같고.
그래서 리트릿 스케줄을 매 시간 꽉꽉 채우는 게 기본이었어.
근데 그게 오히려 문제였던 거야.
왜냐면, 예를 들어 데이터 팀 사람이랑
고객지원 팀 사람이랑
엔지니어 한 명이 같이 얘기하다가
“어? 우리 이거 한번 같이 해보면 좋겠는데?” 싶을 수도 있잖아?
근데 그런 게 자유롭게 일어날 시간이 없는 거야.
우리가 만든 스케줄이 그런 자발적인 협업의 기회를 다 막아버리고 있었던 거지.
그래서 이번에 이틀 오후를 그냥 자유 시간으로 주고,
“이건 여전히 근무시간이니까, 너희가 제일 잘 쓸 수 있는 방식으로 써봐”라고 했어.
그럼 그게 잘 작동했는지는 어떻게 알았어?
대부분은 피드백을 통해서 알았어.
처음엔 솔직히 좀 걱정됐거든.
“사람들이 진짜 이 시간을 잘 쓸까?”
“그냥 원래 하던 일이나 하지 않을까?”
“리트릿 와서도 지원 티켓 처리만 하고 있으면 어떡하지?”
이런 생각이 계속 들었지.
그래서 리트릿 전에도 내가 사람들한테
이 시간을 진짜 잘 활용하라고 강조를 많이 했어.
“이건 진짜 기회니까, 팀원들과 뭐라도 같이 해봐” 이런 식으로.
그리고 실제로 그 시간에
내가 리트릿 장소를 돌아다니면서 사람들 구경해봤는데,
정말 많은 사람들이 적극적으로 뭔가 하고 있었어.
내가 괜히 걱정했더라고. 😂
그리고 생각해보면, 우리가 디폴트 액션을 중요하게 여기는 사람들만 뽑잖아.
그런 사람들이 한자리에 모였는데,
자기 주도적으로 뭔가 안 할 리가 없지.
그러니까 결국 중요한 건,
딱 적절한 수준의 압력과 자율성을 함께 주는 것 같아.
그래서 이번 리트릿은 진짜 잘 됐고,
앞으로도 이런 비구조화된 시간은 계속 넣으려고 해.
아까 얘기했던 것처럼,
디자인 크리틱은 어떻게 해?
디자인이라는 게 워낙 협업적이고 복잡하잖아.
수백 개 앱이 연결되고, 수많은 기능들이 엮여 있는 인터페이스를 다뤄야 하니까.
그걸 사람들끼리 붙어서 한참 얘기해야 해결될 것 같은데,
그걸 리모트로 어떻게 해결해?
진짜 그게 궁금해.
음… 나도 궁금한데,
혹시 네가 그렇게 생각하는 전제나 경험이 뭐야?
왜 그런 문제를 꼭 옆에서 붙어서만 해결할 수 있다고 느낀 거야?
음… 그냥 내 생각엔, 특히 디자인 작업에서는
예를 들어 원형을 그린다거나, 스케치하거나, 포인트를 짚는 그런 순간들이 있잖아?
그걸 종이에 그리면서
“이 부분은 이렇게 바꾸면 어때요?” 하면서
손으로 직접 보여주고 얘기하는 게 더 자연스럽다고 느꼈거든.
물론 화면 공유나 영상으로도 할 수는 있는데,
뭔가 그게 더 느리고 덜 효율적이라고 느껴졌어.
그래서 궁금했어, 너희는 그런 걸 어떻게 보완하고 있나?
좋은 질문이야.
결국 이건 또 **‘명확하게 만드는 것’**의 문제로 돌아가.
내가 자주 팀이랑 하는 워크숍 중 하나가 있는데,
바로 "9박스 디자인 스케치"라는 거야.
종이를 아홉 칸으로 접고,
각 칸에다가 두세 분 안에 아이디어를 하나씩 스케치해.
9개의 다른 아이디어를 빠르게 그리는 거지.
그리고 그걸 서로 돌아가면서 보여주고,
다시 그걸 바탕으로 리믹스하거나 발전시키는 시간을 갖는 거야.
이 방식의 핵심은 짧은 시간 안에 깊게 고민하지 말고, 넓게 아이디어를 펼쳐보는 것이야.
너무 고민하다 보면 초반부터 한 방향으로 굳어지기 쉬우니까,
그걸 방지하려고 일부러 제한 시간을 둬.
이걸 우리는 줌으로도 자주 해.
예전엔 회사 전체, 한 70~80명한테도 이걸 했었어.
“자, 종이랑 굵은 펜(샤피) 준비하세요!”
이렇게 말해놓고 문제 상황을 던져.
그러면 다들 각자 책상 위에 종이 놓고 스케치하기 시작하지.
그리고 나서 다 같이 줌 화면에 종이를 들어서 보여줘.
그리고 자기 아이디어를 간단히 설명하고,
슬랙에 사진으로도 올려서 더 선명하게 공유하지.
오히려 이 방식이 오프라인보다 더 강력하다고 느낄 때도 있어.
왜냐면 회의실에 다 같이 앉아 있을 땐,
사람들이 “내가 이거 보여줘도 될까?” 하고 눈치를 보거나 긴장하거든.
특히 디자이너가 아니면 더 그렇고.
근데 각자 자기 공간에서 하면,
자신감 있게 다양하게 시도할 수 있어.
심지어 좀 이상한 아이디어도 부담 없이 보여주게 되더라고.
근데 사람들이 그런 스케치를 보여주는 걸
부끄러워하거나 어색해하는 경우도 있어서,
나는 항상 “그거 별로라고 생각해도 그냥 보여줘요”라고 말해줘.
왜냐면 처음엔 이상하게 보이는 아이디어들이
결국엔 제일 좋은 아이디어로 이어지는 경우가 많거든.
그게 완성형이 아니더라도,
전혀 다른 방식으로 문제를 생각하게 해줄 수 있어.
그리고 또 하나 우리가 자주 쓰는 프로세스가 있는데,
이건 팀 전체가 참여하는 스케치 말고,
실제로 제품팀에서 매주 진행하는 피드백 루틴이야.
우린 일주일에 두 번, 화요일과 목요일에 디자인 리뷰 세션을 해.
여러 제품 디자이너, PM들을 초대해서,
화요일에 아이디어나 진행 중인 디자인을 공유하고
리뷰를 받고, 크리틱을 받아.
그 다음 48시간 안에 빠르게 다시 작업해서
목요일에 다시 보여주는 거야.
이렇게 되면 매주 두 번의 리뷰 사이에서
깊게 집중할 수 있는 시간도 확보되면서,
계속 반복해서 개선할 수 있는 루프가 만들어져.
그리고 이 모든 건 여전히 줌 화상회의로 해.
줌 회의할 때 내가 꼭 부탁하는 게 하나 있는데,
“마이크 끄지 마세요”라고 말하는 거야.
특히 디자인 협업 세션에선.
우리 회사는 리모트로 일하면서
줌 예절 같은 게 좀 생겼거든.
언제 비디오 켜고, 언제 말하고, 언제 마이크 끄고…
근데 난 그걸 의도적으로 깨라고 해.
이 세션만큼은 “그냥 마이크 켜두고 편하게 얘기해요”라고 해.
왜냐면, 그래야 서로 눈치 보지 않고 바로바로 피드백을 줄 수 있거든.
이게 약간 무작위성이 생기게 해주는 장치야.
예측할 수 없는 대화 흐름, 갑작스러운 피드백,
이런 게 오히려 아이디어에 활기를 넣어줘.
리모트 회사에선 이런 게 더 중요하다고 생각해.
누가 트위터에 이런 질문을 했었는데,
“리모트 회사에서 어떻게 혁신이 생기게 만들죠?”
이게 진짜 좋은 질문이야.
내 생각엔, 조직 안에 약간의 **무작위성(randomness)**은 꼭 필요해.
물론 무작위가 100%가 돼버리면 안 되겠지만,
적당히는 있어야 해.
예를 들어, 사람들이 우연히 만나서 대화하다가 생기는 아이디어—
이런 걸 요즘은 ‘워터쿨러 순간’이라고 하잖아?
우린 그런 걸 일부러 프로세스로 만들었어.
**“페어 버디(pair buddies)”**라고 해서
이제는 3명씩 짝을 지어.
슬랙에 있는 봇이 무작위로 세 명을 골라서
“30분 통화해보세요” 하고 알려줘.
아무 의제 없이 그냥
“요즘 뭐하고 있어요?” 같은 얘기 나누는 거야.
그러다 보면 생각지 못한 아이디어가 나오기도 해.
이 시스템은 내가 봤을 때 꽤 괜찮았어.
근데 또 솔직히 말하자면,
많은 회사들이 ‘우연’에 너무 집착하는 것도 이상하다고 생각해.
“혹시 어디선가 대박 아이디어가 나올 수도 있잖아!”
이런 마인드인데…
그건 솔직히 로또 맞길 바라는 거랑 비슷한 거잖아.
대부분의 회사는 로또 맞을 시간 없거든.
해야 할 일이 빼곡히 정해져 있어.
그래서 내 생각엔 우선순위는
‘우연한 아이디어’보다
지금 해야 할 일을 확실히 해내는 게 먼저라고 생각해.
물론 해커톤처럼 완전 개인 주도적인 프로젝트에서
의외로 대박 아이디어가 나온 적도 있어.
아무도 위에서 시키지 않았는데,
재미로 만든 게 나중에 되게 중요한 기능이 되기도 했고.
이게 중요한 포인트야.
적당한 압박감이 쌓이고, 그걸 풀어주는 기회가 생겼을 때
그게 진짜 좋은 결과로 이어지더라고.
반면에 “그냥 다 같이 모여서 뭐라도 해보자~”는 식이면
그렇게 잘 안 되는 것 같아.
결국 핵심은,
서로가 뭘 하고 있는지 아는 게 먼저야.
이건 정말 모든 회사에서 똑같이 어려운 문제야.
예를 들어, 나도 케빈이 최근 2주 동안 정확히 무슨 일을 했는지는 몰라.
“아, 요즘 이메일 좀 많이 했구나” 정도지.
실제로 뭘 만들었는지까지는 모를 수 있어.
근데 우린 좀 다른 문제가 있어.
오히려 너무 많은 정보가 있다는 거야.
“다들 뭘 하고 있는지는 알겠는데,
내가 그 중에서 뭘 챙겨봐야 하는지를 고르는 게 어렵다”는 거지.
자, 이제 거의 마지막으로 왔는데,
만약 내가 리모트 회사 하나를 새로 만든다고 하면
**“성공적으로 시작하기 위한 프레임워크”**가 궁금하지?
내가 봤을 땐,
기존 회사에서 리모트를 도입하려는 게 더 어렵고,
처음부터 리모트로 시작하는 게 훨씬 유리해.
왜냐면 기존 회사엔 이미 자리잡힌 문화가 있고,
그걸 바꾸는 건 진짜 어렵거든.
리모트는 단순히 **툴이나 프로세스 문제가 아니고,
‘문화적인 변화’**야.
그래서 처음 시작하는 창업자들이 더 유리해.
왜냐면 아직 아무 문화도 없잖아.
그걸 처음부터 리모트에 맞게 세팅할 수 있으니까.
그러니까 처음부터 디폴트 액션, 자율성, 의사결정 방식 같은 걸
정말 잘 생각해서 시작해야 해.
그리고 무조건 기록하고 공유하는 습관을 만들어야 해.
“내가 지금 뭘 했는지” 말로만 하지 말고,
다른 사람들도 볼 수 있게 글로 남기는 문화.
줌 콜로 얘기만 하고 끝내면
그건 휘발성이고 다 사라져.
기록이 있어야 공유되고, 나중에 써먹을 수 있어.
이런 문화적 습관은 나중에 바꾸기 진짜 어려워.
처음부터 잘 세팅해야 돼.
우리처럼 100% 분산된 조직에선
누구 하나만 안 해도 다 무너져.
“다들 집에서 일하니까”
그 문화를 안 따라가는 사람은
혼자만 고립되고 성과도 못 내게 돼.
그래서 시작할 때부터
자율적이고, 의사결정 잘하고, 글로 잘 소통하는 사람을 뽑아야 해.
나는 신입 엔지니어나 디자이너들에게 항상 얘기해.
“과하게 소통하세요.
슬랙 채널에 아무도 답 안 해도 그냥 상황 공유하세요.”
그게 처음엔 어색하고 뻘쭘한데,
다른 사람들한테는 엄청 유용해.
예를 들어, 네가 “지금 이거 하고 있어요”라고 쓴 게
누군가가 막히던 걸 푸는 힌트가 될 수 있거든.
특히 시차가 다를 땐 더 중요해.
상대가 자고 있을 수도 있으니까.
그래서 진짜 중요한 두 가지는 이거야:
자율성(autonomy)
글 기반 커뮤니케이션(written communication)
우리 이거 관련해서 책도 하나 썼잖아?
맞아. 리모트 회사 운영에 대한 책.
다만 그건 지금 기준으론 몇 년 전 얘기라 조금 옛날 버전이야.
가장 크게 업데이트하고 싶은 건 뭐야?
음… ‘Async’를 어떻게 확장해왔는지 그걸 꼭 추가하고 싶어.
그 책 쓸 땐 아직 회사가 작아서,
거기 나오는 콘텐츠를 대부분의 사람들이 다 읽을 수 있었어.
지금은 너무 커져서 그게 안 되지.
그래서 우린 이제 훨씬 더 정교한 시스템을 짰어.
예를 들어,
누가 어떤 글을 꼭 읽어야 하는지,
무슨 알고리즘으로 그걸 뽑아서 보여줄 건지,
이런 것까지 다 설계해야 하거든.
그럼 너희가 영감을 받은 다른 리모트 회사들은 누구야?
우리가 보고 배운 회사들은 좀 더 규모가 커.
GitLab, InVision, Automattic 같은 회사들.
이 회사들이 우리보다 훨씬 크고,
완전 리모트로도 잘 돌아간다는 걸 증명해줬어.
우리가 거기서 배운 건
프로세스나 문화 자체라기보단, “이게 가능하구나”라는 확신이었어.
우리가 처음부터 새로운 길을 여는 게 아니라는 걸 안 거지.
각 회사마다 세부 가치나 운영방식은 조금씩 다르지만,
어쨌든 그 규모로도 리모트가 가능하다는 걸 알게 해준 게 제일 컸어.
이제 이걸로 마무리하자.
완전 리모트 회사도 충분히 성공할 수 있다는 거,
그리고 너도 그런 회사를 만들 수 있다는 거.