엔지니어링 리더들을 위한 안티-패턴들(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은 "나는 나와 비슷한 실수를 한 다른 사람들의 교훈에서 배워 더 나은 리더가 되었다"고 말함
마지막 "Larson은 "나는 ... 더 나은 리더가 되었다"고 말함." 라는 부분에서 조금 부끄럽네요. 차라리 "리더는 ... 하기 위해 지속적으로 노력해야한다. 나도 아직도 부족하며, 더 나아지기 위해 노력하는 중이다" 요런 표현이었으면 좀 더 읽기 편했을텐데 말이죠. 너무 한국적인 관점일까요? ^^;;
한국적인 관점이냐고 물으시는 걸 보니 잘 알고 계신것 같습니다 제가 보기엔 화자가 나르시즘을 보이는 것도 아닌데 이런 반응은 좀 의아하네요
한국에서는 마냥 이상만 좇는 글로 보여집니다.
CTO도 직원 입장에서는 '관료' 입니다. 팀장이 아닙니다.
CTO에게 팀장 직책을 강조하는 글로 보입니다.
적절치 않은 조언으로 보입니다. 미국은 어떨 지 몰라도, 적어도 한국에서는요.
마이크로매니지먼트를 안 좋은 것, 하지 말아야 하는 것으로 간주해서 무조건 회피하는 것이 안티패턴이라는 것이고요. 마이크로매니지먼트냐 아니냐 하는 판단을 하지 말고 필요에 따라 세부사항을 챙겨야 한다는 얘기입니다.
하다못해 '안티패턴: 마이크로매니지를 선택지로 생각하는 것' 내지는 '디테일을 챙기는 것과 마이크로매니징을 같다고 생각하는 것' 이라고 했으면 문맥이 좀 더 매끄러웠을 것입니다. 글의 의도는 알겠는데, 결국 전달하고자 하는 메시지는 '마이크로'매니지 대신 디테일을 챙기는 매니지를 하란거겠죠
CTO나 엔지니어링 리더들과 만나면 가장 자주 나누는 대화 주제는 "엔지니어링 속도를 높이라"는 CEO의 압박임
판매나 채용과 달리 엔지니어링에는 뚜렷한 성과 지표가 없음
엔지니어링 리더 입장에서는 CEO에게 "엔지니어링은 예술이라 성과를 예측하기 어렵다"고 말하기 곤란함
이 글에 대한 Hacker News의 의견도 참고하세요.
- 여러 조직에서 적용해본 Will Larson의 Larson의 방법론이 그리 효과적이지 않다는 의견. 그의 방법론이 엔지니어와 비즈니스 간의 갈등을 초래함.
- Ron Jeffries의 책 추천: "The Nature of Software Development" 책을 추천하며, 점진적 가치, 엔지니어 주도, 지속적인 피드백, 유연성을 강조함.
- Larson이 자기반성과 비판을 할 수 있는 능력이 있다는 점에서 긍정적임. 그의 글이 항상 옳거나 그르지는 않지만 문제 해결에 깊이 몰두하고 있음.
- 웹 기반 제품의 특성상 오류가 치명적이지 않으며, 자주 발생하는 변경 사항이 마케팅 이유로 이루어짐. 따라서 빠르게 움직이고 실수를 허용하는 문화가 형성됨.
- 마이크로매니지먼트의 긍정적 측면: 좋은 엔지니어링 리더는 세부 사항을 잘 이해하고 팀과 소통할 수 있는 능력이 있음. 이는 마이크로매니지먼트와는 다름.
- 기술 인력이 너무 많아 문제를 일으킴. 더 나은 도구가 개발되면 소규모 팀으로도 충분히 작업을 수행할 수 있을 것임.
- 측정 자체가 문제가 아니라, 그 측정 결과로 잘못된 판단을 내리는 것이 문제임. 지표는 질문을 던지기 위한 도구로 사용되어야 함.
- 대규모 소프트웨어 개발은 협업이 핵심임. 커뮤니티의 붕괴가 프로젝트 속도를 늦추는 주요 원인임.
- 개발 파이프라인에서 각자의 역할과 기대가 명확하지 않으면 문제가 발생함. 관리자는 이러한 상황을 해결해야 함.
- 좋은 글이지만 길이를 25% 줄이면 더 좋을 것이라는 의견.