Red Flag:사업 적신호에 미리 대비할 것
스타트업에서 조직 체계를 통해 리스크를 관리하는 방식
사업 적신호
사업을 하다 보면 납기가 항상 늦어집니다. 예측하지 못했던 문제들이 끊임없이 발생하기 때문입니다. 사업 아이디어가 좋은 사람은 세상에 너무 많습니다. 하지만 아이디어를 실행에 옮기다 보면 단언컨대 생각지도 못했던 문제들이 일분일초마다 생겨납니다. 쉬운 일이 하나도 없습니다. 쉬운 일이라고는 아이디어를 떠올리고 ‘전략’을 머릿속에서 굴리는 것뿐입니다. 세상에 좋은 제품/서비스를 내놓는 것은 끊임없이 생겨나는 ‘안 될 이유’들을 헤치고 나가 ‘되게 만듦’으로써 현실이 됩니다.
하지만 사업을 주먹구구식으로 한다면 말 그대로 ‘맨땅에 헤딩’만 하게 될 것입니다. 초행길에 지도와 방위를 확인하지 않고 아무 길로나 일단 걷는다고 해서 원하는 곳에 닿을 수 있는 것은 아닙니다. 그래서 우리는 목표와 계획을 미리 세우고, 생길 수 있는 문제들을 미리 대비합니다. 목이 마를 경우를 대비해 물을 챙기고, 비가 예정된 날에는 우산을 챙깁니다. 사업도 마찬가지가 아닐까 합니다.
사업을 하다 보면 수많은 적신호를 마주합니다. 대개는 예상치 못한 것이지만, 또 알고 보면 충분히 대응할 수 있었던 것들이 많습니다. 날씨 예보만 찾아봤어도 집 밖을 나서기 전에 우산을 챙겼을 것이죠. 그러니 우리도 미리 사업 적신호를 대비해야 합니다.
문제는 나 혼자 창업하는 게 아니라 팀으로 일하는 경우입니다. 우리는 혼자 일할 수 없어서 팀원을 구합니다. 여행 전 준비물을 구매하고 챙기는 팀원, 경로를 알아보고 계획하는 팀원, 차를 운전하는 팀원 등 다양한 역할을 나눕니다. 그런데 팀이 생기면 리더가 알아차리지 못한 적신호들이 생깁니다. 차라리 혼자 했더라면 오늘 비가 올지, 안 올지 일기예보를 찾아봤겠지만, 팀원에게 준비물 챙기는 일을 맡겨버렸더니 일기예보를 확인하지 않아 우산을 챙기지 않은 문제가 발생합니다. 그 결과 팀은 쫄딱 젖거나, 혹은 여행 일정이 하루가 늦춰지게 됩니다. 이런 일이 회사에서 비일비재하게 발생합니다.
그래서 우리는 레드플래그(Red Flag), 사업 적신호를 알아차리기 위해 노력해야 하고, 관리해야 합니다.
레드플래그란?
저는 레드플래그(Red Flag)라는 개념을 ‘매니징'이라는 책에서 처음 알게 되었습니다. (해럴드 제닌 저, 권오열 옮김, 오씨이오 발행, 2019.03.10.) 책에서는 ITT의 전 CEO였던 헤럴드 제닌(Harold Geneen)의 경영 철학과 방식에 대해 소개하고 있습니다. 헤럴드 제닌은 58분기 연속 흑자라는 어마어마한 경영 실적을 가지고 있는 CEO입니다. 그야말로 경영의 대가이고, 그는 항상 레드플래그를 관리했습니다.
제가 이해한 레드플래그는 사업이나 조직에 영향을 끼칠 만한 걱정되는 요소를 의미합니다. 일종의 경고 징후나 적신호 같은 개념입니다. 예를 들면 생산 공정에 고장이 생긴 경우, 근로자들의 파업이 우려되는 경우, 경쟁사가 신제품을 출시한 경우 등등 다양한 상황이 레드플래그가 될 수 있겠습니다. 비단 회사 전체에 영향을 끼치는 요소들만 해당하는 게 아니라, 팀 단위에서는 팀원의 우울함이나 개인적인 사정, 업무 효율 저하 같은 것들도 레드플래그라고 부를 수 있을 것입니다. 자기 조직에 맞게 그 개념을 어떻게 활용하느냐가 중요하겠죠.
헤럴드 제닌은 부서장이나 임원들로부터 받는 보고서 상단에 항상 레드플래그를 메모하도록 지시했습니다. 수십 장의 보고서 사이에 짤막하게 적혀 있는 레드플래그들을 놓치게 되기 때문입니다. 혹은 해당 부서에서 위기를 숨기거나, 자기들이 직접 해결하려고 상부에 보고하지 않은 사건들이 갑자기 문제가 되어 터지는 경우가 발생하기도 합니다. 그래서 그는 무조건 레드플래그를 최상단에 적고, 정말 사소한 것까지 보고하도록 시켰습니다.
이는 스타트업이나 작은 조직에도 얼마든지 적용해볼 수 있습니다. 사실 작은 조직에서도 위와 같은 문제는 매일매일 발생합니다. 고작 10명도 안 되는 조직일지라도 실무자로부터 경영진까지 정보가 제대로 전달되지 않는 경우가 많습니다. 실무자에게 많은 권한이 위임되어 있고, 서로 커뮤니케이션이 원활하지 않으면 더더욱 그렇습니다. 그래서 우리도 레드플래그를 관리하면 좋습니다.
다음은 제가 현재 속한 조직에서 레드플래그를 관리하는 방식에 대해 소개해 드리겠습니다. 정답은 없습니다. 각자 자기 사업과 조직에 맞는 방법을 잘 찾아 나가셨으면 좋겠고, 제 경험이 도움되길 바랍니다.
조직 체계를 통한 레드 플래그 관리
< 1 > 주간 회의
저희는 매주 월요일과 금요일에 전사 인원(약 13명)이 모여 주간 회의를 진행합니다. 근래에는 재택근무 인원은 줌을 통해 실시간으로 참여합니다. 주간 회의는 여러 직무와 팀(파트)이 모두 알아야 하는 정보들을 공유하는 자리입니다. 회사 전체의 방향성이나 각 사업 파트의 진행 상황을 중심으로 진행하며, 동시에 큰 축을 맡는 것이 각 사업 파트의 레드플래그를 점검하는 것입니다.
매주 주간 회의의 식순이나 진행 내용은 바뀌지만 대체로 다음과 같이 진행합니다. (통상 30분 내외)
레드플래그 점검 : 각 파트에서 사업이나 업무에 지장을 줄 만한 걱정거리에 대해 점검
전사에 공유할 내용 : 회사 전체의 사업 방향성이나, 경영 방침이나, 제품/고객 인사이트 등 공유
이번 주의 축하할 일 : 회사에서 사소한 축하할 일을 자유롭게 적고, 자축하기
업무 원칙 체크 : 회사에서 일하는 방식을 계속 정리하고, 되새기며 업무 방법론 정렬하기
각자 공유할 내용 : 각자의 업무적 인사이트라든지, 사적인 잡담 등등 하고 싶은 말 공유하기
중요한 건 레드플래그입니다. 어떤 레드플래그는 10주가 넘게 적혀있기도 하고, 어떤 것은 1주 만에 해결되어 삭제되기도 합니다. 목표는 레드플래그를 미리 예상하여, 문제를 해결할 방법을 전사가 같이 찾아보고, 그 레드플래그를 없애버리는 것입니다.
이렇게 주간 회의에서 레드플래그를 공유하는 것은 추가로 다른 효과를 가집니다. 보통 레드플래그는 전사 혹은 다른 팀에 영향을 끼칩니다. 예를 들어 디자인 팀에서 디자인을 완료해야 개발팀에서 작업을 시작하는데, 디자인 팀이 긴급하게 처리해야 할 레드플래그가 있다고 칩시다. 이를 개발팀이 모르는 경우에는 디자인 팀을 욕하며 빨리 작업물을 달라고 재촉할 수도 있습니다. 하지만 주간 회의 때 미리 문제를 공유하고, 전사가 그 문제를 우리 회사 공통의 문제라고 인지하고 있을 때엔 위와 같은 갈등이 줄어듭니다.
뿐만 아니라 우리 조직의 문제를 투명하게 구성원 모두에게 공유하니, 회사의 문제가 더이상 불평 거리일 수 없습니다. 모두가 인지하고 있는 ‘우리 문제’가 됩니다. 스타트업들이 항상 얘기하는 게 직원들 동기부여를 말하는데 회사 방향이나 현재 상황, 당면한 문제들을 하나도 공유 안 해주면서 동기부여 운운하는 건 모순입니다. 그냥 책상 앞에서 자기 일만 하다가 퇴근하게 만들어놓고 어떻게 회사에 동기부여 하겠습니까? 그래서 주간 회의를 활용하고, 레드플래그를 관리하면 좋습니다.
< 2 > 매일 회고
저희는 모든 구성원이 매일 회고를 적습니다. 그날의 업무와 인사이트, 레드플래그를 매일 기록하는 것입니다. 그리고 이러한 회고는 모든 구성원이 언제든 접근해서 볼 수 있도록 사내 게시판에 업로드합니다. 지금은 노션(Notion)이라는 툴을 활용하고 있습니다.
이름은 ‘회고 다이어리'라고 지었습니다. 모두가 보는 게시판에 업로드하기는 하지만, 형식은 명백히 ‘다이어리’ 형식으로 작성하고 있습니다. 그래야 나 자신의 솔직한 이야기를 적을 수 있기 때문입니다. 처음에는 대부분 구성원이 글로 무언가를 쓴다는 것 자체를 어려워하고, 이를 남이 보는 곳에 올리는 걸 부담스러워했습니다. 하지만 모두가 규칙적으로 쓰기 시작하자 몇 주가 지난 뒤에는 자연스러워졌습니다.
이렇게 회고 다이어리를 적는 이유는 사람들이 레드플래그를 전사에 공유하기 부담스러워하기 때문입니다. 주간 회의 때 논의하는 레드플래그는 각 파트의 팀장이나 실무자가 회의 전에 직접 적어야 합니다. 때문에 실무자나 주니어분들은 적기가 곤란합니다. 이러한 경우를 조금이라도 줄여보고자 회고 다이어리에 양식을 만들어서 레드플래그 적는 문항을 추가했습니다.
이때는 개인적인 레드플래그까지 전부 적기를 권장합니다. 개인적으로 요즘 너무 졸리다든지, 우울하다든지, 일이 너무 많다든지 등등 자유롭게 적도록 반복해서 권장합니다. 다이어리 형식이기 때문에 그래도 종종 레드플래그들을 적어주고 있습니다. 하지만 그럼에도 불구하고 사실 레드플래그를 적는 건 개개인에게 매우 부담스러운 일입니다.
< 3 > 원온원 미팅
그래서 원온원 미팅을 주기적으로 합니다. 쉽게 말해 일대일 면담인데, 보통 한 사람당 1~2주에 한 번씩 만나서 30분~1시간 내외로 대화합니다. 이는 레드플래그를 찾아낼 수 있는 가장 효과적인 방법입니다.
특히 조직 구성원 수가 15명을 넘어가면 CEO 혼자서 모든 구성원을 케어하기가 어렵습니다. 그래서 중간 관리자를 두어서 팀장급이 각 팀원을 케어하도록 합니다. 이렇게 팀과 직급 체계가 생기면 실무단에서 경영진까지 전달되는 정보량이 급격히 줄어듭니다. 왜냐하면 상부에 보고할수록 정보가 의식적으로든 무의식적으로든 검열되고 걸러지기 때문입니다. 그래서 중간 관리자에게 원온원 미팅을 권장하여 레드플래그를 추출해내면 좋습니다.
원온원 미팅은 상사가 팀원을 가르치거나, 다그치거나, 조언하는 자리가 되어서는 제 역할을 해내기 어렵습니다. 해당 팀원이 요즘 어떻게 지내는지, 어려운 점은 없는지, 조직 차원에서 해줬으면 하는 것은 없는지 등등을 물으며 ‘서포터’의 자세로 임해야 합니다. 그렇지 않으면 팀원들은 부담을 느끼고 팀장에게 레드플래그를 이야기하지 않을 것입니다. 생각해보십시오. 팀원이 프로젝트에서 걱정되는 점(레드플래그)을 이야기했더니 팀장이 “왜 그걸 제대로 해결하지 못하냐”, “그걸 왜 이제 말하냐”는 식으로 대응하면 누가 레드플래그를 이야기하겠습니까? 그런 맥락에서 조심스럽게 접근하는 게 좋습니다.
중간 관리자를 통해 원온원 미팅을 정기적으로 하더라도 포착하지 못하는 레드플래그가 생길 수 있습니다. 그래서 더 상위 관리자나 경영진, 혹은 인사 담당자는 ‘스킵 레벨 미팅’을 진행할 수도 있습니다. 중간 관리자를 건너뛰고 실무자와 직접 만나서 원온원 미팅을 진행하는 것입니다. 제가 속한 조직도 리드(Lead) 역할이 실무자 팀원들과 원온원 미팅을 하지만, 이를 건너뛰고 저는 모든 구성원과 필요할 때마다 스킵레벨 미팅을 진행합니다.
레드플래그를 없애자
레드플래그의 목적은 레드플래그를 “없애는 것”입니다. 우리 사업의 납기를 늦출만한 요소에 미리 대응하고, 갑자기 ASAP으로 치고 들어오는 업무를 미리 준비하는 게 중요합니다. 그래서 결국엔 계획했던 납기에 맞게 사업을 진행시키고, 문제를 해결하고, 예측 불가능한 위험을 미리 대비하는 게 목적입니다.
하지만 아무리 레드플래그를 신경 쓰고, 없애고자 노력해도 잘 해결되진 않습니다. 사업이라는 게 매 순간 생각지도 못했던 사건이 발생하고, 별의별 문제들에 직면합니다. 하지만 그럼에도 불구하고 위험을 미리 감지하고, 계획을 세우고, 대비하기 위해 노력해야 할 것입니다. 왜냐하면 사업을 운에 맡길 수는 없으니까요. 최대한 예측 불가능한 요소를 줄이고 문제를 해결하는 게 필요하다고 생각합니다.
다양한 경영 방식과 노하우가 있습니다. 이를 모든 사업과 조직에 동일하게 적용하고, 동일하게 효과를 볼 수 있다는 건 거짓말일 것입니다. 각자 자기 성향에 맞는, 자기 팀원들의 업무 방식에 맞는, 조직 단계에 맞는 방법들을 만들어나가야 합니다. 거미의 사냥법을 독수리가 써먹을 수는 없는 법이니까요. 세상에 만능키는 없습니다. 레드플래그도 마찬가지입니다.
이러한 경영 스킬을 접했을 때는, 그 안의 원리가 무엇인지를 눈여겨보셔야 합니다. 큰 조직이든 작은 조직이든 마찬가지입니다. 대기업이나 실리콘밸리의 경영 스킬을 보고 그대로 적용하는 건 어리석은 짓입니다. 거미의 사냥법을 보고서, 나도 거미줄을 칠 게 아니라 덫을 만들어 설치할 생각을 하는 것이 더 원리에 접근한 방식이라고 할 수 있겠습니다. OKR이든 레드플래그든 직급 체계를 없애는 것이든 무엇이든 다 똑같습니다.
부디 이러한 내용이 사업과 조직을 운영하시는 데에 조금이나마 도움이 되었으면 좋겠습니다.
※ 이 글은 SBA(서울산업진흥원) 블로그에 유료 기고한 글입니다.
(출처)
