1. 협력
정말 뛰어난 개발자는 실력뿐만아니라 협력할 수 있는 능력을 가진 사람이다.
하지만 협력의 중요성이 강조된지는 그리 오래된 일이 아니다.
그렇기 때문에 협력해서 일을 한다고 할 때, 협력을 단지 일을 나눠서 하는 것으로 잘못 이해하고 있거나 협력이 오히려 효율성을 떨어뜨린다고 생각하는 사람도 여전히 존재한다.
그렇다면 협력이 왜 필요한 것일까? 그냥 혼자서 코딩만 하면 안되는 걸까?
결론부터 말하자면 협력을 통해 창발적 추상화가 일어날 수 있기 때문에 협력이 필요하다.
추상화의 중요성은 개발을 하는 사람이라면 누구나 이해하고 있을 것이다.
서로 다른 사람이 함께 일을 하게 되면 추상화를 통해 서로를 연결해줄 다리를 만들게 되고, 이러한 추상화 속에서 새로운 발견이 나오기 때문에 협력이 필요하다.
2. 신뢰
서로를 신뢰하는 조직이 커뮤니케이션 효율이나 생산성이 높다는 연구 결과는 어디서든 한 번쯤은 들어 보았을 것이다.
신뢰를 쌓으려면 투명하게 공유하고, 상호작용이 필요한데, 공유 조건에 따라서는 오히려 신뢰가 깎이는 경우도 발생한다.
연구에서는 공유 조건을 하나만 공유, 최고의 하나만 공유, 여러개를 공유하도록 했는데, 이 중에서 여러개를 동시에 공유(복수 공유)했을 때의 상대방에 대한 신뢰도가 가장 높았다.
결국 단순히 공유만 한다고 신뢰가 쌓이는 것이 아니므로, 어떻게 복수 공유를 하도록 할 것인가에 대한 진지한 고민이 필요하다.
3. 사람
애자일같은 새로운 개념을 조직에 도입하는 경우, 관리자의 위치에서 도입을 주도하면 쉬울 것이라 생각하기 쉽다.
하지만 도입을 위해 필요한 것은 결국 사람을 설득해 따르게 하는 것이고, 이는 지위고하나 객관적 데이터의 유무와는 관계 없이 상대방에 대한 이해를 바탕으로 수행되어야 한다.
결정하는 사람도 인간인만큼 의사결정에 감정이나 주관이 개입될 수밖에 없는데, 이를 하향식으로 강제하거나 객관적 데이터만으로 설득이 될 것이라 생각하는 것은 환상에 불과하다.
4. 문제 해결 과정
흔히 전문가는 문제를 해결할 때 탑다운(추상->구체) 방식을 사용한다고 생각한다.
대다수의 조직에서도 탑다운 방식을 적용해 추상 층위에 따라 팀을 나누고 팀 간의 바통 터치가 탑다운으로 이루어진다.
하지만 이러한 방식은 잘 정의된 문제를 해결할 때는 효율적이지만, 현실에 존재하는 잘 정의되지 않은 문제를 해결할 때는 전문가도 바텀업 방식을 섞어 쓴다.
이렇게 추상과 구체를 쉽게 왔다갔다 할 수 있는 전문가가 조직에 많으면 좋겠지만, 전문가 한 명을 구하는 것도 현실적으로 어렵다.
그렇다면 취할 수 있는 방법은 조직의 의사소통 방식을 바꿔서 각 층위간에 자유롭고 빈번하게 소통할 수 있도록 해야 한다.
5. 팀
좋은 팀이란 무엇일까? 전문가들로만 구성된 팀이면 좋은 팀일까?
연구 결과에 따르면 전문가로만 구성된 팀도 협력 계획 없이는 비전문가만 있는 팀보다도 못한 결과를 낸다고 한다.
구글에서는 좋은 팀의 특징을 찾기 위해 지속적으로 연구하고 있는데, 2015년에 공개한 연구 결과에 의하면
-
개개인의 능력보다 팀원이 어떻게 상호작용하고 자신의 일을 어떻게 바라보는지
-
실수, 질문 등에 대한 구성원의 태도(심리적 안전감)
-
심리적 안전감은 개선이 가능함
과 같은 부분이 중요한 것으로 나타났다.
이를 위해 새로운 방식을 도입할 때도, 리더가 일상에서의 마이크로 인터랙션을 통해 신뢰감을 주어야 성공적으로 도입이 가능하다.
팀 학습
개발자라면 기존의 코드를 처음 사용하는 언어로 바꿔야 하는 경우가 종종 있다.
이 때 팀의 학습 속도에 따라 새 언어로 된 코드가 무사히 안착할 수도, 전혀 진도가 나가지 못할 수도 있다.
이러한 학습 속도의 차이는 리더의 기술적 능력과는 크게 관계가 없다.
오히려 좋은 학습 환경이 학습 속도에 큰 영향을 준다.
좋은 학습 환경이란 다른 사람과의 협력이 장려되는 문화, 학습을 팀의 목표로 인식하고 함께 발전하고자 하는 태도가 갖추어진 곳이다.
이런 좋은 학습 환경을 갖춘 팀이 빠르게 학습할 수 있다.
