CodeStates에선 어떻게 일을 해야할까
CodeStates 에서는 말 그대로
하루에도 수백가지 고민과 아이디어들이 나오는데요.
최근 있던 이야기는 “어떻게 해야 일을 압도적으로 잘할 수 있을까?” 입니다.
이 단순하지만 복잡한 질문에 대해서 이미 고민을 해본 적이 있는 크루들도 있는데요. (사실 회사 외부에도 “일잘러” 에 대한 좋은 컨텐츠들은 많이 있죠).
이들이 했던 시행착오와 고민들을 “구전동화”의 형태로
일일히 커피타임을 통해 전달하기보다는,
앞에서 했던 고생들을 “조금 덜 해맬 수 있게”
가이드라인을 만드는 건 어떨까? 라는 고민을 했고,
이를 만들게 되는 동안 나눴던 이야기들을 다듬어서
여러분들에게 소개해드리려고 합니다.
이미 Codestates의 노션에는,
아래와 같은 “일잘러 직무 온보딩”이라는 페이지가 있습니다.
일에 대해서 늘 고민하시는 일모님(CPO)께서 열심히 모아두신 건데요.
목적은 단순합니다.
“우리 모두가 어벤져스처럼 일당백으로 일을 잘해내자.”
라는 겁니다.
CodeStates의 크루는 어느 새 70명으로 어마어마한 성장을 했습니다.
(제가 입사할 때는 29명이었습니다!)
그러다보니 늘어나는 크루와 온보딩의 수만큼,
다양하지만 각자의 개성을 살리면서도 하나의 공통된 필터로
- 커뮤니케이션
- 회의
- 일 관리, 시간 관리
와 같은 중요한 “역량”들을 더 효과적으로 습득할 수 있지 않을까?
라는 생각도 늘어나게 되었습니다.
(물론 이러한 역량들은, 회사를 다니면서 혼나고 깨지면서 배우게 되는 것들이지만요)
이렇게 Quality guarantee 된 “북극성”은 어떤 관점에서 봐야 할까?
이 “어벤져스가 되는 방법”을 고민하기 전에, 우리는 구체적인 질문을 먼저 했습니다. “무엇을 어디까지 알려줘야 하나” 가 먼저 정해져야 했던 거죠.
그리고 이야기의 결론은 이 “일잘러 온보딩” 기간을 거쳤을때,
“다 알고 있다”까진 아니어도
“이런게 있다는 것에 대해서 인지”하는 것이
우리가 기대하는 일잘러 온보딩의 핵심 목적이라는 걸 알게 되었습니다.
“인지해야 한다” 라고 정하게 된 이유는
- 일을 잘하는 방법은 하나만 있는 것도 아니고
- 어떤 크루는 이미 본인만의 방법을 알고 있기 때문인데요.
그렇기 때문에 무언가를 강제하는 가이드라인이 아닌 자신만의 타임라인으로 익혀 나갈 수 있도록 “리마인더” 하자는 결론이 났습니다.
추가로, 이 북극성이 안내하는 궁극적인 목적. “성장을 위한 업무”라는 것은 :
- 약간 고통스러워야한다. (업무를 하며 발전이 되려면 고통은 필연적일 수 밖에 없기 때문이죠).
- 재밌고 쉽기만 하면 안된다.
- 업무의 실행과정은 고통스러울 수 있지만, 완결과 lesson-learned를 얻고 개선하며 높은 성장이 가능하다
와 같은 추가 설명들도 있었습니다.
이미 Code States에는 온보딩이 있지 않나요?
아마 이런 생각을 하실텐데요,
사실 이미 “제너럴 온보딩”은 아래 이미지와 같이 진행되고 있었습니다.
그러나 이번에 다루었던 “일잘러 온보딩”은 더 추상화된 내용이고,
우리가 이미 하고 있던 “제너럴 온보딩”은 이를 가시화 한 내용,
즉 “제너럴 온보딩”은 사내에서 사용하는 툴, 규칙에 대한 설명에 더 가까웠다 라는 차이가 있습니다. (번외로, 사실 업무에 사용하는 툴은 그렇게 까지는 중요하지 않은 것 같아요.)
회사마다 사용하는 툴은 전부 다르기도 하고,
심지어 CodeStates에서도 팀별로 다양한 툴들을 사용하고 있는데,
시트, 타입폼, 자피어 정도를 제외한 다른 툴들은,
상대적으로 일을 하면서 배워도 충분하기 때문입니다.
(물론, “러닝데이를 통해” 서로가 배운 내용을, 열심히 공유하기도 합니다)
그래서 “일잘러 온보딩”에서는 더 일의 근원이 되는 이야기.
- 방법론이나,
- 스타트업의 문화,
- 일하는, 생각하는 방식,
- 지켜야할 원칙
과 같은 것들을 다루기로 했습니다.
한편 “레이어” 또한 나눠야 했습니다.
사회생활을 처음 하는, 일에 대해서 완전히 새로운 크루들도 있고,
이미 “일”에 대해서 알고 있는 분들도 있기 때문에,
어느 정도 레벨 혹은 수준에 따라서 가이드라인을 나눠야 한다는 거죠.
이를 통해 “잘 지어진 가이드라인”이 성공적으로 정착하고,
정기적으로 진행되어 효과를 낸다면 크루 뿐 아니라
매니저들에게도 도움이 될 것은 확실했습니다.
일종의 우리가 이전에 배웠던 “수학의 정석” 처럼,
각 팀마다 조금씩은 다를 수 있지만,
전사적인 원칙을 크게 반하지 않는 우리의 전통이 되는 거죠.
이전에는 이런 고민이 없었나요?
사실 이 “수학의 정석”과 비슷한,
이미 작성되어 있는 “코드스테이츠가 일하는 방식”이라는 글이 있었지만,
이 글은 상당히 추상적이고, 매우 나이브하게 작성되어 있습니다.
그러다보니 이전에도 “업데이트”에 대한 얘기들을 했던 적이 있는데요,
그때마다 액션이 나오지 못했던 이유는 크게 2가지였습니다.
- 첫번째로 그럼 “누가 일을 잘하는데?” 의 문제였고,
- 두번째로는 그 “일을 잘하는 사람이 시간이 되긴 해?” 의 문제였죠.
그래서 이번에는 “우리가 만들자”가 아닌 “큐레이션하자” 로 방향을 바꾸게 되었습니다.
사실 굳이 모든 것을 우리가 만들 필요가 없는 이유가 있었는데요.
수많은 “일 잘하는 사람”들을 대상으로 연구되어 있는
“공통적인 특징”이 있고, 인터넷에는 이를 정리한 자료들도
충분히 있기 때문입니다.
그래서 우리가 모아두고, 잘 정리해서 MVP로 만들어보고
전사에 공개 후, 피드백을 통해 더 개선하기로 했습니다.
여기서 피드백이 필요한 이유는,
모든 크루가 동일한 방식으로 일할 필요가 없고,
더 나아가 팀과 상황에 따라서도 다를 수 있기 때문입니다.
예를 들면, 모든 팀이 Asana를 쓸 필요는 없다라는거죠.
(실제로 ENG팀에서는 Jira를 더 사용하고 있습니다)
그리고 만약, 우리가 모아둔 것들보다 더 좋은 아이디어가 있다면
그 방법대로 해도 문제 없고, 오히려 저희는 그러한 문화를 권장합니다.
그러나 “일과 방법”에 대해서
“알지만 안하는 것”과 “몰라서 못하는 것”은 다르다고 생각합니다.
이 “북극성”은 한번 만들어두면, 채용 인터뷰에도 사용 할 수 있습니다.
어떤 회사들은 이미 경영진, 리더십, 크루분들을 대상으로 조사해서
문서화하고 이를 적극적으로 사용하고 있다고도 합니다.
예를 들면, 회의를 할때 “어떻게 준비를 했는가”, “어떠한 프로세스를 가지고 있는가” 와 같은거죠.
이런 것 없어도 잘 굴러가는 회사들도 있는데요?
“일 잘하는 사람들이 모여있는 회사”에는 이런 고민이 필요 없습니다.
이미 “말하지 않아도” 모든 크루가 알고 있기 때문인데요.
한 예시로, 어떤 회사 같은 경우는
더 효과적인 communication을 위해 “좋은 ppt 빠르게 만들기”를
주말 동안 연습하는 사람들이 모여있다고도 해요.
아쉽게도 우리 CodeStates는 이러한 “시니어”들로 가득 차 있다고 보기엔 어렵습니다.
이를 해결하고, 전사를 “시니어, 베테랑”으로 가득 채우는 방법은
- 다 해고하고 시니어로만 팀을 꾸려 시작하거나
- 건강한 주니어들과 같이 발전하는 2가지가 있습니다.
(둘 다 되지 않으면 Codestates는 그냥 동아리가 되는 거죠)
CodeStates는 위 2가지 중에서 전자보단 후자를 더 지향하기 때문에
이러한 “같이 성장하는” 방법을 고민하게 되었습니다.
그리고 이 “일잘러 온보딩”을 완성하고, 시간이 지난 후,
“코드스테이츠에서 일하는 사람들은 진짜 일 잘하더라.”
라는 소리를 듣는 것이 우리가 원하는 것이다 라는 결론을 낼 수 있었습니다.
이 “일잘러 온보딩 커피타임” 동안 모든 크루가 동의 했던 것은,
일잘러 온보딩 문서가 효과적이냐 아니냐를 넘어서
이런식의 더 압도적으로 잘하기 위한 고민과 노력 자체가 정말 중요하다.
라는 것입니다.
실제로 성장단계에서 이러한 고민을 하는 기업과,
자유라는 이름하에 두는 기업의 성장속도는 다를 것이라고 생각해요.
하지만, 너무 구체적인 액션가이드는 상상력을 제한할 수 있습니다.
예를 들어
“효과적인 회의를 위해 해야할 10가지”라고 작성한다면
“이 10가지만 하면 되는건가?” 라는 생각이 들 수 있다는 거죠.
그래서 액션가이드는, “이렇게 이렇게 해야해” 라고 하는 것보다는,
큰 원칙만 두고 더 창의적으로 문제 해결을 권장하는 방향이어야 합니다.
Jr들을 위한 Why에서 How
너무 당연한 이야기지만 아무리 좋은 자료라고 해도
“온보딩 때 읽으세요” 만으로는 의미가 없습니다.
“좋은 내용이네요.” 이상의 리액션은 기대할 수 없기 때문인데요.
“더 좋은 리액션”을 위해서는 입사 후 3일 정도,
회의실에서 이 가이드만 읽고 리뷰를 쓰게 하는 게 좋을 수도 있습니다.
이 시간 동안 가이드를 통해 중요한 것들을 상기하고 숙지할 수 있다면 앞으로의 3개월간 시간 낭비를 줄일 수 있기 때문이죠.
(그러나 우리는 연수원이 있는 대기업처럼 크루를 “특정 공간에 가두기”는 어렵기 때문에, 방법에 대해서 여전히 고민 중입니다.)
동시에 이 3일 동안 “일을 잘하는 것” 에만 집중하기보다는,
CodeStates에서는 이렇게 일을 하고,
생각하는 사람들이 일을 잘하는 사람들이다
라는 가이드라인 정도만 줘도
신입 크루들의 입장에서는 크게 도움이 될 것이다 라는 의견도 있었습니다.
회사에 왔으니
- 성과를 내야할 것 같은데.
- 조급하기는 하고
- 어떻게 해야할 지 잘 모르겠는
신입 크루들의 고민을 많이 해결 할 수 있다는 거죠.
예를 들어, 업무요청의 경우, 배경, 이유, 결과가 다 필요한데요.
이게 명확하지 않으면 “그래서 어쩌라는 거죠?” 와 같은 답변이 나오게될테고 이는 우리의 소중한 시간을 낭비 할 수 있다는겁니다.
대기업이 아닌, “스타트업”의 Jr 한테는 “Why, 왜, 일잘러가 되어야 하는지.”에 대해서 회사가 머리 속에 심어줘야 합니다. 물론 동기부여는 회사에서 하는 것이 아닌 개인이 하는 것이 훨씬 효과적인데, 이 문장자체가 Jr들에게는 잘 안 와닿을 수도 있기 때문입니다. 물론 기존의 크루들한테는 일잘러가 되는 구체적인 “How”를 기준으로 접근해야 하겠죠.
이러한 고민은 다른 회사들도 비슷하게 하고 있습니다.
그러나 필요성은 느끼는데 하자고 하면 끝도 없고, 리소스도 없어서,
Publy 같은 큐레이션 된 서비스를 단체구독하게 하는 이유가 아닐까요?
아무튼, 이 끝이 없던 이야기의 결론은 이렇습니다.
일단 정말 말도 안되게 모아 놓은 이 문서를 사내에 공유하고,
피드백을 받아 앞으로 개선해가자.
(일잘러 온보딩 문서는 지금 이 시간에도 개선중입니다 !!)
번외
- 우리는 이 문서를 다듬어서 1주 안에 배포하려고 했습니다만,
그 날 저녁에 배포했습니다. Move Fast ! - 관심있는 회사들이 연합해서 서로 github PR을 날려가며 집단지성으로 만들 수 있지 않을까? 도 고민했습니다.
- 우리 회사에 있는 “일잘러”들도 모든 것을 다 잘한다고 생각하지는 않았습니다. 그러나 그들의 “모를 수 있지, 근데 곧 모르는 건 채울꺼야”와 같은 Continuous Learning의 마인드가 중요하다고 생각합니다.
