30-60-90 플랜

새로 합류한 사람의 첫 석 달에는 오랫동안 기준이 없었습니다. 첫 주에 문서 링크 스무 개와 계정을 받고, 그다음부터는 필요한 것이 있으면 말하라는 안내만 남습니다. 준비가 부족했던 것이 아니라 무엇을 언제까지 해내면 되는지를 적어 둔 곳이 없었을 뿐입니다.

그러면 3주째에 이런 질문이 나옵니다. 제가 지금 잘하고 있는 건가요. 관리자도 답할 기준이 없어서 대답은 잘하고 있다는 말로 나갑니다. 두 달 뒤 첫 평가 자리에서 서로가 다른 기대를 품고 있었다는 사실이 처음 드러납니다. 관리자는 두 달째에는 기능 하나를 맡을 줄 알았고, 새로 온 사람은 아직 배우는 기간이라고 생각했습니다.

반대쪽 실패도 흔합니다. 첫날부터 실무를 몰아 주면 배경을 모르는 상태에서 짐작으로 처리하게 되고, 그렇게 만든 결과물은 두 주 뒤에 다시 만듭니다.

30-60-90 플랜은 이 석 달을 세 구간으로 잘라 각 구간의 도달점을 미리 적어 둡니다. 앞쪽에는 배우는 일을, 뒤쪽에는 맡는 일을 놓아 순서를 만듭니다. 문서가 하는 일은 두 가지입니다. 새로 온 사람에게 지금 어디쯤인지 알려 주고, 관리자에게 무엇을 언제 확인할지 알려 줍니다.

구간이 셋이고 구간마다 도달점과 그것을 위해 할 일과 확인 시점을 적습니다. 전체 분량은 한 장이면 충분하고 구간마다 항목 세 개에서 다섯 개를 둡니다.

1. 30일은 배우는 구간입니다. 읽을 문서 목록, 만날 사람 목록, 제품을 직접 써 보는 과제를 놓습니다. 도달점은 작게 잡습니다. 새로 온 개발자라면 작은 버그 하나를 고쳐 운영 환경에 올리는 정도입니다.
2. 60일은 맡는 구간입니다. 기능 하나를 처음부터 끝까지 맡아 내보내는 식으로, 혼자 굴려 보는 단위를 하나 줍니다. 이 구간에서 처음으로 다른 사람이 그 결과를 기다리게 됩니다.
3. 90일은 판단하는 구간입니다. 남의 코드를 리뷰하거나 다음에 무엇을 할지 제안하는 일이 여기 들어갑니다. 지시를 받아 처리하는 쪽에서 무엇을 할지 함께 정하는 쪽으로 넘어가는 지점입니다.

직군마다 도달점이 다릅니다. 세일즈라면 30일에 제품 시연을 혼자 할 수 있는 상태, 60일에 고객 미팅 단독 진행, 90일에 첫 계약으로 적습니다.

확인 시점도 문서에 넣습니다. 30일과 60일과 90일에 관리자와 30분씩 잡아 두고, 그 자리에서 문서를 함께 열어 항목을 짚습니다. 일정을 적어 두지 않으면 이 대화가 대개 90일째에 한 번으로 줄어듭니다.

넣지 않는 것도 있습니다. 평가 등급과 회사 실적 숫자입니다. 석 달 안의 매출이나 이탈률은 새로 온 사람이 혼자 움직일 수 있는 값이 아니라, 적어 두면 통제할 수 없는 것으로 판단받는 상태가 됩니다.

쓰는 사람은 관리자입니다. 합류가 정해진 뒤 프리보딩 기간에 초안을 만들어 두고, 첫 주에 본인과 함께 읽으며 조정합니다. 새로 온 사람이 직접 쓰게 하면 회사 사정을 모르는 상태에서 목표를 잡게 되고, 대개 첫 달에 하기 어려운 것을 적습니다. 그 문서는 석 달 뒤에 본인을 불리하게 만듭니다.

가장 많이 읽는 사람은 본인입니다. 매일 열지는 않지만 막혔을 때 여는 문서라, 찾기 쉬운 자리에 두는 것이 차이를 만듭니다. 버디 제도로 붙은 선임도 읽습니다. 지금 어느 구간인지 알면 무엇을 먼저 알려 줄지 판단할 수 있습니다.

관리자 쪽에서는 두 자리에서 씁니다. 구간별 확인 대화와 수습 기간 종료 판단입니다. 뒤엣것에서 이 문서가 없으면 판단이 인상으로 넘어갑니다.

조정은 정상입니다. 30일 확인 자리에서 항목의 절반쯤이 바뀌는 경우가 흔합니다. 맡기려던 기능의 일정이 밀렸거나, 생각보다 빨리 따라와 60일 항목을 앞당기는 경우입니다. 고치지 않는 문서는 첫 주에 한 번 열리고 그 뒤로 아무도 보지 않습니다. 석 달이 지나면 이 문서는 닫고, 이후의 성장은 성장 계획이 이어받습니다.

"30-60-90 초안 써 뒀으니 첫 주에 같이 보고 고칩시다."

관리자가 먼저 쓰고 본인과 맞춘다는 순서를 확인하는 말입니다.

"60일 항목이 좀 이르네요. 기능 맡는 건 70일쯤으로 옮길게요."

확인 대화에서 도달점을 조정하는 경우입니다.

"이건 평가표가 아니라 기준이에요. 못 한 항목은 왜 못 했는지만 봅니다."

점수를 매기는 문서가 아니라는 점을 분명히 하는 말입니다.

페이지덱은 개발자 두 명이 석 달 안에 나간 뒤 이 문서를 쓰기 시작했습니다. 지현이 퇴사 면담 기록에서 찾은 공통점은 처우나 업무 난도가 아니었습니다. 두 사람 모두 자기가 기대에 맞게 가고 있는지를 몰랐다고 했습니다.

태오가 개발 직군 초안을 만들었습니다. 30일에 작은 버그 하나를 운영에 올리고, 60일에 기능 하나를 맡고, 90일에 다른 사람의 코드를 리뷰한다는 세 줄이 중심이었습니다. 다음에 합류한 사람과 첫 주에 함께 읽으며 60일 항목 하나를 뒤로 옮겼고, 30일 확인 자리에서 만날 사람 목록에 두 명을 더했습니다.

수습 기간 평가표로 아는 경우가 가장 많습니다. 석 달이라는 기간이 겹치고 확인 시점도 비슷해서 그렇게 읽힙니다. 하지만 이 문서는 점수를 매기는 자리가 아니라 도달점을 미리 알려 주는 자리입니다. 평가표로 읽히면 새로 온 사람은 질문을 줄이고 문서에 적힌 항목만 처리하는 쪽으로 움직입니다. 그대로 두면 모르는 것을 묻지 않고 넘어간 채 석 달을 보내고, 정작 확인해야 했던 것은 아무도 확인하지 않습니다.

한 번 써 두면 끝나는 문서로 보는 시각도 흔합니다. 계획이라는 이름이 그렇게 읽게 만듭니다. 하지만 합류 전에 쓴 계획은 실제 일정과 어긋나는 것이 정상입니다. 맡기려던 기능이 밀리거나 반대로 진도가 빠른 일이 대개 첫 달에 생깁니다. 그대로 두면 문서가 현실과 멀어지고, 90일째에는 아무도 열지 않는 파일이 됩니다.