스타트업에서 회의는 어느 정도 해야 하는가?
조직의 역량에 따라 다르다!
해당 스타트업의 역량에 달렸음!
능력 좋은 인원이 모여있다면, 회의는 줄어들고... 능력 없는 인원이 모여있다면.. 회의는 보통 늘어나거나, 의사소통에 비용을 많이 지불함.
개발 방법론과 조직의 역량과의 궁합이 가장 중요한 IT스타트업에서 적절한 개발 문서의 수준은 바로, 의사소통에 딱 필요한 수준까지만 작성하는 것이 최선이고, 그 수준을 찾기 위해서 계속 사람과의 작업 속도나 품질에 대한 기준을 일치하게 하는 일련의 작업들은 매우 빈번하게 동작해야 합니다.
일단. 프로세스나 적당한 프로세스, 의미 있는 품질에 대한 생각은 크게 중요하지 않습니다. 비즈니스 모델이 동작하고 있는지, 수익화가 가능한 모델의 의미를 찾았는지가 더 중요합니다. 기업은 비즈니스 모델이 의미 있게 동작할 때까지 끊임없이 변화되고 변경됩니다. 이때에는 조직원의 변동, 모델의 변동이 극심합니다. 이 시기에 사실 회의의 숫자나 질은 그다지 중요하지 않습니다. 대부분은, 특정인, 특히. 대표의 생각을 중심으로 업무 지시나 오더, 도달 가능한 지표나 KPI 등이 설정됩니다.
그리고, 그것을 달성하기 위한 내부적인 움직임이 더 빈번하게 움직여야죠. 각 단계별로 '회의'는 너무 많아도 문제이고, 너무 적어도 문제입니다. 회의 시간을 정하는 가장 좋은 방법은 무엇일까요?
첫째. 비즈니스의 속도를 생각하라.
가설과 증명을 얻을 수 있는 시간대가 비즈니스마다 다릅니다. 오전에 가동해서 오후에 얻을 수 있는 가설이 있고, 한 달 후에 결과가 나오기도 합니다. 적당한 비즈니스의 속도에 따라서 회의가 구성되어야 합니다.
중요한 것은 하나의 단계나 스프린트가 동작한 이후에 리뷰나 검토, 반성, 아이디어를 얻을 수 있는 시간이 배분되면 됩니다. 내 업무나 비즈니스의 한 번은 어떤 속도로 진행되는 것인지 알아야 합니다.
둘째. 주간회의와 일간 회의는 필요한가?
한주 단위로 업무가 발생하는 경우가 아니라면, 크게 필요하지는 않습니다. 다만, 근태가 자유롭고 협업을 자주해야 하는 스타트업의 특성이 있다면, 이를 파악하기 위해서 주간회의는 필요합니다.
또한, 일간 회의는 최소화할 수 있지만, 일간 회의가 많아지거나, 길어진다면... 팀장이나 의사결정을 하는 관리자의 능력을 의심해 보는 것도 좋습니다. 대부분 회의를 줄이기 위해서 애를 쓰고 있습니다.
셋째. 회의를 하기 위한 적정한 인원수는?
너무 많은 사람들이 모여봐야, 이야기를 나누는 사람들은 제한적입니다. 의사소통이 가능한 사람으로 모여야 하고, 의사결정이 가능해야 합니다. 5명 이내로 줄이고, 의사결정을 할 수 있는 사람들만 모여야 합니다.
아무 말 없이 듣고만 있는 사람이라면, 회의에서 빼고, 문서나 결정 난 내용만 이야기해주면 됩니다.
그들은 어차피, 토론보다는 험담이나 불만을 나중에 이야기합니다. 그냥, 회의에서 제거하고. 해당 조직원에서도 제거하는 것이 가장 효과적입니다.
넷째. 회의에 결과가 안 난다면?
일단, 회의는 잘못 열린 것입니다. 모여서 잡담을 한 것이라고 체크하고 나중에 회의에 대한 회고가 필요합니다.
다섯째. 권한 위임에 따라서 회의의 숫자는 증가한다.
대표의 권한이 C레벨에게 위임되고, 팀장까지 위임되면 회의가 발생하는 빈도나 의사소통의 속도가 빨라집니다. 하지만, 위임이 극히 제한적이거나 없다면, 회의는 빈번하게 진행되는 것이 당연합니다. 회의가 늘어난다면, 위임을 하셔야 합니다. 아니면, 조직을 더 두거나, 인원 변동이 필요합니다.
여섯째. 기업에서 업무와 회의의 비중은 어느 정도가 좋을까요?
대부분의 대표이사나 경영진에 해당하는 C레벨들은 업무의 80% 이상을 회의를 통해서 일정을 소진합니다. 직접적인 회의, 간접적인 의사 전달, 실시간 채널을 통한 지시와 검토, 전자결재나 이메일을 통한 소통까지 모두 계산한다면 그러합니다.
다만, 실제 일을 해야 하는 팀장이거나 팀원의 시간에서 회의 시간은 정말 최소가 되어야 합니다.
하지만, 실제 대다수의 업무들은 팀원이 타 팀의 부서원과의 회의도 발생하기 때문에 실제 업무의 50% 정도를 대부분 회의에 소진합니다. ( 검토, 전자결재, 이메일, 문서작성 등을 포함한다면 말이죠. )
개발자가 40% 이상 책상에 앉아서 개발이 가능하게 하는 것이 정말 어렵습니다.
일곱째. 슬랙과 같은 실시간 도구가 다 어울리는 것은 아니다.
은근, 매시간, 매분 울려대는 슬랙 메시지는 작업자들의 맥을 끊어 놓는 나쁜 수단입니다. 차라리, 개발자들은 적절한 회의와 규칙적인 회의 시간에 호출하는 것이 좋습니다.
다만, 슬랙은 기획자나 운영과 같은 영역에 있는 사람들에게는 매우 효과적입니다.
작은 스타트업의 개발자가 슬랙에 바로 반응하는 이유는 그들이 서비스 운영을 담당해서 업무의 하나로 여기는 것이지, 원래 개발자가 더 효과적으로 작업하려면 슬랙과 같은 실시간 채널에서 그를 제거하는 것이 좋습니다.
여덟째. 개발자의 시각화를 비개발자 영역까지 확장해야 하는가?
이는 선택의 몫입니다. 개발자의 작업 내용을 시각화하는 것에는 많은 리소스가 투입됩니다. 이 리소스를 감당할 자신이 있으면, 하는 것이죠. 대기업의 경우에는 이 시각화에 많은 것을 투자합니다.
---------
그렇다면, 어느 때에 회의를 늘려야 하고, 어느 때에 회의를 줄이거나 방식을 조정해야 할까요? 일단 다음의 기준으로 회의가 늘어나야 하는 것을 판단하는 것이 좋습니다.
첫째. 조직의 인원이 증가되는 속도가 빨라지고, 인원 충원이 많이 증가할 경우에는 회의를 늘려야 함.
둘째. 조직이 취급하는 비즈니스의 범위나 서비스의 개수가 증가할 경우에도 회의를 늘려야 함.
셋째. 업무의 특성이나 조직의 불 완정 때문에 인원의 변동이 심한 경우에도 역시 회의를 늘려야 함.
넷째. 구체적이지 못한 비즈니스 모델의 경우에는 실제 작업보다 가설과 검증을 위한 회의를 늘려야 함.
다섯째. 불완전한 기술구조나 실험적인 코드를 기반으로 작업하는 경우에도 역시 회의를 늘려야 함.
여섯째. 책임자가 변경되거나, 책임자가 불안해하면 회의가 자연스럽게 늘어남.
일곱째. 관리자의 역량이 떨어지거나, 대표의 역량이 떨어지게 되면 역시 자연스럽게 회의가 늘어남.
그럼. 회의가 줄어들거나, 줄이는 것은 어떻게 해야 가능할까요?
리더의 판단이 가장 중요합니다.
적절한 회의의 숫자와 회의의 진행은 그들의 몫이죠.
