개발 7년차, 매니저 1일차
저자의 영문 원제목은 "The Manager's Path" 인데, 그대로 쓰기에는 번역본의 제목보다는 확실히 좀 눈에 덜 띄긴 하다.
책의 흐름이 중니어를 벗어나 시니어로 들어선 때부터 CTO 까지, 각 직책에서 필요한 역량들에 대해 잘 정리해서 알려주고 있어서 좋았다. 물론 회사마다 직책에서 요구하는 역량들이 다르긴 하겠지만, 책을 읽을 때 특별히 직책을 고려하지 않고 전반적으로 어떤 역량을 필요할때 어떻게 하면 좋다라는 가이드라고 생각하고 읽으면, 오히려 앞으로 필요한 역량을 미리 준비하는데 도움이 되지 않을까 한다.
하지만 반대로, 현재 내 주변에 같은 직책의 분들이 이 책에 나오는 만큼 왜 못하는 있는걸까 하고 답답함이 느껴지기도 하는 역효과도 있을 수 있으니 감안하고 읽으면 좋겠다.
책의 내용중 팀장 이후부터 CTO 까지의 주요 글귀는 아직 발췌하지 않았다. 그 시기가 오면 다시 천천히 정독해볼 셈이라서...
원온원 미팅
팀원에게 매니저와 하는 원온원(1:1) 미팅은 좋은 업무 관계를 맺는 데 꼭 필요하다. 그러나 많은 매니저가 원온원 미팅을 소홀히 하거나 시간 낭비라고 생각한다.
원온원 미팅에는 두 가지 목적이 있다.
첫 번째는 팀원과 매니저 사이의 인간적인 연결이다. 훌륭한 매니저라면 팀원의 컨디션을 눈치채고 왜 그런지 물어볼 정도로 팀원을 챙길 줄 알아야 한다. 신뢰가 바탕이 된 인간적인 연결은 좋은 팀의 뼈대다. 신뢰, 특히 진실한 신뢰를 쌓으려면 상대 앞에서 기꺼이 약해질 수 있는 능력과 의지가 필요하다. 그러니 매니저라면 팀원을 직장 밖에서 삶이 있는 사람으로 대하고 팀원의 삶을 주제로 몇 분쯤은 이야기할 수 있어야 한다.
두 번째 목적은 어떤 주제라도 개인적으로 이야기하는 것이다. 원온원 미팅 주제를 정하는 것은 팀원의 몫이다. 만약 매니저가 먼저 요청하는 경우 팀원이 주제를 준비할 시간이 부족할 수 있다. 좋은 원온원 미팅은 상황을 보고하는 미팅과 다르다. 원온원 미팅이 프로젝트 상황을 확인하는 시간이 된다면 미팅은 금세 지루해진다.
☻ 원온원 미팅을 요청받는 입장에서 미리 경험해봤으면 좋았겠지만 현재는 정기적인 미팅이 체계화되어 있지 않아 아쉽다.
그래도 미리 연습해본다 생각하고 후배님들에게 요청해보는 것도 좋을 것 같은데, 한편으로는 걱정도 된다.
개인의 삶이라고 해도 어느정도 선이 있을테니 그 선을 넘지 않게끔 잘 기준을 잡아봐야겠다.
피드백과 직장 가이드
팀원이 매니저에게 기대하는 두 번째는 피드백이다.
피드백에서 칭찬은 공개로, 비판은 비공개로 하는게 이상적이다. 팀원을 공개 칭찬하는 것은 모범 사례(Best Practice)가 주는 긍정적인 효과가 크다.
팀원이 매니저에게 피드백을 요청하는 경우, 매니저에게 조언을 구하는 것은 존경을 표현하기에 좋은 방법이다. 누구나 꼭 필요한 사람이라고 인정받는 것을 좋아하며 매니저라고 해서 결코 다르지 않다.
시니어가 될수록 좋든 나쁘든 피드백의 수는 줄어든다. 시니어가 될수록 개인적인 피드백보다는 팀 또는 전략과 관련된 피드백이 늘어난다. 원온원 미팅을 주도하고 논의할 주제를 준비하고 매니저에게 피드백을 받는 일이 더욱 중요해지는데, 이를 소홀히 하면 매니저는 당신에게 성과 평가말고 무엇에도 많은 시간을 쓰지 않으려 할 것이다.
☻ 좋든 나쁘든 피드백도 했을때 받아들이는 태도가 되야 해주는 리소스가 아깝지 않다!
사회 어딜가나 귓등으로 듣거나 알겠다고 해도 고쳐지지 않는 사람들은 반드시 있다!
교육과 경력 성장
매니저는 구성원과 회사라는 관료제 사이의 주요 연결 고리이므로 팀원의 경력 개발을 돕는 교육을 찾아 제공할 책임이 있다.
시니어 업무일수록 승진 기회는 줄어든다. 따라서 매니저는 팀원이 다음 단계로 승진하는 데 필요한 자격을 증명해줄 성과가 무엇인지 찾고 알려줘야 한다.
☻ 꼭 승진에 결부시키지 않아도, 후배들이 한단계 더 성장할 수 있는데 도움이 되는 포인트를 찾고
관련 능력을 성장시킬 수 있는 교육과정을 잘 찾아주는것도 필요할 것 같다.
매니저에게 휴식을 주자
경력을 쌓아 시니어가 될수록 매니저는 풀어야 할 문제보다는 해결책을 기대한다. 원온원 미팅 때마다 필요한 것, 잘못된 것, 더 원하는 것을 말하지는 말자. 매니저가 문제를 해결해주길 바라는 대신 매니저에게 문제 접근 방식에 대한 조언을 구하자. 조언을 구하는 것은 존중과 신뢰를 표현하는 좋은 방법이기도 한다.
☻ 문제를 해결해주길 바라는 대신, 문제 접근 방식에 대한 조언을 구하자!
매니저를 현명하게 선택하자
실력 있는 매니저는 '사내 정치'를 하는 방법을 알고 있다. 뛰어난 매니저와 친구 같은 매니저, 개발자로서 존경받는 매니저 사이에는 차이가 있다. 많은 개발자는 조직에서 리더십과 관련된 정치적 맥락을 알지 못하고 알려고도 하지 않기 때문에 무능한 매니저로 전락하고 만다. 뛰어난 개발자가 주니어 팀원에게는 훌륭한 멘토형 매니저(Mentor-Manager)일 수 있지만, 시니어 개발자에게는 그저 자기 주장만 강한 변호사형(Advocate-Manager)일지도 모른다.
☻ 음...제일 하기 싫은게 '사내 정치'인데..확실히 무능한 매니저가 될수 있겠다 싶다.
성과를 잘 내도 회사에 아무것도 못 받아내는 거에 비해,
어느 정도 성과에도 '사내 정치'가 뒷받침 되어 잘 받아내는 매니저가 부러울때도 있다.
인턴을 위한 멘토링
실무 경험이 거의 없는 대학생을 멘토링한다는 것. 인턴이 의미 있는 경험을 하려면 어떻게 해야 할까? 먼저 인턴이 회사가 찾는 인재가 아니어도 멘토를 좋아하게 만들어야 한다. 그래야 인턴 기간이 끝나고 학교로 돌아가 친구에게 인턴 경험을 좋게 전달하고, 멘토에 대한 좋은 인상은 인재 채용에 막대한 영향을 미친다. 인턴을 뽑는다는 것은 그 회사가 그 학교의 졸업생을 채용하는 데 관심이 있다는 의미이기도 하다. 인턴과 함께하는 과정이 장차 매니저가 되는 데 필요한 기술을 연습하는 과정이 된다. 이때 필요한 기술은 경청, 의사소통하기, 적절한 피드백 주기 등이다.
☻ 인턴에게만 초점을 두고 하나라도 배워가게 해주면 좋겠다고만 생각했었는데,
그에 더해 인턴이 학교로 돌아가서 주변에 전파하는 회사의 좋은 인상들이 더 영향을 미칠 수 있을거라 생각해본적 없었던 것 같다.
경청하기
경청은 사람 관리의 시작이자 기본이다. 경청은 좋은 매니저의 핵심 기술 중 하나인 공감의 전 단계다.
멘티가 말할 때 자신의 행동에 주의를 기울이자. 멘티가 말할 때 뭐라고 말을 할지 미리 생각하지 않는가? 눈앞에 닥친 업무를 고민하지 않는가? 상대방이 하는 말에 귀기울이지 않고 다른 일을 하지는 않는가? 만약 그렇다면 이것은 경청이 아니다.
리더십을 배울 때 초반에 느끼는 깨우침 중 하나는 직접적이든 간접적이든 모든 사람은 자신의 의도를 상대방이 정확히 이해하게 말하지 못한다는 점이다.
멘토는 복잡한 설명을 몇 번이나 다른 방법으로 말할 수 있어야 한다. 멘티의 질문이 이해되지 않으면 다른 방식으로 거듭 질문을 한다. 멘티가 이해할 때까지 시간을 쓰는 것이다. 기억하자. 멘티의 눈에는 멘토가 큰 힘이 있는 위치의 사람이다. 멘티는 힘들게 잡은 기회를 망칠까 봐 또는 멘토를 기쁘게 해야 한다는 생각에서 멍청하게 보이지 않으려 노력하기 때문에 긴장한다. 멘토가 질문에 답을 하기 위해 많은 시간을 쓰는 확률보다 멘티가 충분히 질문하지 않아 일이 전혀 다른 방향으로 잘못 진행될 가능성이 더 높다.
☻ 나는 어느정도 부담감과 긴장감을 가지는건 나쁘지 않다고 본다. 그만큼 집중할 수 있고 집중하고 있다는 거니까.
다만 시간을 뺏어서 미안해하거나 바쁜데 방해해서 죄송하다는 생각은 안했으면 좋겠다.
후배님들의 업무에 방향성을 잡아주고, 성장시키고 조언을 해주라고 회사에서의 내 시간은 그러려고 있는거니까...
명확하게 의사소통하기
인턴이 스스로 해결 방법을 찾지 않고 멘토의 도움에만 기댈 수도 있다. 이럴 경우 다른 관리 방법이 필요하다. 인턴에게 이정표가 될 프로젝트의 첫 마일스톤을 알려주고 하루나 이틀 동안 혼자 작업할 시간을 준다. 인턴이 작업을 하고 있는 중간에 프로젝트를 중단하거나 교체하는 것은 부득이한 경우를 제외하고는 피해야 한다. 인턴이 기대보다 빠르게 모든 작업을 끝내 놀라게 할 수도 있으나 대부분은 행복한 상상에 불과하다. 대개 인턴이 올바른 방향을 유지하도록 약간의 방향성과 명확한 작업 방법을 알려줘야 한다.
☻ 인턴이라면 실력을 뽑내고 성과를 내는데 주안을 두기보다는 일하는 법을 배워간다고 생각하면 좋을 것 같다.
신입 사원 멘토링하기
효율적으로 일하는 팀에는 신입 사원 교육 문서가 잘 갖춰져 있다. 이를테면 개발 환경을 구축하고, 트래킹 시스템 동작을 이해하고, 필수 업무 도구를 단계별로 설명한 문서 등을 말한다. 이런 문서는 업무 환경의 변화에 따라 내용이 갱신되어야 한다. 멘토는 이 문서를 통해 신입 사원이 잘 적응하도록 돕고, 신입 사원은 교육 과정에서 겪은 문제를 기록해 팀에 헌실할 수 있음을 보여주는 것이 좋다.
☻ 처음 환경 적용하면서 한번 업데이트, 3개월 OJT 끝날때 다시 한번 업데이트!
기술과 경력 멘토링
매니저나 동료로서 반드시 해야 하는 솔직한 충고나 조언을 자신 있게 할 정도의 전문성을 갖추고 있지 않다면 멘토로 나서는 것은 의미가 없다. 그런 경우라면 멘토링을 거절해도 괜찮다. 자신의 시간은 소중하며, 멘토와 멘티에게 가치 있는 일이 아니라면 의무감에 "알겠다"라고 대답하는 것은 의미가 없다.
☻ 그렇긴한데...너무 다 자신있는 사람만 시키고 준비만 하다보면 언제 경험을 쌓아볼 수 있을지 걱정되기도 한다.
완벽한 준비는 아니더라도 해보자. 멘토도 해보면서 어디가 부족한지도 느끼고 전문성도 갖춰가는거니까.
다만, 멘티에게 미안함을 느낄정도로 준비가 덜 되었다면 안하는게 좋겠다.
좋은 매니저, 나쁜 매니저 : 알파 긱
팀이나 외부 사람과 멘토링을 하다 보면 '알파 긱(Alpha geek)'을 만날 때가 많다. 알파 긱은 팀에서 인정받는 최고의 개발자로, 늘 정답을 말하며 어떤 문제도 풀어내는 사람이다. 이들은 뭐든 뛰어나야 하는 '탁월함의 문화'를 만들려고 하지만 결국에는 '두려움의 문화'를 만드는 경향이 있다.
알파 긱이 좋은 매니저일 경우에는, 두려운 존재이기도 하지만 젊은 개발자에게 많은 영감을 주기도 하지만, 팀원이 그의 하대를 견디며 실력을 존경하기도 한다.
나쁜 매니저의 경우라면, 자기 의견이 반영되지 않은 결과는 아무도 가져갈 수 없게 하거나, 자기가 아는 것을 주위 사람이 모르면 즐거워하며 무지를 지적하기도 한다. 자신이 개발한 시스템에 대해 사람들이 불평하거나 기술적 결정을 비판하면 매우 공격적으로 반응한다.
알파 긱 성향은 대개 개발자가 처음 멘토 역할을 맡을 때쯤에 드러나기 시작한다. 만약 기술적인 부분이 뛰어난 데도 사람이 다가와서 도움을 부탁하지 않는다면, 자신에게 알파 긱 성향이 없는지 스스로 물어보자.
☻ 겪어보니 이런 사람들은 시간이 지날수록 스스로 외톨이가 되더라...
이런 부류의 사람들은 본인들이 무슨 잘못이 있는지 모른고 상대방 걱정따위는 신경도 안쓴다.
그러니 이런 부류의 사람들 때문에 내 스스로를 망가뜨리거나 낭비하지 마라.
멘토를 위한 핵심 요약
1. 호기심과 열린 마음 갖기
멘토링은 호기심을 키우고 새로운 눈으로 세상을 바라볼 좋은 기회다. 멘티의 질문은 새로운 사람의 눈을 통해 조직의 명확치 않은 것들을 관찰하는 시작점이 된다. 이해했다 여겼던 것에서 명확하지 않은 부분을 찾고, 일하는 동안 가치 있는 것이 무엇인지 다시 의문을 던질 기회를 준다.
2. 상대방의 언어를 듣고 말하기
멘토링은 경청을 연습할 좋은 기회다. 질문을 잘 듣지 않으면 좋은 대답을 할 수 없다. 신입 사원, 주니어 팀원과 업무를 잘 수행하려면, 몇 번이나 시간을 들여 노력을 쏟더라도 그들이 이해하는 방식으로 경청하고 소통해야 한다.
3. 인맥 관리하기
멘토링은 인맥을 쌓는 좋은 방법이다. 멘토 중 누군가가 직장을 소개해줄 수도, 미래에 함께 일을 할 수도 있다.
☻ 연차가 이제 구인공고에도 안나올 연차다 보니 확실히 인맥이 중요하다;
테크리드
테크리드는 매니저는 아니지만, 리더십이 필요한 자리다.
테크리드의 역할은 회사마다, 심지어 같은 회사에서도 팀마다 다를 수 있다. 그러나 테크와 리더의 합성어란 직함에서 알 수 있듯이 태크리드는 기술과 리더십이 모두 필요하며, 지속되는 직책이 아니라 일시적으로 부여되는 책임이다.
테크리드의 역할은 경력 사다리에서 특정한 지점이 아니라 모든 개발자가 시니어 수준이 되면 맡을 수 있는 몇 가지 책무라고 정의할 수 있다.
* 정기적인 원온원 미팅(주 1회)
* 경력 성장, 목표 진행, 개선된 영역 및 명시적인 칭찬 등에 대한 정기적 피드백
* 프로젝트 업무, 외부 교육 또는 멘토링 등을 통해서 팀원의 성장을 돕는 교육과 지원 보고서 작업
테크리드는 팀 전체의 성장을 위해 기술 프로젝트 리더로 활동하면서, 대규모 프로젝트에서 자신의 전문성을 살려 팀에 기여한다. 독립적인 결정을 할 수 있으며, 기술 팀과 비기술 팀 사이의 협력에서 중요한 역할을 한다. 여기서 특별히 기술적 업무에 관련된 것이 없다는 것을 알았을 것이다. 기술은 시니어 개발자의 역할이다. 따라서 테크리드의 역할을 팀에서 가장 경험이 많거나 실력 있는 개발자로 연결지어 생각하는 것은 잘못된 생각이다. 테크리드에게는 기술 전문성 이상으로 사람을 다루는 기술이 필요하다. 그리고 또 다른 중요한 기술인 프로젝트 관리 기술이 필요하다.
☻ 참 부담감 많이 느끼는 직책이다.
테크리드 되기
테크리드가 된다는 건 권위(Authority) 없이 영향력을 행상하는 것을 연습하는 것이다. 테크리드로서 팀을 이끌지만 모든 팀원은 개발 매니저에게 보고한다. 적절한 작업의 우선순위를 정하기 위해 팀원뿐 아니라 상사에게도 영향력을 행사해야 한다.
* 모든 훌륭한 테크리드가 아는 한 가지 비결
테크리드가 발휘해야 할 리더십 중 하나는 상사나 프로덕트 매니저 같은 다른 이해 관계자가 팀의 업무 몰입을 방해하지 않도록 회의 일정을 잡는 것이다.
☻ 팀원뿐 아니라 상사에게도 영향력을 미치는 직책이다.
진짜 참 부담감 많이 느끼는 직책이다.
테크리드의 기본 역할
테크리드가 가장 우선시해야 하는 것은 프로젝트를 계속 진행할 수 있도록 넓은 관점에서 업무를 조망하는 것이다.
테크리드는 새 기능을 개발하기 위해 과로하기 십상인데, 이는 때로 팀이 실패하는 원인이 되곤 한다. 테크리드가 되는 과정에서 소프트웨어 개발자, 시스템 아키텍처, 비즈니스 분석가, 팀 리더로서 직접 할 일과 다른 사람에게 위임할 일을 구분할 줄 알아야 한다.
* 테크리드는 끔찍한 자리인가요?
테크리드는 개인으로 회사에 기여할 수 있는 시니어 개발자보다 광범위한 책임을 맡습니다. 테크리드는 프로젝트의 아키텍처를 정하고 개발 업무의 실제 계획을 차근차근 밟아 프로젝트를 끝내야 하는 자리입니다. 팀원이 매니지먼트 책임을 걱정하지 않도록 하면서 프로젝트의 요구사항을 충분히 이해시키고, 업무를 계획하고, 팀이 효율적으로 일하도록 해야 합니다. 테크리드를 위한 교육도 없지요. 게다가 거의 모든 매니저는 테크리드가 되기 전에 해왔던 개발 업무도 계속 하기를 바랍니다.
* 복잡한 프로젝트 관리하기
프로젝트 관리가 모든 세부 사항을 관리하는 것이 아닌데, 어떤 조직에서는 세부 사항을 지나치게 점검하는 경우가 있다. 이 경우 개발자가 앞으로의 일을 생각하고 현재 무엇을 하고 왜 하는지 자신들이 왜 여기에 있는지 진정으로 질문하고 배우게 하기보다는 프로젝트 매니저에게 지나치게 의지하게 만들기 때문이다.
궁극적으로 '계획의 가치'는 계획을 얼마나 완벽하게 수행하는지, 사전에 모든 세부사항을 미리 파악했는지, 장차 벌어질 일을 예측하는지에 있지 않다. '계획의 가치'는 실제 업무를 시작하기 전에 스스로 프로젝트를 어느 정도까지 깊이 있게 생각할 수 있는지에 있다. 계획을 세우는 데 있어서 어느 선까지 합리적으로 예측하고 계획을 수립하는지가 목표이지, 계획이 얼마나 정확한지에 대해서는 많은 시간을 쓸 만큼 중요치 않다.
* 설명의 중요성
팀원에게 기초적인 개념과 동기를 설명하는 자리를 만드는 것을 주저하지 않는다. 왜냐하면 이런 자리는 팀원의 생각을 넓혀주고 팀원들이 내 판단과 충고를 신뢰하게 만들기 때문이다. 무엇보다 이런 노력이 결국 우리에게 좋은 변화를 가져온다. 시간을 들여 설명하는 건 매우 중요하다.
* 테크리드가 되고 싶지 않아요.
매니저 역할을 강요하는 것은 절대로 해서는 안 됩니다. 그 무거운 책임을 질 준비가 되지 않았다면 책임을 맡지 말아야 합니다. 아직 배울 것이 많다고 느껴 기술에 깊이 빠지는 것은 잘못이 아닙니다.
☻ 그 동안은 이 무거운 책임을 질 마음의 준비가 되지 않아서 멀리했다.
프로젝트 관리에 도움 되는 가이드라인
1. 작업을 작게 나눈다.
큰 성과를 낼 수 있는 업무를 작은 업무로 나누고, 큰 단위의 작업에서 작은 단위로 나누는 일을 반복한다.
작업 단위를 어느 정도 작게 나눈 다음에는 작업 순서에 주의한다.
2. 일을 어렵게 만드는 세부 사항과 문제가 될 수 있는 부분은 끝까지 신경 쓴다.
세부 사항을 더 파악하는 것이 의미가 없다는 생각이 들 때까지 세부 사항을 정리해보자.
3. 프로젝트를 시작하고 진행하며 계획을 수정한다.
잘 짠 계획은 프로젝트가 얼마나 진행됐고 언제 완료될지를 아는 데 도움이 된다. 계획이 어긋날 때면 모든 사람에게 상태를 알려야 한다. 이런 상황에서는 완료까지 얼마나 남았는지 추측하지 말고 마일스톤을 명확하게 지적하고 예상되는 남은 작업의 윤곽을 설명해야 한다.
4. 계획 프로세스에서 얻은 통찰로 변경된 요구사항을 관리한다.
도중에 요구사항이 바뀌면 앞서 분석한 내용을 토대로 변경 사항을 적용한다. 변경에 따른 비용을 명확히 하고, 마감 시간을 맞추려면 어느 정도 작업이 필요한지를 알아야 하며 우선순위를 정하고, 요구사항을 제외하거나 기능, 품질, 완료 일자를 잘 조율해야 작업할 때 도움이 된다.
5. 프로젝트 완료 시점이 가까워지면 세부 사항을 다시 검토한다.
마무리를 위한 세부사항을 꼼꼼히 챙길 때다. 무엇을 빠뜨렸는가? 테스트는 제대로 하고 있나? 검증은 잘 되고 있나?
☻ 대부분의 일을 잘하는 방법은 거의 유사하다.
좋은 매니저, 나쁜 매니저 : 프로세스 독재자
프로세스 독재자는 올바르게 구현된 설계를 따르면 팀의 모든 문제를 해결할 수 있는 '프로세스'가 있다고 믿는다.
프로세스 독재자가 가장 힘들어하는 것은 사람들 대부분이 자신만큼 프로세스를 잘 따르지 못한다는 사실을 알지 못할 때다. 또한 프로세스 독재자는 프로세스의 유연성과 예기치 않은 변경의 불가피함을 이해하기보다 모든 문제가 최선의 프로세스를 제대로 준수하지 않는 데 있다고 믿는다.
프로세스 독재자의 반대는 프로세스를 완전히 포기한 매니저가 아니라 프로세스가 팀과 업무의 요구 조건을 충족해야 한다는 것을 이해한 사람이다. 역설적이게도 애자일 방법론은 종종 엄격하게 적용되는데, 애자일 선언은 '건강한 프로세스 리더십'을 훌륭히 요약한 것이다.
* 프로세스와 도구에 우선하는 개개인과 상호작용
* 완벽한 문서화보다는 작동하는 소프트웨어
* 계약 협상보다는 고객 협력
* 계획을 고집하기보다는 변화에 유연한 대응
☻ 예전에는 프로세스를 빡빡하게 잘 지키지 않으면 스트레스 받고 그랬는데,
지금은 조금 모자란 것들은 내가 채워주고 지원해주고 그렇게 하는게
프로세스를 완벽하게 지켜서 나오는 팀워크나 성과, 효율성보다 훨씬 더 높다고 느낀다.
훌륭한 테크리드가 되는 방법
* 아키텍처 이해하기
테크리드로서 지원해야 할 아키텍처에 관해 충분히 이해하지 못했따는 느낌이 든다면 시간을 투자해야 한다.
1. 아키텍처에 대해 학습하여 감을 잡고 시각화해본다.
2. 데이터가 어디에 있고 어떻게 흘러가는지 파악한다.
3. 제품의 핵심 로직은 어디고, 이 부분이 어떻게 반영됐는지 이해한다.
* 팀 플레이어 되기
혼자서 재미있는 작업을 전부 하고 있다면 당장 멈추자. 기술적으로 필요한데 까다롭고, 지루하고, 성가신 작업이 무엇인지 살펴보고 이런 작업을 해결할 수 있는지 고민해야 한다. 코드에서 별로 재미없는 부분을 작업하다 보면 프로세스 어느 지점에 문제가 있는지 많이 배울 수 있다. 따분하고 실망스러운 프로젝트의 경우 경험 많은 개발자로서 이런 부분을 검토하는 데 시간을 쓴다면 개선할 부분을 분명하게 파악할 수 있다.
* 기술 결정을 주도하기
테크리드는 직접 결정할지, 팀의 전문가에게 결정을 위임할지, 팀원 전체가 모여 결정할지를 정한다. 어떤 경우라도 논의 중인 사항은 명확하게 하고 결과를 가지고 충분히 소통한다.
* 의사소통
팀의 생산성이 당신의 생산성보다 더 중요하다. 많은 경우에 의사소통으로 인한 비용이 든다는 의미다. 모든 팀원이 회의에 참석하는 대신 당신이 팀을 대표해서 팀원들의 요구사항을 전달하고, 회의 결과를 공유해야 한다. 성공한 리더는 글을 잘 쓰고, 주의 깊에 읽으며, 그룹 앞에서 나서서 말을 잘할 수 있다.
의사소통 과정에서 경청을 꼭 기억해두어야 한다. 다른 사람에게 발언 기회를 주고 그 사람의 말을 귀담아 듣는다. 다른 사람의 말을 확실하게 이해하기 위해서 그 사람의 말을 반복해보는 연습이 필요하다. 이때, 다른 사람의 말을 잘 듣고 자신의 언어로 바꾸는 방법을 배운다.
☻ 일단 지식적으로도 공부할께 너무 많고, 부족한 면도 채울 수 있게 스스로 성장도 해야 한다;
특별히 새로운 기술의 발전로 해결책의 패러다임이 크게 변하지 않는 이상은 무언가를 결정하는데 있어서
결론이 이랬다 저랬다 하지 않도록 자신만의 기준점(결정의 흐름이라고 해야하나..)을 확고히 다져놓는게 중요한것 같다.
문화 개선
문화를 만드는 것도 시니어 개발 리더의 역할이다. 팀이 성장하고 발전함에 따라 다른 중요한 인프라에 신경을 쓰는 것만큼 팀 문화에도 신경을 써야 한다.
스타트업 문화를 매력적으로 느끼는 많은 사람에게는 '구조'와 '과정'이 무의미하고 최악의 경우 오히려 방해가 된다고 여겨진다. 회의론자들과 구조를 논의할 때는 논의 방법을 바꾸기도 한다. 구조에 관해 논의하기보다는 학습에 관해 이야기한다. 과정 대신에 투명성을 이야기한다.
구조와 과정에 가치가 있기 때문에 시스템을 만드는 것이 아니다. 성공과 실수를 통해 학습하고 실패로부터 학습한 교훈을 투명하게 공유하고 싶다면 시스템을 만들어야 한다. 이러한 학습과 공유는 시간이 갈수록 조직이 더 안정되고 성장하는 방법이다.
☻ 문화는 여기저기 좋다는 말들만 입밖으로 전달해서는 안된다.
나 부터 실천하고 지키면서 전파하고 따라오게 만들어야 쉽게 개선된다.
문화 만들기
문화는 회사가 발전하면서 나타나는 자연스러운 현상이며, 문화가 존재한다고 믿지 못하면 빠르게 문제가 될 수 있다. 리더는 의식적으로 팀 문화를 이끌어야 하고, 잘 이끌기 위해서는 먼저 문화가 무엇을 의미하는지 이해해야 한다.
문화란 무엇인가? 문화는 일반적으로 사람들 사이에 존재하는 무언의 규칙이다. 서로 다른 입장의 사람들이나 서로 다른 관계의 사람들을 대하는 방법도 문화다. 하지만 모든 사람들이 완전히 똑같은 가치를 가진다는 의미는 아니다.
따라서 사람들은 문화적 가치가 아닌 다른 기준으로 결정을 하기도 하지만, 개인의 요구보다 그룹의 요구를 더 우선시하는 복잡한 환경에서의 문화는 팀으로서 우리가 함께 일할 수 있도록 하는 접착제이고 불확실할 때마다 결정을 내릴 수 있도록 돕는다.
☻ 우리가 함께 일할 수 있도록 하는 접착제이고 불확실할 때마다 결정을 내릴 수 있도록 돕는 우리 사이에 존재하는 무언의 규칙!
장애 사후 분석(Postmortem)
* 비난하거나 지적하고 싶은 충동을 억제하라
비난은 직원들이 실수를 두려워하게 만들 뿐이다.
* 사건의 상황을 살펴보고 맥락을 이해하라.
장애요인 목록을 잘 정리해두면, 개선을 위한 패턴이나 개선이 필요한 부분을 알 수 있고 학습 검토에서 진짜 학습이 일어난다.
* 중요하게 가져가야 할 것과 그렇지 않은 것에 대해 현실적으로 접근하라.
팀원들의 업무 과정에서 발견된 모든 문제를 해결해야 한다는 인상을 주지 않도록 하라.
수많은 학습 검토는 길고 긴 긴 '개선 목록'을 정리하고서야 끝나지만 모든 것을 해낼 수는 없을 것이다. 사실, 모든 것을 다하려고 한다면 아무것도 끝내지 못할 것이다. 정말 위험한 문제와 향후에 상당히 문제가 될 수 있는 두 가지만 선택하라. 그리고 나머지는 내려놓아야 한다.
☻ 특정 누군가의 실수가 아닌 우리 모두의 실수이다.
좋은 매니저는 누구인가
임백준님의 기고
경영층이 개발 팀에게 요구하는 사항과 개발팀의 현실을 조율하고, 소프트웨어 사용자의 목소리를 경청하고, 채용과 비용절감을 고민하고, 소프트웨어 제품의 출시 기간을 결정하고, 인사 부서와 함께 직원의 복지 문제를 논의하고, 평가를 통해 연봉과 보너스 수준을 결정하고, 개발자의 불만과 의견을 접수하고, 개발자 문화를 어떻게 개선할지 고민하는 일.
매니저를 통한 맥락에 대한 이해와 통찰의 안목이 넓어짐.
앞으로 매니저를 하려고 마음 먹은 사람이나 이미 매니저의 길을 걷는 사람이 반드시 기억해야 하는 중요한 논점.
매니저는 기술의 막다른 골목이 아니다. 매니저 트랙과 기술 트랙은 서로 만나지 않는 두 개의 평행선이 아니다. 그것은 서로 수시로 교차하는 나선형이다. 매니저는 언제나 기술현업에 돌아갈 준비가 되어 있어야 하고, 코딩 업무를 보는 사람도 상황에 따라 hands-off 매니저 역할을 수행할 수 있어야 한다.
좋은 매니저는 후배를 성장시키는 사람이다. 잘난 후배는 더 잘나게 만들고, 못난 후배는 자신감을 갖도록 도와주는 사람이다. 자기 장점이 무엇인지 깨닫게 해주고, 배움의 기회를 만들어주고, 자기 역량을 발휘하여 스포트라이트를 받게 해주는 사람이다. 후배가 너무 환히 빛나서 자신을 앞질러 가거나 다른 회사가 데려간다 해도 진심으로 개의치 않는 사람이다. 후배들의 앞 길을 있는 힘을 다해 열어주고, 이끌어주고, 밀어주는 사람이다. 그게 좋은 매니저다. 마음이 넓고 그릇이 커야 한다.
☻ 마음이 넓고 그릇이 커야 한다.
뉴비 프로젝트 매니저를 위한 이야기 한 조각
배상언님의 기고
공유의 힘, 성숙되지 않은 조직에서는 정보가 공유되지 않는 경우를 흔하게 볼 수 있습니다.
첫 번째, 작업이 끝난 뒤 종료일까지 일하지 않기 위해서입니다.
두 번째, 본인의 업무를 좋아하는 담당자라면 스스로 만족할 때까지 노력하고 싶기 때문입니다.
공유하지 않는 것은 어떻게 보면 인간의 본능이란 생각도 듭니다. 내가 준비하고 있는 것을 남에게 알려주고 싶어하지 않는 겁니다. 사람들은 본인의 일이 공유되거나 또는 공개되는 순간 마음이 편하지 않습니다. 나만 알고 있던 것들을 남들도 알게 됨으로써 압박을 느끼고 긴장하게 됩니다.
반대로 생각해봅시다. 나만의 일을 공유했을 때 동료들의 칭찬, 격려 그리고 감사의 마음을 받게되면 사람들은 쉽게 그리고 자주 공유하고자 할 것입니다. 공유가 편해지는 최소한의 조건은 팀 내에서 나의 안전입니다. 그렇다면 안전한 환경은 어떻게 만들 수 있을까요? 안전한 환경이란 솔직히 표현하자면 덜 위험한 환경입니다. 이것은 문화와 프로세스를 통해서 만들 수 있습니다.
투명하고 솔직하게 공유되는 정보는, 그 정보가 나쁜 내용을 가지고 있더라도 비판해서는 안 된다고 강조하고 싶습니다. 투명하게 모든 사람에게 공유한다는 것이 누구에게는 용기를 낸 행동일 수도 있습니다. 우리는 그러한 용기에 감사해야 합니다. 그리고 그런 문화를 만들어야 합니다.
☻ 안전한 환경보다는 덜 위험한 환경. 같이 일하는 동료들을 신뢰하고 공유하자.