엔지니어링 리더들을 위한 안티-패턴들(Anti-patterns)
(review.firstround.com)- CTO나 엔지니어링 리더들과 만나면 가장 자주 나누는 대화 주제는 "엔지니어링 속도를 높이라"는 CEO의 압박임
- 판매나 채용과 달리 엔지니어링에는 뚜렷한 성과 지표가 없음
- 엔지니어링 리더 입장에서는 CEO에게 "엔지니어링은 예술이라 성과를 예측하기 어렵다"고 말하기 곤란함
- 엔지니어링 리더와 경영진 간 이견의 원인
- 엔지니어링 리더들이 관행적인 리더십 조언을 너무 경직되게 따르는 경향이 있음
- 어떤 관행이 유용하다거나 그렇지 않다고 보편화하면 조직 상황에 맞는 적용이 어려워짐
- 상황에 따라 관행을 따를지 새로운 접근을 시도할지 판단하는 것이 효과적인 엔지니어링 리더십의 핵심임
- Carta의 CTO, Will Larson이 팟캐스트에서 얘기한 것을 정리한 글
엔지니어링 리더십의 3가지 안티패턴
- 마이크로매니지먼트 회피
- 불완전한 지표 측정 기피
- 리더가 팀을 위한 우산이 되는 것
[안티패턴 #1: 마이크로매니지먼트 회피]
최고의 엔지니어링 임원이 되기 위한 세 가지 모순된 역할
- 엔지니어링 임원은 서로 상반되는 세 가지 역할을 수행해야 하며, 최고의 임원은 이 역할들 사이를 능숙하게 오갈 수 있음
- 경영진 일원으로서의 역할 : 사업을 발전시키는 방법을 모색함
- 때로는 엔지니어링 예산 삭감 등 "엔지니어링 전체에 나쁜" 결정을 내려야 할 수도 있음
- 특정 주제에 대해 엔지니어링의 목소리가 줄어드는 사업부 모델로 이동하는 것도 포함될 수 있음
- 엔지니어링 관리자로서의 역할
- 엔지니어링 조직 운영에 필요한 정책의 구조를 파악하고, 효과적인 인재 리더가 되는 방법을 모색함
- 엔지니어로서의 역할
- 외부 스트레스 요인에도 불구하고 기술적 우수성과 엔지니어링 실행에 대한 책임을 짐
- 기술적 탁월성에 대한 기준을 높게 유지해야 함
- 경영진 일원으로서의 역할 : 사업을 발전시키는 방법을 모색함
- 많은 임원들이 이 세 가지 역할 중 하나에 너무 치우치는 경향이 있음
- 어떤 역할을 수행하든, 더 이상 도움이 되지 않는 관리 관행을 고수할 때 지도자들은 실수를 범함
- 갑자기 팀의 관리자가 되면 기술적으로 팀이 하는 모든 일에 대해 가장 많은 맥락을 가지고 있지만, 동시에 사람 관리자가 됨
- 이 시점에서 사람들은 계속해서 세부 사항에서 물러나라는 조언을 받음
- 신임 엔지니어링 매니저들은 종종 "코드에서 벗어나라"는 조언을 받음
- 어떤 사람들에게는 이런 조언이 도움이 될 수 있음을 인정함
- 하지만 고도로 유능한 경영진은 자신이 운영하는 도메인에 대해 어느 정도 세부적인 이해를 가지고 있음
- 세부사항에서 너무 멀어지면 관료가 될 뿐이고, 너무 많은 엔지니어링 매니저들이 결국 관료가 되고 마는 이유임
리더십 스타일의 배양
- Larson은 엔지니어링 임원들에게 마이크로매니지먼트라는 용어를 완전히 잊고, 대신 선택할 수 있는 다양한 리더십 스타일을 배양하는 데 집중하라고 함
- 명확한 앞으로의 길이 없거나 앞으로 나아갈 길에 대한 맥락을 가진 사람들이 격렬하게 의견이 일치하지 않는 경우, 세부 사항을 파고들어 스스로 결정을 내리는 것이 도움이 됨
- 이를 통해 비즈니스를 실질적으로 변화시킬 수 있는 지렛대, 팀이 달성해야 할 결과, 이를 수행하는 기간, 사용자에게 더 나은 서비스를 제공하는 방법을 이해할 수 있음
- 의사 결정에 대한 더 강한 확신을 개발하는 것은 평생 연습해야 할 일이며, Larson 자신도 여전히 노력 중임
- "우리가 무엇을 하고 있는가? 왜 그렇게 하는가? 데이터는 무엇인가? 실제 데이터 출처는 어디인가?"와 같은 질문을 매월 또는 분기별로 하는 것이 세부 사항을 더 깊이 파고드는 데 도움이 됨
세부사항으로 다가가는 두 가지 전술
-
"갈등 채굴"을 통해 맥락을 파악하기
- 새로운 환경에서 작은 맥락의 차이를 놓치는 것도 운영의 성공을 해칠 수 있음
- 반대 관점을 가진 사람들과 대화를 나누는 것이 오래 걸리더라도 "갈등의 씨앗"을 찾아내는 과정이 중요
- 성공적인 리더는 "내가 어떻게 바뀌어야 조직에 맞출 수 있을까?"라고 묻지, "내 방식에 맞추려면 조직을 어떻게 바꿔야 할까?"라고 묻지 않음
-
세부사항을 문서화하기
- 전략은 어디에나 있지만 거의 문서화되어 있지 않음
- 중요한 의사결정의 근거가 문서화되어 있지 않은 경우가 많음
- 문서화 문화 구축이 빠르게 움직이는 엔지니어링 조직의 열쇠
- 새로운 리더는 전략을 직접 만들기 전에 기존의 모든 것을 조사하고 다른 회사의 성공 사례를 벤치마크로 삼아야 함
- 전략 문서 작성 시 Richard Rumelt의 "좋은 전략, 나쁜 전략" 프레임워크 활용 추천
- 전략을 아무리 형편없게 작성하더라도 그냥 문서화하는 것만으로도 전략이 하룻밤 사이에 개선될 수 있음
[안티패턴 #2: 불완전한 지표 측정 기피]
- 측정에는 안티패턴이 만연해 있음
- 이상적으로 순수하게 "우리는 그것을 측정하지 말아야 해"라고 말할 수 있지만, 그렇게 하면 주위 조직의 학습만 느려질 뿐임
- 엔지니어링 임원이 가장 가치있는 일은 다른 임원들에게 공학이 어떻게 작동하는지 교육하는 것
정신 모델 개선에 초점 맞추기
- 지표가 현실을 보여주길 바라지만, 지표는 진실을 보여주는 것만이 아니라 사람들을 교육하는 것이기도 함
- 자신의 정신 모델을 모욕하는 것보다 이사회나 CEO의 정신 모델을 알리는 것을 더 걱정해야 함
CEO를 세부사항으로 끌어들이기
- "이것은 측정하기에 끔찍한 방법"이라고 말하는 대신 "여기서 시작해서 이런 식으로 측정하는 한계를 이해할 때까지 파고들어 보자"고 말해야 함
- 사람들을 억지로 세부사항에서 벗어나게 하는 것은 결코 좋은 방법이 아님. 세부사항으로 끌어들여 거기서 교육해야 함
[안티패턴 #3: 팀을 위한 우산이 되는 것]
- 과거에는 팀을 보호하기 위해 매니저가 "우산"처럼 행동하는 것을 믿었음
- 하지만 팀을 현실로부터 보호하는 것은 장기적으로 팀에게 해를 끼침
- 매니저와 엔지니어 모두 중요한 대화에 참여할 수 있게 해야 함
전략적 의사결정에 새로운 관점 필요
- Bottom-Up 전략
- 장점: 팀이 빠르게 움직이고 도구를 통제할 수 있도록 함
- 단점: 집중된 기술 투자 능력 없고, 정보를 약간 늦게 알게 됨
- Top-Down 전략
- 단점: CTO나 아키텍처 그룹이 모든 결정을 내리는 것은 비효율적
- 위원회가 최선의 결정을 내리는 경우는 거의 없음
"내비게이터"를 활용해 의사결정 가속화
- 비즈니스 유닛 별로 "미니 CTO" 역할을 하는 "내비게이터"를 두어 의사결정 속도를 높임
- 현장에서 가장 많은 맥락을 가진 사람들이 가장 적합한 기술 스택 결정을 내릴 수 있도록 함
- 성공을 위한 교훈:
- 문서화를 빠뜨리지 말 것
- 사후 검토할 것
- 신뢰를 두는 사람 선정에 매우 신중할 것
- 조직은 소수 개인들의 판단력이 축적된 것이며, 그것에서 벗어날 수 없음
마무리
- 규칙을 너무 엄격하게 따르는 것의 위험성
- 회사와 함께 엔지니어링 팀이 성장하기 시작할 때, 리더들은 이전에 많은 선의의 임원들을 곤경에 빠뜨렸던 것을 잊어서는 안 됨
- 궁극적인 목표는 사람들이 호기심을 가지고 예외를 찾는 것에 대한 고품질 메커니즘을 만드는 것임
- 학습 서클 (Learning Circle)
- Larson은 지난 3년 반 동안 2주에 한 번씩 "학습 서클"을 개최해 옴
- 6~10명의 CTO, VP of Engineering 또는 기술 회사의 기타 선임 엔지니어링 임원들이 모여 근황을 알리고, 전술과 프로세스 문제를 교환함
- 각 회의는 한 사람당 1분씩 돌아가면서 이번 주에 집중하고 있는 것과 이야기하고 싶은 주제를 말하는 것으로 시작함
- 5분 정도 주제에 대해 이야기한 후, 그룹으로 하나를 선택하고 다음 20분 정도 그것에 대해 심도 있게 파고듦
- 주제는 "이 프로젝트 때문에 곤란해지고 있다"에서 "정말 훌륭한 사람을 새로 고용했는데 기대된다"까지 다양함
- Larson은 지난 3년 반 동안 2주에 한 번씩 "학습 서클"을 개최해 옴
- 실천을 통한 학습
- 실천을 통해 배우는 사람들은 학습 서클이나 개인적인 반성과 같은 일상적인 성찰에 의지하여 규칙을 섬세하게 조정하는 데 필요한 자기 성찰을 강요할 수 있음
- Larson은 "나는 나와 비슷한 실수를 한 다른 사람들의 교훈에서 배워 더 나은 리더가 되었다"고 말함
이 글에 대한 Hacker News의 의견도 참고하세요.
- 여러 조직에서 적용해본 Will Larson의 Larson의 방법론이 그리 효과적이지 않다는 의견. 그의 방법론이 엔지니어와 비즈니스 간의 갈등을 초래함.
- Ron Jeffries의 책 추천: "The Nature of Software Development" 책을 추천하며, 점진적 가치, 엔지니어 주도, 지속적인 피드백, 유연성을 강조함.
- Larson이 자기반성과 비판을 할 수 있는 능력이 있다는 점에서 긍정적임. 그의 글이 항상 옳거나 그르지는 않지만 문제 해결에 깊이 몰두하고 있음.
- 웹 기반 제품의 특성상 오류가 치명적이지 않으며, 자주 발생하는 변경 사항이 마케팅 이유로 이루어짐. 따라서 빠르게 움직이고 실수를 허용하는 문화가 형성됨.
- 마이크로매니지먼트의 긍정적 측면: 좋은 엔지니어링 리더는 세부 사항을 잘 이해하고 팀과 소통할 수 있는 능력이 있음. 이는 마이크로매니지먼트와는 다름.
- 기술 인력이 너무 많아 문제를 일으킴. 더 나은 도구가 개발되면 소규모 팀으로도 충분히 작업을 수행할 수 있을 것임.
- 측정 자체가 문제가 아니라, 그 측정 결과로 잘못된 판단을 내리는 것이 문제임. 지표는 질문을 던지기 위한 도구로 사용되어야 함.
- 대규모 소프트웨어 개발은 협업이 핵심임. 커뮤니티의 붕괴가 프로젝트 속도를 늦추는 주요 원인임.
- 개발 파이프라인에서 각자의 역할과 기대가 명확하지 않으면 문제가 발생함. 관리자는 이러한 상황을 해결해야 함.
- 좋은 글이지만 길이를 25% 줄이면 더 좋을 것이라는 의견.
마지막 "Larson은 "나는 ... 더 나은 리더가 되었다"고 말함." 라는 부분에서 조금 부끄럽네요. 차라리 "리더는 ... 하기 위해 지속적으로 노력해야한다. 나도 아직도 부족하며, 더 나아지기 위해 노력하는 중이다" 요런 표현이었으면 좀 더 읽기 편했을텐데 말이죠. 너무 한국적인 관점일까요? ^^;;
한국적인 관점이냐고 물으시는 걸 보니 잘 알고 계신것 같습니다 제가 보기엔 화자가 나르시즘을 보이는 것도 아닌데 이런 반응은 좀 의아하네요
한국에서는 마냥 이상만 좇는 글로 보여집니다.
CTO도 직원 입장에서는 '관료' 입니다. 팀장이 아닙니다.
CTO에게 팀장 직책을 강조하는 글로 보입니다.
적절치 않은 조언으로 보입니다. 미국은 어떨 지 몰라도, 적어도 한국에서는요.
마이크로매니지먼트를 안 좋은 것, 하지 말아야 하는 것으로 간주해서 무조건 회피하는 것이 안티패턴이라는 것이고요. 마이크로매니지먼트냐 아니냐 하는 판단을 하지 말고 필요에 따라 세부사항을 챙겨야 한다는 얘기입니다.
하다못해 '안티패턴: 마이크로매니지를 선택지로 생각하는 것' 내지는 '디테일을 챙기는 것과 마이크로매니징을 같다고 생각하는 것' 이라고 했으면 문맥이 좀 더 매끄러웠을 것입니다. 글의 의도는 알겠는데, 결국 전달하고자 하는 메시지는 '마이크로'매니지 대신 디테일을 챙기는 매니지를 하란거겠죠