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