스타트업에서 제품 개발 총괄을 찾기 시작하는 때는 대부분 scale up 시점입니다.

이 시점에 크게 두가지 문제점이 부각됩니다. 업무 또는 서비스 안정성(프로세스, 서비스 안정화, 일정 관리 등), 조직 안정성 (채용, 조직운영, 온/오프 보딩 등) 물 들어올 때 노를 젓고 있는 상황인데 배 안의 문제로 쉬이 나가지 못하는 상황인거죠. 불신이 쌓여가고 바깥의 훈수를 듣고있자면 내부 인력들에 대한 부족함만 보입니다. 이 시점에 개발 총괄을 찾습니다. 보통의 경우 쉽게 상위 레벨의 기업 리더들을 타겟합니다.
 현재 인력 규모와 비슷하거나 더 큰 조직을 운영해보고 서비스 안정화, 규모있는 프로젝트 등을 수행한 리더분을 추천 받거나 탐색하고 열과 성을 다해 모십니다. 그렇게 서로 오랜 기간을 거쳐 심사숙고해 내린 어려운 결정임에도 영입 실수라고하는 경우를 너무 많이 들었습니다. 이후에 포지션을 없애거나 직책을 낮추어 채용하는 경우도 보았습니다. 대부분 이런 이유들 이었습니다. 채용으로 모든 문제를 풀어가려하는 경우 프로덕트 조직 외 협업 경험이 없는 경우 외부 커뮤니티 일정으로 바쁜 경우 채용, 매니징 역량이 부족한 경우 개발 문화만 잡고 있는 경우 우선순위가 잘못 설정되는 경우 비지니스 일정까지 조정해 안정성을 이유로 개발스택을 전환하였으나 비용과 장애만 증가하는 경우 등등… 물론 이런 이유들이 실패의 원인으로 볼 수 있겠지만…. 근본적인 원인은 사업의 성장에 맞춰 필요한 역량을 명확히 하지 못했고 사업의 성장 단계에 대한 경험을 갖추었는지 충분히 검증하지 못한 것일지도 모릅니다.
 예를 들어 ISMS 심사 이전이라면 현재 채용규모, 매출액 기준으로 언제 준비할지, 사내 IT 시스템을 사전에 준비를 해둘 것인지 심사 준비 때 할 것인지, 보안 기준의 어느 수준까지 맞춰갈 것인지 아니면 컨설팅을 받을지, CSIO와 같은 채용을 통해 별도의 로드맵을 마련할지, CSIO 채용은 언제가 좋을지 등과 같은 고민을 나누고 경험을 들어봐야합니다. 스타트업은 업무 범위도 그레이 존도 매우 넓습니다. 타겟하는 회사, 타이틀, 명성, 연차, 나이말고 성장에 정말 필요하고 중요한 경험이 무엇인지 구체화해두고 어떤 이슈들이 있었고 어떻게 풀어갔는지 등과 같은 경험을 깊이 들여다 본다면 실패가 줄어들 것 같습니다.