그때는 입사 초기여서 코드를 쓰는 것보다는 제품과 결제 도메인에 대해 배우느라 훨씬 더 많은 시간을 썼어요. IRC에서 우리 팀의 고객(즉, 개발자)이 통합 업무를 수행하는 것을 돕는 데 많은 시간을 할애했죠. 물론 기술적으로 어렵지 않은 작은 업무(버그 픽스, 작은 기능 추가, 소소한 문제에 대한 응급 조치 등)도 수행했지만 그런 업무도 사용자에게는 중요한 것이었죠. 이런 업무가 항상 엔지니어의 성장으로 이어지지는 않았어요(하지만 제 디버깅 스킬에는 도움이 됐죠. 전 이제 디버깅은 곧잘 해요). 그리고 슬랙과 티켓에 지나치게 도움을 많이 주고, 다른 팀이 우리 사용자를 위한 최적의 솔루션을 찾는 데 도움을 주는 방법으로 다른 팀이나 엔지니어와의 관계를 구축해 나갔죠. 처음 2년간은 회사에 새로 입사한 제품 엔지니어 대부분이 업무에 적응하는 것을 도왔어요. 시간이 지나면서 저는 고객을 배려하고 제품에 대해 잘 알고 있다는 평판을 얻게 됐어요(‘사용자 우선’은 여전히 제가 가장 좋아하는 스트라이프의 운영 원칙이에요).

소프트웨어 엔지니어로서 기술적인 면의 성장을 효율적으로 이뤄내지 못했던 그 시간이 사실은 시니어에서 스태프로, 스태프에서 현재의 직책으로 더 빨리 나아갈 수 있는 중요한 스킬을 배우는 시간이었다는 것을 나중에 깨달았죠(전부 다 해서 3년밖에 안 걸렸어요!). 사실 취소됐던 1년 반짜리 기술 프로젝트가 제 경력에 그다지 큰 오점이 되지 않았던 것은 처음 몇 년간 구축해온 관계 덕분이라고 확신해요.

저는 스트라이프 레이다(radar)⁸와 스트라이프 엘리먼트(elements)⁹의 첫 버전을 개발하면서 기술적인 기반을 천천히, 조심스럽게 개발해 나갔어요. 제가 가졌던 기술적인 격차를 생각하고 제가 참여했던 프로젝트를 위해 그 격차를 줄이고, 프로젝트를 통해 더 도전적인 과제를 스스로에게 부여하면서 자연스럽게 스킬을 배우고 실습할 수 있었다고 굳게 믿고 있습니다. 회사 전반에 걸친 인맥, 사용자 위주의 사고, 제품에 대한 더 깊은 이해 등 소프트 스킬을 배우는 데 더 오랜 시간이 걸렸지만, 결국 제가 기술적 기반을 다진 후에 스태프 엔지니어로의 성장을 가속화하는 데 도움이 됐어요.