<div id="readability-page-1" class="page"><div><h2 id="d121">온보딩 시기에 나는 ‘무엇’ 을 해야할까?</h2>어쨌든 입사하면 나를 맞이하는 누군가는 있다. 팀의 리더, 팀에 먼저 입사해서 일하고 있던 동료, 대표 등 나에게 무언가를 기대한 사람이 있기 마련이다. 그 사람과의 대화를 통해 나에게 기대하는 바를 1차적으로 확인한다.그렇게 나에 대한 기대치의 큰 맥락을 확인했다면, 수습 기간의 목표를 스스로 구체화해 본다. 팀이 신규 입사자의 구체적인 목표를 설정해 주지 않더라도, 나에게는 팀의 일에 대해 알 수 있는 많은 재료가 있다. 입사 지원 시 JD도, 팀의 협업 도구를 탐색하며 얻게 되는 정보도 모두 해당된다.목표 구체화가 끝이 아니라, 이 구체화한 목표를 들고 리더를 찾아가서 공유하고 피드백을 받는다. 이로써 내가 온보딩 기간 혹은 수습 기간에 하게 될 일에 대해 나와 회사가 전혀 다른 방향을 보게 될 일은 피할 수 있다.이전에 작성했던 <a href="https://medium.com/@mjspring/%EB%82%98%EC%99%80-%ED%9A%8C%EC%82%AC-%EC%96%91%EB%B0%A9%ED%96%A5-%EA%B8%B0%EB%8C%80%EC%B9%98-%EC%A1%B0%EC%A0%88%ED%95%98%EA%B8%B0-bc2edf7854c7" rel="noopener">나와 회사, 양방향 기대치 조절하기</a> 글을 참고해도 좋겠다.<h2 id="7c6a">온보딩 시기에 나는 ‘어떻게’ 해야할까?</h2>무엇을 하게 될지는 정의했으니, 그걸 어떻게 하는지에 대해서도 고민이 필요하다. 나는 크게 2가지 행동 기준을 갖고 이를 반복한다.<ol><li id="9a7c">큰 그림에서 출발하여 세부 사항에 도달하기. 아주 작은 이슈 딱 1개를 해결해보기.</li><li id="4da9">이 과정에서 수시로 문서화하고 수시로 공유하기.</li></ol>나는 개발자이기 때문에 보통은 회사가 제공하는 전체 서비스의 큰 그림을 먼저 그려본다. 어떤 사용자들이 있고, 그 사용자들의 요청이 어떤 통신 프로토콜로 내부 시스템에 도달하는지 파악할 수 있는 만큼 해본다. 여기서 핵심은, 내가 실제로 작업하고 기여하게 될 시스템 주변을 이해하는 것이다.그렇게 전체 그림과 내가 기여할 시스템의 주변을 이해하게 됐다면, 팀의 백로그에 쌓여있는 이슈 중 난이도 혹은 변경 크기가 아주 작은 이슈를 딱 1개만 해결해본다. 이 작업을 통해 팀이 담당하는 시스템의 맥락을 대단히 깊게 파악하는 건 아니더라도, 팀이 일을 하는 프로세스를 경험해 본다는 데 의미가 있다.그리고 가장 중요한 건, 이 과정에서의 결과물을 계속 기록하고 자꾸 공유하는 것이다. 팀에 이제 막 입사한 사람이 애쓰고 공유하는 것들을 그냥 지나치지는 않을 것이다. 적어도 한 사람은 더 많은 정보를 주려고 하거나, 잘못된 정보를 교정해 주거나, 작은 공감이라도 보낼 것이다. 그리고, 그 한 사람이 두 사람이 되고 결국 팀이 되는 길은 지속적인 공유가 답이다.<figure><figcaption>셀프 온보딩 할 때 노트에 끄적이던 것들</figcaption></figure></div><div>결국, 이러한 셀프 온보딩 과정을 통해 얻게 되는 것은 내가 기여하게 될 시스템에 대한 막연함 제거, 팀이 일을 하는 프로세스 선경험, 피드백 과정을 통해 누구에게 어떤 도움을 받을 수 있는지 파악할 수 있다는 점이다.새로운 조직에 입사하자마자 엄청난 기여를 하겠다는 각오보다는, 지속적 기여를 위해 프로세스와 사람을 파악하는 시간으로 온보딩 시기를 활용하는 게 더 현명하다고 생각한다.나는 지금까지 야생 온보딩에 가까웠지만, 현재 리드하고 있는 팀에서는 신규 입사자들이 온보딩에 대한 부담을 필요 이상으로 느끼게 하고 싶지 않았다 😂 그래서내 경험을 기반으로 신규 입사자가 합류하기 전 미리 준비하는 것들이 있다. 바로 ‘온보딩 한 달 계획’ 과 ‘온보딩 일지’, ‘한 달 동안 주 2회 온보딩 세션 일정 계획’ 이다. 이를 통해 신규 입사자가 수습 기간 동안 본인이 달성해야 할 목표에 대해 방황하지 않았으면 하고, 자연스럽게 공유하고 질문할 수 있는 장치를 적극 활용했으면 한다.추가로, 입사 후 온보딩 시기는 질문/도움에 대한 채널을 확보하고 안정감을 얻기에 너무나 완벽한 시기라는 점을 알리고 싶다. 신규 입사자에게 온보딩 시기는 ‘눈치 보지 않고 질문할 수 있는 시기’, ‘실수가 없으면 오히려 이상한 시기’, ‘도움이 가장 절실한 시기’, ‘아무 말이나 의견을 내더라도 대부분 허용되는 시기’ 이지 않을까? 입사하자마자 알아서 척척 성과를 내길 바라는 사람은 없을 것이다. 그러니 도움 없이도 잘 해내는 ‘척’ 하지 않고 이 소중한 시기를 누렸으면 좋겠다.</div></div>

Stories by Mijeong (Rachel) on Medium

이직을 자주 한 편이다 보니 다양한 온보딩 환경을 자주 경험했다. 하지만 온보딩 대상자가 기대하는 수준의 체계를 갖춘 회사는 거의 없었다. 회사 규모와 상관없이 팀 빌딩 초기에 합류해서 체계를 기대하기 어렵거나, 어느 정도 안정화된 조직같은데 오랜만의 신규 입사자라 최신화가 안되어 있다거나, 회사가 의도적으로 야생 온보딩을 기대하거나 등등 다양한 이유가 가능하다.
그래서 입사 전 기쁨의 총량이 컸던 것에 비해, 입사 직후에 허덕이며 괴로움에 먹혀버린 경험이 종종 있었다. 이런 경험들이 누적되며 온보딩 시기에 나 스스로 할 수 있는 것들에 대한 생각을 많이 해왔다.
온보딩 시기에 나는 ‘무엇’ 을 해야할까?
어쨌든 입사하면 나를 맞이하는 누군가는 있다. 팀의 리더, 팀에 먼저 입사해서 일하고 있던 동료, 대표 등 나에게 무언가를 기대한 사람이 있기 마련이다. 그 사람과의 대화를 통해 나에게 기대하는 바를 1차적으로 확인한다.
그렇게 나에 대한 기대치의 큰 맥락을 확인했다면, 수습 기간의 목표를 스스로 구체화해 본다. 팀이 신규 입사자의 구체적인 목표를 설정해 주지 않더라도, 나에게는 팀의 일에 대해 알 수 있는 많은 재료가 있다. 입사 지원 시 JD도, 팀의 협업 도구를 탐색하며 얻게 되는 정보도 모두 해당된다.
목표 구체화가 끝이 아니라, 이 구체화한 목표를 들고 리더를 찾아가서 공유하고 피드백을 받는다. 이로써 내가 온보딩 기간 혹은 수습 기간에 하게 될 일에 대해 나와 회사가 전혀 다른 방향을 보게 될 일은 피할 수 있다.
이전에 작성했던 나와 회사, 양방향 기대치 조절하기 글을 참고해도 좋겠다.
온보딩 시기에 나는 ‘어떻게’ 해야할까?
무엇을 하게 될지는 정의했으니, 그걸 어떻게 하는지에 대해서도 고민이 필요하다. 나는 크게 2가지 행동 기준을 갖고 이를 반복한다.
큰 그림에서 출발하여 세부 사항에 도달하기. 아주 작은 이슈 딱 1개를 해결해보기.
이 과정에서 수시로 문서화하고 수시로 공유하기.
나는 개발자이기 때문에 보통은 회사가 제공하는 전체 서비스의 큰 그림을 먼저 그려본다. 어떤 사용자들이 있고, 그 사용자들의 요청이 어떤 통신 프로토콜로 내부 시스템에 도달하는지 파악할 수 있는 만큼 해본다. 여기서 핵심은, 내가 실제로 작업하고 기여하게 될 시스템 주변을 이해하는 것이다.
그렇게 전체 그림과 내가 기여할 시스템의 주변을 이해하게 됐다면, 팀의 백로그에 쌓여있는 이슈 중 난이도 혹은 변경 크기가 아주 작은 이슈를 딱 1개만 해결해본다. 이 작업을 통해 팀이 담당하는 시스템의 맥락을 대단히 깊게 파악하는 건 아니더라도, 팀이 일을 하는 프로세스를 경험해 본다는 데 의미가 있다.
그리고 가장 중요한 건, 이 과정에서의 결과물을 계속 기록하고 자꾸 공유하는 것이다. 팀에 이제 막 입사한 사람이 애쓰고 공유하는 것들을 그냥 지나치지는 않을 것이다. 적어도 한 사람은 더 많은 정보를 주려고 하거나, 잘못된 정보를 교정해 주거나, 작은 공감이라도 보낼 것이다. 그리고, 그 한 사람이 두 사람이 되고 결국 팀이 되는 길은 지속적인 공유가 답이다.
결국, 이러한 셀프 온보딩 과정을 통해 얻게 되는 것은 내가 기여하게 될 시스템에 대한 막연함 제거, 팀이 일을 하는 프로세스 선경험, 피드백 과정을 통해 누구에게 어떤 도움을 받을 수 있는지 파악할 수 있다는 점이다.
새로운 조직에 입사하자마자 엄청난 기여를 하겠다는 각오보다는, 지속적 기여를 위해 프로세스와 사람을 파악하는 시간으로 온보딩 시기를 활용하는 게 더 현명하다고 생각한다.
나는 지금까지 야생 온보딩에 가까웠지만, 현재 리드하고 있는 팀에서는 신규 입사자들이 온보딩에 대한 부담을 필요 이상으로 느끼게 하고 싶지 않았다 😂 그래서내 경험을 기반으로 신규 입사자가 합류하기 전 미리 준비하는 것들이 있다. 바로 ‘온보딩 한 달 계획’ 과 ‘온보딩 일지’, ‘한 달 동안 주 2회 온보딩 세션 일정 계획’ 이다. 이를 통해 신규 입사자가 수습 기간 동안 본인이 달성해야 할 목표에 대해 방황하지 않았으면 하고, 자연스럽게 공유하고 질문할 수 있는 장치를 적극 활용했으면 한다.
추가로, 입사 후 온보딩 시기는 질문/도움에 대한 채널을 확보하고 안정감을 얻기에 너무나 완벽한 시기라는 점을 알리고 싶다. 신규 입사자에게 온보딩 시기는 ‘눈치 보지 않고 질문할 수 있는 시기’, ‘실수가 없으면 오히려 이상한 시기’, ‘도움이 가장 절실한 시기’, ‘아무 말이나 의견을 내더라도 대부분 허용되는 시기’ 이지 않을까? 입사하자마자 알아서 척척 성과를 내길 바라는 사람은 없을 것이다. 그러니 도움 없이도 잘 해내는 ‘척’ 하지 않고 이 소중한 시기를 누렸으면 좋겠다.

셀프 온보딩, 스스로 적응하기

댓글