파트장 잘 하고 있는 건가?

사진: Unsplash 의 Vian Widana

파트장 잘 하고 있는 건가 → 모르겠다. → 책을 읽어보자..

• 구글 엔지니어는 이렇게 일한다.
• 개발 7년차, 매니저 1일차
• 개발자를 넘어 기술 리더로 가는 길
• 육각형 개발자

리더십을 향상하는 데 경험이 정말 중요하지만, 경험만으로는 부족하다. 리더십 관련 책을 읽거나 강의를 들을 필요가 있다. 경험은 제한된 상황에서 이뤄지기 때문에 경험하지 못하는 상황이 훨씬 많다.경험에서 부족한 부분을 책과 강의로 채워 나가야 한다.
육각형 개발자 p.255

오늘날의 엔지니어링 관리자? 좋은 매니저?

리더는 주변 사람들을 성장시키고, 팀의 심리적 안전을 개선하고, 팀워크와 협업 문화를 조성하고, 팀 내 긴장을 해소하고, 구글 문화의 가치를 설정하며, 구글을 더 활기차고 신나는 일터로 가꿔야 합니다.

구글 엔지니어는 이렇게 일한다. p.109

좋은 매니저는 후배를 성장시키는 사람이다.

개발 7년차, 매니저 1일차 p.97

전통적인 관리자는 일을 '어떻게(how)' 처리할지를 고민하는 반면, 훌륭한 관리자는 '무슨(what)' 일을 처리할지를 고민합니다. (그리고 어떻게는 팀을 믿고 맡깁니다.)

구글 엔지니어는 이렇게 일한다. p.142

좋은 리더가 된다는 것은 위임을 잘한다는 것이다.

개발 7년차, 매니저 1일차 p.116

거시적인 측면에서 엔지니어링 관리자는 자신이 관리하는 팀의 구성원 모두의 성과, 생산성, 행복을 책임져야 합니다. 그와 동시에 팀에서 만드는 제품의 사업적 요구까지 충족시켜야 하죠.

하지만 사업적 요구와 개별 팀원의 요구가 항상 일치하는 것은 아니라서 이따금 관리자를 난처한 상황에 놓이게 합니다.

구글 엔지니어는 이렇게 일한다. p.136

 

여전히 대부분 '관리자(manager)'라는 용어를 사용하지만 사실 여러 면에서 시대에 뒤떨어진 이름.

(개인적으론 클래스 이름으로도 적합하지 않다는 생각; xxxManger, xxxService. 뭔가 다양한 일을 하는 녀석 같은데, 마땅한 이름이 생각 안날때 사용되는 것 같다.)

직책의 이름 자체가 사람을 '관리'하게 부추김, 관리자는 부모처럼 행동하고, 그 반작용으로 직원들은 자연스럽게 아이처럼 반응하게 됨

겸손, 존중, 신뢰의 틀에서 생각했을 때, 관리자가 직원들을 신뢰한다는 분명한 신호를 주면 직원들은 신뢰에 부응해야 한다는 긍정적인 압박을 느낌.

9시 출근의 의미

하지만 출근시간 가지고 싸우는 것을 보면, 한국에선 아직 쉽지 않은 것 같다..

위에서 언급된 단어들

• 심리적 안전
• 성장
• 행복
• 마이크로 매니징 → 위임

심리적 안전

• 2024.01.12 - [DEV] - 심리적 안전과 지식공유, 강백호와 중경삼림
• 팀원들이 안전하다고 느끼게 해주는 일 역시 팀을 촉진하는 좋은 방법. 심리적 안전을 확보해주면 사람들은 더 큰 위험도 기꺼이 감수할 것.
• 사람들 대부분은 위험을 정확하게 평가하지 못하며, 회사들 대부분은 최선을 다해 위험을 회피하려 함.
• 그래서 보통은 작은 성공에 집중하는 보수적인 전략을 택함
• 더 큰 위험에 맞서야 큰 성공을 쟁취할 수 있다.

Non-consensus right things

 

마이크로 매니징 → 위임

• 위임하되, 곤란한 일은 직접 처리하자
• 리더 역할로 이동할 때 가장 어려운 일 하나가 균형잡기
  • 초기에는 모든 일을 스스로 처리하려 들 것, 반대로 오래 수행하다보면 아무것도 스스로 하려 들지 않게 되기 쉬움
• 마이크로매니지먼트는 시나브로 시작된다.
  • 일정 지연이 용납되지 않고, 스트레스가 심한 프로젝트는 위태로워 보이기 마련이고 뭔가 해야겠다는 생각에 조금씩 개입하게 된다.
  • 팀원에게 위임했지만 팀의 기술적인 결정 사항이 마음에 들지 않거나, 실수가 많아서 이를 수정하느라 대가를 치른 경험 때문에..
• 마이크로매니징이 항상 나쁜것은 아니다
  • 주니어 개발자는 구체적인 지시를 원한다.
  • 하지만 팀을 운영하는 기본 방식으로 마이크로 매니징을 사용하는 것은 좋지 않다.
• 마이크로 매니지먼트로 팀을 잘 운영하기 어려운 이유는 자율성 때문
  • 창의적이고 재능 있는 사람이 자율성을 빼앗기면 즉시 동기도 사라짐
  • 자율성은 팀원이 자신의 업무 중 일부를 직접 통제할 수 있는지를 의미, 동기 부여의 중요한 요소

행복

• 행복한지 확인하기
  • 팀의 생산성을 장기적으로 더욱 끌어올리려면(이탈하는 팀원 줄이기 포함) 팀원들이 행복해 하는지를 확인하는데도 시간을 써야 함
  • 수시로 팀원의 복지를 챙기고, 하는 일을 인정해주고, 일에 만족하는지 확인
  • 한 매니저는 지저분하고 표 안나는 일, 하지만 꼭 해야만 하는 일들을 스프레드시트에 정리한 다음 모든 팀원에게 고르게 분배 되도록 관리
  • 팀이 행복한지를 추적하는 간단한 방법
    • 팀원들과의 일대일 면담 마지막에 '뭐 필요한 거 없어요?'라고 묻는 것
    • 이 질문은 면담 때마다 빼놓지 않고 던진다면 팀원들은 원하는 것을 머릿속에 담아둘 것

프로젝트 관리

추정

추정은 정확하지 않다. 요구 사항을 완벽하게 분석한 상태에서 추정한 것이 아니기 때문.

물론 요구 사항을 완벽하게 분석한 뒤에 추청해도 정확하지 않다. 요구사항이 변하기 때문.

자신만만한 개발자는 일정을 짧게 추정하는 경향이 있기도 하다... 그래서 추정할 때는 자신 있다고 너무 빡빡한 추정치를 사용하기보다는

약간의 여유 시간을 포함해서 추청해야 한다.그래야 추가로 발생할 업무나 변경에 따른 재작업 시간을 확보할 수 있다.

개발 7년차, 매니저 1일차 p.210 (한국 개발자)

빠른 추정을 할 때는 두 배 법칙을 사용하지만, 긴 작업을 추정하려면 계획 시간을 따로 가져야 한다.

인기 있는 소프트웨어 추정 방법인 두 배 법칙은 "시간 추정 요청을 받을 때마다 추측한 다음 두 배로 알려준다."이다. 이 규칙은 즉석에서 추측해 달라는 요청을 받을 때 사용할 수 있는 적절하고 좋은 규칙이다.

개발 7년차, 매니저 1일차 p.170 (미국 CTO)

 

.. 그래도 업무 소요 시간을 측정하는 것은 상당히 중요하다. 가장 일반적인 방법은 그 일을 완료할 수 있는 가장 작은 범위의 업무로 나누어 보는 것. 작은 범위의 업무 소요 시간을 측정하는 것은 상대적으로 쉽기 때문. 

두 번째 방식은 여러분의 측정이 항상 틀렸다고 가정하고 모든 측정 결과에 3을 곱하는 것.

개발자를 넘어 기술 리더로 가는 길 p.233 (아일랜드 스테프 엔지니어)

 

일정 산정에 너무 인색하지 않아도 된다. ㅎ

스케줄링

일정 구성 방법

일정 구성

• 통상 업무와는 달리 리더십 관련 업무량은 예측하기 어렵다. 일정을 구성할 때는 항상 업무량의 변동성을 최대한 감안
• 사용 가능한 시간의 100%를 할당했는데 예상치 못한 일이 발생한다면, 다른 업무를 취소하지 않고 모든 업무를 다 하기로 결정한다면
• 스트레스와 피로로 인해 불가피하게 여러분의 삶의 다른 부분까지도 부정적인 영향을 받을 것
• 가능하면 여유시간을 조금이라도 남겨두는 것

일관성 유지

• 스트레스를 받거나 감당할 수 없을 정도의 업무를 수행할 때는 한결같은 모습을 보여주기가 어려울 수도 있다.
• 한결같다는 것은 여러분 스스로를 잘 돌보는 것을 의미
• 여러분의 삶에서 계획에 없던 급작스러운 추가 업무를 위한 공간을 항상 어느 정도는 남겨두어야 한다.
• 스스로를 잘 돌볼수 있어야 → 한결 같은 모습을 보여줄 수 있고 → 다른 사람들이 예측 가능 → 조직내 안정감 평온함 부여

일관성 유지