<라인 개발자 김영재님의 페이스북 코멘트> 속도감 있는 팀과 없는 팀의 차이 중 하나라면, 속도감 없는 팀은 정례를 '기다린다' 정례 때까지 별다른 검토없이 가만히 있다. 이 흐름을 바꾸려는게 요즘 내가 하는 일이다. 꼭 정례 때에만 논의해야 한다는 암묵적인 룰이 만들어진 셈인데. 그래서 내가 정례를 안 좋아한다. 업무 방식과 속도를 정례 템포에 길들인다. 정례를 최소화하면 평소에 내용을 미리 체크하고 정례가 올 때는 실시간 대화가 필요한 논의만 할 수 있다. 다시 말해, 비동기 메시징과 동기 메시징을 점차 구분지을 수 있게 된다. 미리 확인해야 하는건 Slack이든 메일이든 몇 번 물어보며 처리하고, 정례 주제는 기본적인 가/불 체크는 끝난 상태라서 선택지만 남는다. 상황 공유도 체크하는 동안 이미 되어있다. 그렇지 않고 정례까지 기다리면 토픽 공유에 절반 이상의 시간을 쓰고, 회의 후의 액션이 가/불 체크가 된다. 정례에 12명이 참여한다면, 가/불 정도를 결정하는 사람은 3명 정도다. 정례까지 모두가 기다려야만 하는 사안은 생각보다 적다. 나는 '맥락을 펴바른다'는 표현을 쓰는데, 단점도 있다. (없을리가) 단점이라면, 이슈를 체크하는 누군가는 흐르는 정보 속에서 주요 맥락을 잘 낚아서 정리해야 한다. 맥락의 흐름에서 비껴있는 사람이나 메시지 하나를 놓치는 경우는 스텝이 좀 꼬이곤 한다. 그리고 가/불 체크에 합의보다는 주체적인 판단을 하기도 하므로 좋은 선택지가 사라질 가능성도 있다. 하지만 전체적으로 속도감이 높아지면 오해도 빨리 풀리고, 판단력도 날카로워지고, 잦은 신호에 노출되므로 합의가 굳이 필요없는 고맥락 집단으로 발전한다. (써놓고보니 너무 당연한 말 같은데. 이런 노력 따위 왜 해야하나 싶은 허망함이 느껴질 때도 있다니깐.. ) ========================================== 이게 생각보다 굉장히 중요한 얘기입니다. 제품 개발팀의 어떤 커뮤니케이션은 동기적으로 되어야 하고, 반대로 어떤 커뮤니케이션은 비동기적으로 되어야 하거든요. 이렇게 될 때, 중요한 포인트는 비동기적으로 되어도 상관 없는 커뮤니케이션들을 동기 커뮤니케이션으로 가져 오지 않는 것입니다. 이렇게 되기 어려운 이유가 뭐 여러가지 있겠지만.. 그 중 하나는 의사결정 권한에 대한 명확한 위임이 안 되어 있을 경우이거나, 혹은 구성원이 내가 스스로 이렇게 결정을 내리고, 액션을 했다가 실패하면 그 책임이 나에게 주어질 것이고..그 책임을 지는 행위가 두렵다고 느끼는(즉 심리적 안전감이 부족할 경우) 경우 잘 안 되기도 합니다. 정기 미팅 혹은 동기화된 커뮤니케이션에서 이해관계자 다 모아놓고, 얘기해야 안전하다고 느끼기 때문이죠. -_-;; 이런 부분들에 대해서 더 스터디해봐도 좋을 것 같네요. :)