선택과 집중의 중요성, 번아웃을 조심하자
스타트업은 '마라톤', 애자일이 필요한 이유
대부분의 초보 스타트업들이 시행착오를 겪는 부분 중에 하나인데,
의욕이 너무 앞선 나머지 감당할 수 없는 'capa'의 새로운 일을 벌리는데,
업무 프로세스 / 인력이 잘 셋업된 상태에서 일을 시작하는게 아니다보니.....
기존에 돌아가던 업무에서 문제가 생길수도 있고 / 때로는 누군가의 업무 공백 - 딜레이 등으로 인해
특정 기간에 일이 병목 현상으로 몰리고, 도미노 현상으로 줄줄이 연쇄 도산이 발생한다.
(= 일정이 밀리는 경우)
이 경우, (대체로 일을 열심히 하는 순서대로...) 보통 10명 중에 6~7명은 번아웃에 걸리고....
이 번아웃에 한번 걸리고 나면 그 다음부터는 'NO'를 말하는것에 대해서 기준치가 더 낮아져서
결과적으로는 앞으로의 장기적인 관점에서 업무 생산성을 저해한다고 생각한다.
내 지론은 스타트업은 단거리 스프린트라기보다는 장기적인 마라톤을 뛰어야 한다고 생각하고,
85~90% 정도의 페이스를 계속 유지하는게, 120% - 60%를 널뛰기하는 생산성보다 훨씬 낫다.
> 때로는 100%를 달려할 수 있지만, 그래도 절대 120% 상황은 만들지 말자. 잃는게 더 크다.
이를 위해서는 대략 두가지 정도의 해결책이 있는데,
1. 좋은 산출물을 뽑아낼 수 있는 업무 프로세스를 정의하고, 'C레벨'도 이를 반드시 원칙으로 지킨다.
1-1. 처리에 예외를 두려면, '지시'가 아닌 '요청'을 통해 사전 동의를 받고서 해결한다.
> 내가 조인하고 개발팀 리드를 맡은 뒤부터, 개발팀의 업무 방식을 '스프린트'주기로 바꾸면서
실제로 개발할 output에 대한 최종 퀀티티/퀄리티 컨트롤은 개발팀에게 권한을 위임했다.
(launch due date가 명확한 외부 제휴 / 프로모션 등만 제외하다면...)
그럼에도 불구하고, biz의 여러가지 급박한 요구사항 변경에도 잘 대응하며 큰 문제없이 잘 돌아가고 있다.
2. (!중요) 전사적 업무 우선순위를 잘 정의 해둔 상태에서
당겨진 일정 or 갑작스럽게 새로운 일감을 집어 넣을때는 반드시 이 일에 대한 우선순위와 함께 전달하고,
2-1. 이로 인해 다른 낮은 우선순위 업무 일정이 밀리는 것에 대한 암묵적 동의/의사 결정자로서 책임을 진다.
2-2. ** 이 책임을 실무자에게 전가하지 않는다.
> 이 부분은 '팀 리더/시니어 PM'에게 업무를 할당할 'C레벨' 임원이 참고하면 좋은 내용이다.
항상 급한일은 산재해 있고, 어제는 급했는데 하루 지나고 보면 아니더라... 인 경우도 많다.
그리고 새 일을 계속 밀어넣었는데, 원래 언제까지 되어야했던 일이 안되어있는건 어찌보면 당연한 거다....
(만약에 누군가가 이를 기대에 충족한다면, 포상을 주고 승진을 시켜야한다.)
언제까지 될꺼라 기대했고 계획을 세웠는데 안되어서 실망하기보다는, 애초에 capa에 한계가 있음을 인정하고
투자를 받아서 인력을 충원하거나, 임팩트가 덜 중요한걸 최대한 포기하거나, 가장 중요한것에 집중해야 한다.
이 방식을 통해, 실무자 capa의 한도가 넘치지 않게 적절히 일의 총량을 관리하고
혹은 단기간에 번아웃이 날 만큼 달렸다면 반나절/하루 정도의 특별 휴가를 부여하는 것도 하나의 방법이겠다.
(중요!)막상 그렇다고 모든걸 실무자에게 위임하면, 현실적으로 달성 가능한 수준의 목표를 정의하고
'도전'을 하지 않는 문제가 있어서 도전적인 업무 목표 정의는 경영진이 해야하는게 맞다고 생각한다.
여기까지가 본론이었음.
아래는 아래는 약간 긴 회고에 가까운 과거의 상황에 대한 기록인데, 내 브런치에서 심심찮게 나오는
자아 성찰, 개인적으로도 아쉬움과 반성과 후회를 담은 전전전 직장 까기...편이다. 읽기를 생략하셔도 무방
(전전전전 직장, 전전 직장, 전 직장도 당연히 문제는 참 많았는데도 굳이 전전전 직장이 자주 언급되는 이유는 초기 스타트업이었어서다.)
-> 과거 내 첫 스타트업 시절은, 사실 tech팀은 전반적인 역량이 아주 뛰어났고, 열정도 넘쳤는데,
아래의 문제가 있었다. 그래서 나는 이를 교훈삼아 이러한 실패가 또 나오지는 않게끔 할 것이다.
0. 실무 product 팀의 문제는 아니었다. 사용성 높은 디자인에 대한 고민, 사용자의 목소리는 열심히 듣던 편.
> 오히려 헤비 유저의 목소리에 너무 매몰되서, 그 뒤에 숨은 진짜 고객의 needs를 몰랐던게 더 컸다.
1. C레벨에서 근본적인 killer feature 의사결정이 잘못 되었던 (포지셔닝 전략 없음, 큰 그림을 못 그린)
2. 리소스 대비 효과가 안나오는 일에 리소스 120% 몰빵 올인했던.
(한달간 집에 3~4일 들어간 적도 있었다. 그러나 비즈니스 임팩트만 놓고 보면, 완전히 실패했다.)
3. 내부에서 부터 나온, 데이터 기반의 growth에 대한 목소리가 많았는데, top down으로 대형 프로젝트를 밀어붙였고 이게 연속으로 2~3번 실패해버려서, 초기부터 헌신했던 a급 이상의 개발자를 꽤 많이 잃었음
4. 그럼에도 불구하고 왜 OOO에는 이게 되는데, 우리는 안되냐는 불만을 재기하던 적이 있었는데, 이게 매우 사기를 저하했다. 그리고 이게 당시엔 aws가 보급화된 상황도 아니여서 infra에 base를 둔 기능이라면 (머신러닝, 빅데이터 분석, 레이턴시, 저장 용량, cdn, 캐시, 최적화 등) 더더욱 답이 없는 문제였다.
(!!!절대로 해서는 안된다 이런말... 네이버나 구글이 되고 싶다면 A급 개발자를 한 천명 정도 뽑아달라.)
5. 개발자를 3명 뽑아봐야 1명일때 퍼포먼스의 2배가 겨우 나오고, 이게 10명이 되어도 3명일때의 3배가 안될꺼다. 즉 10명이 되어야 1명일때의 4~4.5배 정도? 그것도 후속 합류자들이 모두 B급 이상일때나 가능한 얘기라.... 해서 개발자를 뽑는 것에 대해서는 단위 효율을 정량적으로 생각하면 손해가 크기 때문에....
집중할 일에 신중 또 신중을 가하는게 아주 아주 중요한 biz 리더의 업무 중 하나이다.
> 그리고 두번의 프로젝트에서 IC로서 한번에 큰 피쳐를 런칭하는 것에 대해서 당시 경영진의 판단을 신뢰했으나 결과적 실패를 겪으면서 이후로는 제대로 된 큰 전략적 방향을 세운 다음에, 작게 시작해서 조금씩 더 방법으로 점진적으로 프로젝트를 키우는 애자일에 눈을 뜨게되고..
다가올 4번째 프로젝트에는 메인 PM을 맡길 바랬으나 경영진에 믿음을 주지 못했는지... 새로 영입된 검증된 인재분이 프로젝트 리딩을 맡으셨다. 그리고 전략적 접근이 부족한걸 인지했던건지, 서울에서 불법 판정을 받아서 실업자가 되어버린 - 아주 유명한 어떤 회사의 한국 지사장(?)을 CSO로도 영입했던걸 뉴스로 보았다. 그리고 그분은 10개월인가 만에 빠른 gg
하여간에 나는 3번째 큰 프로젝트인 '글로벌 진출을 위한 인프라 셋업 및 1차 소프트 런칭'을, 백엔드 서버 개발자 + 서브 PM & QA인 IC로서 마무리하며 퇴직을 했다. 그 뒤에 또 도전했던 4번째 큰 프로젝트인 러닝 카드에도 능력자들이 정말 사운을 걸고 올인한 것 같은데 성과는 어땠는지 말을 아껴본다.
> 4번째 이후에는 방향이 약간 그로스 기반의 린한 성장으로 바뀐 것 같다고 느꼈다. 4번째 프로젝트를 전후로 내 생각에는 장기적인 관점에서 회사의 발전을 저해하던 어떤 분이 퇴사를 하신 것도 영향이 컸을 것 같다.
> 아직 남아있는 초기 멤버들은 오래전부터 알았지만, 다들 열정적이고 뛰어나고 존경할만한 동료들이었다.
이를 보면 높은 직급의 단 한명의 문제가 얼마나 많은 풍파를 가져온지를 알 수 있다.
