개발자의 커리어 패스 중 관리자(매니저) 트랙이 아닌 기술 리더십 트랙에 관한 내용
-
유형
- 기술 리드: 특정 팀의 방법과 실행을 가이드
- 많은 애자일 조직에서 존재하는 직함
- 8명 당 1명 정도가 보편적
- 아키텍트: 엔지니어링 방향/품질. 접근법의 정의를 책임
- 도메인 자체가 충분히 복잡하고 성공에 중추적인 역할을 할 때 유용
- 해결사: 여러 복잡한 문제를 파고들어 적절한 해결책을 찾아낸다
- 가장 어려운 문제를 해결하는 조직이 신뢰하는 인력
- 찾아보기 힘든 유형
- 오른팔: 임원의 역할과 권위를 위임받아 복잡한 조직 운영
- 리더를 대신하여 스태프 회의에 참석
- 본질적인 여러 문제를 해결하고 적절한 팀에 실행을 위임
-
어떤 업무를 주로 하게 되는가?
- 기술적 설계를 주도하고 회사의 전략적 가치를 지닌 프로젝트나 활동을 주도
- 기술적 방향 설정과 수정
- 주변 사람의 성장과 지원
- 의사 결정 시 엔지니어링 관점의 제공
- 신뢰할 수 있는 직원을 찾아 리소스를 제공
- 눈에 보이지 않더라도 팀의 발전을 위한 작업 지속
-
이렇게 해보자!!!
- 중요한 일에 집중하자
- 영향력이 작고 쉬운 일에 매몰되지 말자
- 과거의 경험에 너무 의존하지 말자
- 중요하지만 수행할 자리가 충분한 업무를 수행하자
- 조직의 아키텍처, 기술, 구조 등의 엔지니어링 전략을 기록하자
- 전략은 주도적인 조정 도구로 신속한 결정에 도움을 준다
- 전략: 설계 문서 5개의 유사점을 찾아내서 기록한 문서
- 비전: 5개의 전략을 통해 향후 2년 내에 벌어질 일을 예측하는 짧은 문서
- 기술적 품질을 선별하자
- 현재 품질과 목표 수준을 계속 재 설정하고 달성하기 위해 노력해야 한다
- 빠르게 적용 가능한 것부터 도전해보자
- 품질 문제가 발생하는 지점을 먼저 수정한 후 권장 사례를 도입해야 한다
- 지렛점
- 조금만 투자하면 시간이 지나도 품질이 유지되는 부분
- 주로 인터페이스, 상태가 있는 시스템, 데이터 모델
- 지휘권을 가진 사람과 협력하기
- 관리자에게 정보를 많이 제공하자
- 문제를 숨기기 위해 정보를 조작하거나, 상황을 제대로 전달하지 않는 행위를 하지 말자
- 리드하려면 따라야 한다
- 팀의 기술적 로드맵을 엔지니어링 전반의 로드맵에 맞춰야 한다
- 피드백, 지원은 신속하게 이루어 져야 한다
- 절대 틀리지 않는 방법을 배우자
- 회의에서 좋은 의도의 좋은 질문을 던지자
- 명확한 목적을 제시하여 불필요한 토론을 제거하자
- 참석자 간의 의견이 너무 다르다면 하위 그룹이나 다른 그룹으로 논의를 옮겨보자
- 반대 할 수 있지만 결정이 내려지면 따라야 한다
- 타인을 위한 공간 창출
- 내가 관여하지 않아도 더 많은 사람이 참여하는 좋은 논의가 진행되도록 해보자
- 내가 아닌 팀의 성장을 위해 업무를 배분해야 한다
- 동료와 네트워크 구축
- 자신을 팀 외부에 드러내고 대화에 참여하자
- 오래 지속될 문서를 작성하자
- 회사 블로그나 포스트를 작성하자
-
스태프 프로젝트
- 스태프가 되기 위해 도움이 되는 프로젝트
- 모호하고 복잡하자
- 이해 당사자가 많다
- 모두가 실패할까 조바심 내지만 중요한 프로젝트이다
-
여러 스태프 엔지니어들의 생각
- 개밥먹기(스스로 기능을 실제 유저 처럼 테스트)는 매우 유용했다
- 엔지니어링 조직의 모든 문제를 해결할 거라고 생각하지는 마세요
- 50%정도는 회의로 시간을 보내요
- 스폐셜 리스트는 정말 복잡한 프로젝트를 맡아 스스로 진행해요
- 넓은 시야를 가지려고 노력해 보세요
- 아키텍처적 결정과 배포 전략을 고민하는데 많은 시간을 써요
- 단점보다는 자신의 강점을 확대해라
- 기술적 지식과 회사에 미치는 영향에 집중해보세요
- 조직의 피드백 절차를 통해 조직의 상황을 계속 파악해 보세요
- 시스템 설계를 해보고 , 환경이나 소프트웨어에서 오 동작하는 부분을 디버깅 해보세요
- 생각을 제시 할 때 순서를 관리하는 것은 명확한 글쓰기에 필요한 가장 중요한 요소이다
- 좋아하는 일을 해라!!
- 나를 높이 평가하는 회사에 입사하라