멘토링
- 멘토링은 관리와 관련된 업무를 배울수 있는 기회이다.인턴을 위한 멘토링
인턴쉽
- 인턴에게는 실무 경험의 기회
- 회사에게는 인재 채용의 기회
인턴의 멘토를 하면서 매니저가 되었을때 필요한 기술을 연습할 수 있다.
- 경청하기
- 의사소통 하기
- 적절한 피드백 주기신입사원 멘토링 하기
* 암묵적 규정
: 명문화 되어 관리되는 규정이 아닌 것들
- 책에서의 예시 : 전자상거래 업체는 보통 연휴 전/후로 휴가를 쓰지 않는다.
- 내가 경험한 예 :
1. 금요일에는 배포를 지양한다.
- 주말간 배포로인해 이슈 발생시 빠른 대응이 어렵기 때문.
- 이전 직장에서는 개발조직에서 배포에 대해 명문화? 조직내 전파 하며 관리 하기도 했다.
(설 연휴 1~2주 전부터 앱/서버 등, 주요 피쳐를 제외하고 배포 홀딩)
2. 온콜 제도
- 서비스 규모가 조금 크다고 생각하는 회사에서의 경험으로.
비상대기조 같은 느낌의 일인데. 당연히 이러한 업무는 어떤 회사라도 있을거라고 생각했지만.
당연하게도 입사할 때 이런 업무가 있을거라고 듣지는 못한다. ㅋ (이건 예시에 안맞을지도..)
- 신입사원 멘토링은 암묵적 규적을 알고 이해하기 위한 기회가 되어야 한다.
- 암묵적 규정 때문에 새로운 사람들이 팀에 적응 하고 맡은업무를 해내기 힘든 경우가 있다.
- 효울적인 팀에는 신입사원 교육문서가 잘 갖춰져 있다.
- 개발환경 구축, 트래킹 시스템 동작 이해, 필수업무 도구 단계별로 설명한 문서 등.
- 멘토링은 신입사원을 주변 동료에게 소개할 수 있는 기회이기도 하다.
- 신입사원이 멘토의 인맥을 사용하면 더 쉽게 적응 할 수 있다.
- 멘토 또한 인맥을 넓힐 기회일 수 있다.
- 신입사원을 관리하는 것이 관심이 없을지라도!!
- 정보와 아이디어를 공유하는 신뢰할 수 있는 이맥이 없다면 좋은 경력을 쌓기 어렵다.
- 인맥을 만드는 일이 시간과 에너지를 쓰는 일이라는 것을 명심하자.기술과 경력 멘토링
기술 멘토, 경력 멘토
책에서도 간략하게 설명
- 생산성을 높이기 위해 팀내의 시니어 개발자가 주니어 개발자의 멘토가 되면, 둘은 함께 문제를 풀 수 있다.
- 회사에서 팀을 넘어서 멘토와 멘티를 설정할 때도 있는데.
인맥을 넓힐 기회 일 수 있지만, 이러면 업무가 달라서 혼란스러울 수 있다.
- 멘토와 멘티 서로가 서로에게 기대하는 것과 목표를 명확히 하는게 좋다.
- 멘토 일때
- 멘티가 질문을 준비하게 하기 위해서, 미팅 주제와 질문을 먼저 요청해야한다.
- 시간 약속 분명히, 멘티의 질문에 솔직하게 답해준다.
* 매니저나 동료로써 반드시 해야하는 솔직한 충고나 조언을 할 만한 전문성을 갖추지 않았다면
- 멘토로 나서는 것은 의미가 없다. - 거절하는게 맞다.(서로의 시간을 지키자)
- 멘티 일때
- 멘토링을 통해 얻고 싶은것을 생각하며 멘토링시간을 준비해야 한다.
- 멘토가 필요 한지 잘 생각해보자 (서로의 시간을 지키자)내가 누군가를 멘토링한 경험은 많지 않은것 같다.
예전 직장에서 짝궁 제도가 있어서 , 신입사원의 온보딩을 도와줬지만.
글을 읽고 다시 생각해보면, 좋은 역할을 하지는 못 했던것 같다.
당시 온보딩을 위한 문서도 부족했지만, 문서화를 하려는 노력도 하지 않았고
구두 설명으로 진행했던것 같다.
구두 설명을 하다보니 갱신된 정보를 놓칠때도 있고, 설명해야 할 항목을 빠트릴때도 있었다.
내가 누군가의 멘토가 되기에 적절한가 생각해 봤을때.
부족한 면이 많은것 같다.
- 인맥 : 사내 인맥은 중요한 부분이다. 멘티에게 들어오는 모든 문제를 내가 모른다고 해서 다 매니저에게 토스 할 수도 없다.
- 기술 : 기술적으로 뛰어나다고 생각하지 않기때문에, 멘티에게 잘못된 정보를 전달할까봐 두렵다.
멘토로써도 자신이 없는데, 매니저는 가당치도 않은것 같기도 하다.
성격 상 어려운 부분이 많다고 생각한다.
(하고 싶다고 다 하면 안되고 할 수도 없다. 스스로의 모자람은 인지하자.)
좋은 매니저, 나쁜 매니저 : 알파 긱 (Alpha geek)
알파긱 : (역자주)사무실에서 기술이나 컴퓨터에 관련된 지식이 많은 사람을 의미하는 속어
- 팀에서 인정받는 개발자
- 늘 정답을 말하며, 어려운 문제도 풀어내는 사람
- 지적이고, 기술력에 최고의 가치를 두며, 실력이 의사결정에 영향을 미쳐야 한다고 믿는다.
-> 이들은 자기가 받아야할 관심을 빼앗는 사람이나, 자기를 능가하는 사람을 만나면 쉽게 위축된다.
알파긱은 자신이 최고라고 믿으며, 자신에게 동조하는 말에만 반응한다.
뭐든 뛰어나야하는 '탁월함의 문화' 를 만들려고 하지만 결국에는 '두려움의 문화'를 만드느 경향이 있다.
-> 이들은 보통 탁월하고 효율적으로 일하는 개발자
- 등 떠밀려 매니저가 되거나, 팀에서 가장 똑똑한 사람이 매니저가 돼야 한다는 통념에 따라 매니저가 된다.
- 타인의 실수를 얕잡아 보거나
- 아무런 경고도 없이 팀원이 한 작업이나 다른 팀원의 작업을 직접 다시 하는 최악의 해동을 한다.
이들이 좋은 매니저일 경우
- 젋은 개발자에게 많은 영감을 주기도 한다.
- 본인이 원한다면 알려줄 것이 많고 훌룡한 시스템을 설계할 수 있다.
- 팀에게 가르칠 지식이 많아 팀원은 그의 하래들 견디며 실력을 존경한다.
나쁜 매니저라면?!
- 자기 의견이 반영되지 않은 결과는 아무도 가져갈수 없게 한다.
- 좋은 아이디어를 내는 일은 열심히, 부적적인 측면을 검토하는데 관심이 없다.
- 자기가 아는것을 모든 개발자가 알아야 하며, 만약 모르면 즐거워 하며 무지를 지적한다.
- 업무 진행 방식에 매우 엄격
- 비판에 공격적으로 반응한다
- 존경하지 않는 사람에게 지시 받는 것을 극도로 싫어한다.
- 기술 관련 업무를 하지 않는 사람에게 모욕을 주기도 한다.
(이 정도면 저자는 나쁜매니저의 알파긱을 많이 경험 했나 보다... -..- )
자신이 알파긱이라면?
- 멘토링을 통해 자신을 변화 시킬 수 있다.
- 변화하기 싫다면? 하지 마라!
멘토의 매니저를 위한 팁
- 멘토링 관계를 설정하는 이유 찾아보기
- 명확한 목표가 필요하다
- 멘토링은 멘토에게 책임이 추가된다는 점 인지
- 멘토링을 위해 멘토는 시간을 투자한다. 생산성이 떨어질 수 있다.
- 업무가 바쁜 사람을 멘토로 지정하지는 않을 것이다.
- 멘토링을 팀의 차기 리더를 훈련하고 보상하는 기회로 이용하자알파긱 이라는 속어를 처음 들었다.
내가 경험한 알파긱에 해당하는 인물들은… 음.
예전 직장에서 조직의 큰 장이 되신 분(이하 A)이 있었는데.
(직접적으로 얘기 나눠본 적은 없었다 — 내가 있던 팀이 약간 외인구단 같은 느낌이라.)
어느날은 그분이 당시 어떤 엔지니어 분께 큰 소리로 호통을 쳤던 일이 있다.
“비판은 비공개(책의 1장 내용)” 와 정반대로 사무실 입구 가운대에서 일어 났던 일이었다.
그 엔지니어 분도 매니저의 역할을 하고 있었는데. 보는 내가 다 손에 땀이 나고 얼굴이 빨개졌던 기억이 있다.
그 A가 큰 조직의 장이라 (매니저의 매니저라서?) 달랐던 걸까? 라고 생각했지만. 책에서 얘기하는 것처럼, 같은 조직에서 일하는 우리는 서로가 동료로써 인격적인 관계를 맺고 있다고 생각한다. 그 엔지니어 분은 고분고분하게 양손을 모으고 듣고 있던걸로 봐서는 , 엔지니어 분이 먼저 비 인격적으로 얘기하지는 않았을것 같았다.
물론 인과관계를 모르기 때문에 단정 지을 수는 없지만.
알파긱이라는 책의 내용을 보면서 A가 떠올랐다.
핵심 요약
- 호기심과 열린 마음 갖기
- 멘토링 과정에서 조직의 명확하지 않은 부분을 찾을 수 있다.
- 상대방의 언어를 듣고 말하기
- 인맥 관리하기이 장의 처음부터 말하는 핵심은 경청과, 소통 그리고 인맥이다.
어떻게 보면 인간관계의 가장 기초적인 부분인것 같다.
회사에서 상하관계로 나눠진다고 해서 무시할 부분은 아니라는 뜻?
이 장에서 좋았던 부분은 멘토-멘티 목표설정 부분이었다.
멘토링을 함으로써 어떠한 목표를 이룰 건지 명확해야, 좋은 멘토링 과정을 만들어 낼 수 있는것 같고 , 적절한 멘토를 선정할 수 있는것 같다.
회사 이직을 그래도 많이 했는데. 이직 할때마다 온보딩 메이트가 있었다.
보통 매일 1시간 정도로 미팅 스케쥴을 잡고 진행을 했는데.
예전 어떤 직장에서는
온보딩 기간에 너무 한번에 많은 정보가 들어오다 보니. 정리도 안되고
목적조직에서 실무 진행시 어떻게 업무를 처리하면 되는지 까지는 온보딩 기간에 알 수 없었다. (시니어 라서?!) 게다가 맡게된 온보딩 업무는 기능 팀내 백로그 처리라.
실제 업무 스타일(목적조직 팀에서의)을 익히기에는 어려움이 있었다.
당시 온보딩 메이트 분도 너무 바빴어서 매번 물어보기도 애매했다.
(하지만 물어보는 방법밖에 없다. ㅋ 무조건 물어보자.)
기능 조직 팀마다 온보딩 스타일이 달랐던듯도 싶다.
당시 나는 입사 후 혼자 목적조직 팀에 투입되어 일을 처리 했는데.
다른 팀 같은 경우는 팀(스쿼드/유닛/풀스택팀)에 두명이 투입되어 하나의 업무 (또는 두개) 를 온보딩 메이트가 섀도잉 하면서 업무를 처리 했다.
실제 업무를 통한 온보딩이라. 조금 더 효과적일 수도 있는 방법 같았다.
기능조직에서의 온보딩도 중요하지만, 목적조직에서의 온보딩도 중요 한것 같다는 생각이 들었다.
리뷰는 아닌것 같고 요약과 잡글 끝…
