이 책에서 가장 인상 깊었던 개념은 바로 문제 해결형 리더쉽(Problem-Solving Leadership) 이다.
책에서는 리더십을 추상적인 개념으로 설명하지 않는다.
대신 성공한 테크니컬 리더가 실제로 문제를 풀어가는 과정을 세 가지 단계로 보여주고 있다.
- 문제를 정확히 이해하기
- 아이디어의 흐름을 관리하기
- 품질을 유지하기
이 세 가지는 단순한 체크리스트가 아닌, 리더가 문제를 다루는 사고의 구조다.
나는 이 부분에서 특히 공감하게 되었는데, 실무자로 일할 때는 물론이거니와 서비스의 메인 담당자로 일하면서도 이 세 가지를 체계적으로 생각해보진 않았고,
관성에 의해서 일을 해왔던 것 같다.
늘 "빨리 해결해야 한다" 는 압박감 때문에 곧장 해결책부터 던져버리는 경우가 종종 있었던 것 같다.
문제를 정확히 이해하는 것
책에서는 먼저 문제를 정확히 이해하는 것 의 중요성을 강조한다.
겉으로 드러난 증상에만 반응하게 되면 엉뚱한 방향으로 달리게 된다.
이 책을 읽으며 내가 종종 문제 정의를 대충 건너뛰고 해결에만 몰두했었던 장면들이 떠올라서 조금 뜨금했다.
아이디어의 흐름을 설계하는 것
그리고 두 번째로 강조 하는 건 아이디어의 흐름을 설계하는 것 이다.
책은 이렇게 말한다.
좋은 리더는 정답을 독점하지 않는다. 정답이 흘러나올 수 있는 구조를 만든다.
그 동안 나는 리더라면 누구보다 먼저 정답을 제시해야 한다고 생각했는데,
책에서는 오히려 질문을 던지고, 팀이 문제를 함께 소화하고 아이디어가 자연스럽게 흘러가게 만드는 사람이 진짜 리더라고 말한다.
생각해보면 내가 가장 신뢰했던 리더들도 항상 정답을 말하기 보다는 좋은 질문을 던지고, 그 흐름안에서 팀 전체가 스스로 해결하게끔 했던 사람들이었다.
품질 유지
세 번째는 품질 유지이다.
이건 단순히 결과물을 깔끔하게 만드는 걸 의미하지 않는다.
문제 해결 과정 전체가 처음 정의했던 문제와 어긋나지 않도록 방향을 지켜내는 일이다.
리더가 일일이 감시자가 되는 것이 아니라, 팀 전체가 품질 기준을 공유하고 지켜낼 수 있는 구조를 설계하는 것이다.
책을 읽고 나서 품질 이라는 단어가 단순히 QA 나 코드리뷰의 영역이 아니라 리더십의 영역 이라는 걸 새삼 깨달았다.
이 책에서 가장 크게 느낀 건, 리더는 문제를 해결하는 사람이 아니라 문제 해결의 장을 설계하는 사람이라는 점이다.
그리고 이 지점에서 리더와 관리자 의 차이가 아주 뚜렷하게 드러난다.
관리자는 일정과 리소스를 관리하고, 정해진 틀 안에서 효율을 높이는 사람인 반면,
리더는 그 틀을 다시 설계한다.
관리자는 계획을 지키는 데 집중하지만,
리더는 그 계획이 왜 존재해야 하는지부터 묻는다.
관리자는 통제의 언어를 쓰지만,
리더는 신뢰의 언어를 쓴다.
이 부분은 책을 읽으면서 정말 많이 공감이 갔던 부분이다.
특히, 기술 조직에서는 관리만으로는 절대 팀이 잘 굴러가지 않는다. 문제 해결형 리더십이 필요하다.
이 책은 내 사고 방식을 완전히 흔들어놓았는데,
그동안 리더십은 내가 잘 해결하는 것으로 만 생각했는데, 책을 읽고 나서는 함께 해결하는 구조를 만드는 것 이라는 것을 깨달았다.
문제를 정확히 정의하고, 흐름을 만들고, 품질을 지키는 사람이 진짜 리더인 것이다.
앞으로 리더가 될 사람이라면, 문제를 직접 푸는 사람보다 문제를 풀릴 수 있도록 판을 만드는 사람 이 되어야 한다.
그게 바로 이 책이 전달하는 메시지라고 생각된다.