<div id="readability-page-1" class="page"><div> <a href="http://www.yes24.com/Product/Goods/87336637" target="_blank" rel="noopener">http://www.yes24.com/Product/Goods/87336637</a>
<figure id="og_1650689966851" contenteditable="false" data-ke-type="opengraph" data-ke-align="alignCenter" data-og-type="book" data-og-title="개발 7년차, 매니저 1일차 - YES24" data-og-description="『개발 7년차, 매니저 1일차』는 사수, 멘토, 팀장, CTO까지 직책별 관리를 기술한 대백과이다. 개발자도 꼭 알아야 하는 소프트 스킬, 사람 및 조직 관리 노하우 수록하였으며 개발 팀을 성공으로" data-og-host="www.yes24.com" data-og-source-url="http://www.yes24.com/Product/Goods/87336637" data-og-url="http://www.yes24.com/Product/Goods/87336637" data-og-image="https://scrap.kakaocdn.net/dn/Vyosv/hyN8D3fJhb/LckggZi2jmqeNAQcb56kmK/img.jpg?width=823&amp;height=1200&amp;face=253_311_564_650,https://scrap.kakaocdn.net/dn/iEZEH/hyN8Fmu95B/qCdEOQvNZ7imS27biuPNO1/img.jpg?width=823&amp;height=1200&amp;face=253_311_564_650,https://scrap.kakaocdn.net/dn/u6EvN/hyN8Ccbj10/bM7g8cJzHLU3QU8hHjVrS0/img.jpg?width=823&amp;height=1200&amp;face=253_311_564_650"><a href="http://www.yes24.com/Product/Goods/87336637" target="_blank" rel="noopener" data-source-url="http://www.yes24.com/Product/Goods/87336637">

<div>
개발 7년차, 매니저 1일차 - YES24
『개발 7년차, 매니저 1일차』는 사수, 멘토, 팀장, CTO까지 직책별 관리를 기술한 대백과이다. 개발자도 꼭 알아야 하는 소프트 스킬, 사람 및 조직 관리 노하우 수록하였으며 개발 팀을 성공으로
www.yes24.com
</div>
</a><img src="https://scrap.kakaocdn.net/dn/Vyosv/hyN8D3fJhb/LckggZi2jmqeNAQcb56kmK/img.jpg?width=823&amp;height=1200&amp;face=253_311_564_650,https://scrap.kakaocdn.net/dn/iEZEH/hyN8Fmu95B/qCdEOQvNZ7imS27biuPNO1/img.jpg?width=823&amp;height=1200&amp;face=253_311_564_650,https://scrap.kakaocdn.net/dn/u6EvN/hyN8Ccbj10/bM7g8cJzHLU3QU8hHjVrS0/img.jpg?width=823&amp;height=1200&amp;face=253_311_564_650"></figure>
어느덧 개발을 시작한지 횟수로 8년이 되었다. 개발하는걸 그렇게 좋아하지는 않았지만 문제를 해결해 나가는 걸 즐겨왔었고 좋은 사람들과 함께 일하는걸 좋아했다.

그래서 함께 개발하고 함께 오래동안 같이 일하는 문화가 되는것을 주니어때부터 계속해서 생각해왔던 것 같다.

현재 직장에서 일을 하면서 감사하게도 기회가 되어 팀내 작은 테크리드를 하고 있다. 8년간 일을하면서 아쉬웠고 좋았던 부분을 생각하며 어떻게하면 팀원분들과 좋은 문화속에서 오랫동안 일을 할 수 있을까 고민을 많이 했던 것 같다.

그렇게 리딩을 1년, 2년정도 하다보니 노하우가 쌓이면서 나름 좋은 문화의 팀 빌딩을 하고 있다고 생각했다. 그러다 문득 내가 하고 있는 것이 마이크로 매니징이 아닌지 제대로 동료분들에게 재밌는 업무, 성장할 수 있는 업무를 드리고 있는건지 또 나를 포함해서 그들의 자율성을 내가 빼앗아서 서로의 성장의 기회를 막고 있는건 아닌지에 대한 두려움에 쌓인적이 있다.&nbsp;

그래서 스스로 자기 객관화를 할 수 있도록 책을 많이 찾아보고 타 팀의 문화를 보면서 많은 공부를 하고 있다.
그 중 이번에 읽었던 개발 7년차, 매니저 1일차는 많은 부분을 반성하게 만들었고 더 좋은 인사이트를 얻게 만들어줬다.&nbsp;

책을 읽고 난 나의 결론은 모든 건 환경과 프로젝트의 성격에 따라 달라지겠지만 아래 내용은 명심하고 가자는 마음을 가지게 되었다.&nbsp;
- 신뢰를 쌓고 서로에게 약해질 수 있고 의지할 수 있는 환경을 만들자.
- 용기내어 공유할 수 있는 문화를 만들자.
- 자율성을 주고 위임할 수 있도록 하자.
- 그러기 위해서 대화를 많이하자.

최고로 잘할할수는 없겠지만 결심한 마음대로 잘 실천할 수 있도록 최선을 다해보자.


<h4 data-ke-size="size20">인상깊었던 책 내용</h4>
원온원 미팅
<ul data-ke-list-type="disc">
<li>신뢰가 바탕이된 인간적인 연결이 좋은팀의 뼈대</li>
<li>신뢰가 쌓이려면 상대 앞에서 기꺼이 약해질 수 있는 능력과 의지가 필요</li>
<li>팀원의 삶 주제로 몇분간의 대화가 가능해야 한다.</li>
<li>정기적인 온앤온은 엔진오일 확인하는 것과 같아서 시기를 놓치면 언젠가 고속도로에 서있게 되는 최악의 상황에 직면한다.</li>
</ul>
피드백
<ul data-ke-list-type="disc">
<li>성과 평가만 하는 피드백만을 진행하면 안된다.</li>
<li>칭찬은 공개, 비판은 비공개로</li>
</ul>
경청
<ul data-ke-list-type="disc">
<li>상대방의 말에 경청하는 것 부터가 시작이다.</li>
</ul>
알파긱 (alpha geek)
<ul data-ke-list-type="disc">
<li>타인의 실수를 얕잡아보고 타인의 결과물을 말없이 수정하고 팀원의 성과를 독식하는 매니저</li>
<li>개발을 잘할 수 있지만 이런 알파긱에게 매니징을 맡기는건 조심해야한다.</li>
</ul>
인맥
<ul data-ke-list-type="disc">
<li>개발의 세상은 좁다. 인맥의 힘에 따라 성공하고 실패하기에 인맥에 집중하자.</li>
</ul>
테크리드
<ul data-ke-list-type="disc">
<li>기술은 시니어 개발자의 필수조건이기에 기술만 보고 테크리드를 선정하는건 잘못된 선택이다.</li>
<li>테크리드는 코드를 혼자 이끌어간다고 생각하면 안되고 모든 문제를 공유하고 문제를 같이 이끌어 나가야한다.</li>
<li>좋은 테크리드 되기
<ul data-ke-list-type="disc">
<li>아키텍처를 이해한다.</li>
<li>팀원 전체가 역량을 키울 수 있도록 팀 플레이어를 한다.</li>
<li>기술 결정을 테크리드가 독단적으로 하기보다는 기술결정을 팀원전체가 결정할지 아님 테크리드가 주도로 할지등의 기술 결정의 방법을 공유해야한다.</li>
<li>팀의 생산성을 위해서 팀원들 대신 회의에 혼자 참여하고 회의 결과를 공유하라. 의사소통이 테크리드에 큰 역할이다.</li>
</ul>
</li>
<li>매니저
<ul data-ke-list-type="disc">
<li>좋은 매니저는 착한사람도 일을 잘 하는사람이 아닌 후배를 성장시키는 사람이다.</li>
<li>팀은 팀원 개개인의 상태이다. 건강한 팀원을 위해서는 매니저로서 당신이 각 팀원들에게 큰 영향을 끼친다는걸 명심하자.</li>
<li>마이크로 매내징은 고성과자를 한순간에 저성과자로 만들 수 있다. 위임과 마이크로매니징 사이를 구분하자. (위임은 포기가 아니다.)
<ul data-ke-list-type="disc">
<li>마이크로 매니징을 하기 전 미리 확인할 수 있는 지표는 직접 시스템 정보로 확인해라</li>
<li>팀의 표준양식을 도입하라</li>
<li>좋은정보든 나쁜 정보든 정보를 개방하게 하자</li>
</ul>
</li>
</ul>
</li>
</ul>
- 정답은 없고 주어진 상황에 맞게 환경과 프로젝트 성격을 이해하고 그속에서 가장 효율적있는 프로세스를 만들어야 한다.
- 공유는 그 정보가 나쁜 내용을 가지고 있다고 할지라도 비판해서는 안된다. 투명하게 모든 사람에게 공유한다는 것이 누구에게는 용기를 낸 행동이고 우리는 그 용기에 감사해야하며 또 그런 문화를 만들 수 있도록 노력해야한다. 
</div></div>

wedul

http://www.yes24.com/Product/Goods/87336637
어느덧 개발을 시작한지 횟수로 8년이 되었다. 개발하는걸 그렇게 좋아하지는 않았지만 문제를 해결해 나가는 걸 즐겨왔었고 좋은 사람들과 함께 일하는걸 좋아했다.
 
그래서 함께 개발하고 함께 오래동안 같이 일하는 문화가 되는것을 주니어때부터 계속해서 생각해왔던 것 같다.
 
현재 직장에서 일을 하면서 감사하게도 기회가 되어 팀내 작은 테크리드를 하고 있다. 8년간 일을하면서 아쉬웠고 좋았던 부분을 생각하며 어떻게하면 팀원분들과 좋은 문화속에서 오랫동안 일을 할 수 있을까 고민을 많이 했던 것 같다.
 
그렇게 리딩을 1년, 2년정도 하다보니 노하우가 쌓이면서 나름 좋은 문화의 팀 빌딩을 하고 있다고 생각했다. 그러다 문득 내가 하고 있는 것이 마이크로 매니징이 아닌지 제대로 동료분들에게 재밌는 업무, 성장할 수 있는 업무를 드리고 있는건지 또 나를 포함해서 그들의 자율성을 내가 빼앗아서 서로의 성장의 기회를 막고 있는건 아닌지에 대한 두려움에 쌓인적이 있다. 
 
그래서 스스로 자기 객관화를 할 수 있도록 책을 많이 찾아보고 타 팀의 문화를 보면서 많은 공부를 하고 있다.
그 중 이번에 읽었던 개발 7년차, 매니저 1일차는 많은 부분을 반성하게 만들었고 더 좋은 인사이트를 얻게 만들어줬다. 
 
책을 읽고 난 나의 결론은 모든 건 환경과 프로젝트의 성격에 따라 달라지겠지만 아래 내용은 명심하고 가자는 마음을 가지게 되었다. 
- 신뢰를 쌓고 서로에게 약해질 수 있고 의지할 수 있는 환경을 만들자.
- 용기내어 공유할 수 있는 문화를 만들자.
- 자율성을 주고 위임할 수 있도록 하자.
- 그러기 위해서 대화를 많이하자.
 
최고로 잘할할수는 없겠지만 결심한 마음대로 잘 실천할 수 있도록 최선을 다해보자.
 
 
인상깊었던 책 내용
원온원 미팅
신뢰가 바탕이된 인간적인 연결이 좋은팀의 뼈대
신뢰가 쌓이려면 상대 앞에서 기꺼이 약해질 수 있는 능력과 의지가 필요
팀원의 삶 주제로 몇분간의 대화가 가능해야 한다.
정기적인 온앤온은 엔진오일 확인하는 것과 같아서 시기를 놓치면 언젠가 고속도로에 서있게 되는 최악의 상황에 직면한다.
피드백
성과 평가만 하는 피드백만을 진행하면 안된다.
칭찬은 공개, 비판은 비공개로
경청
상대방의 말에 경청하는 것 부터가 시작이다.
알파긱 (alpha geek)
타인의 실수를 얕잡아보고 타인의 결과물을 말없이 수정하고 팀원의 성과를 독식하는 매니저
개발을 잘할 수 있지만 이런 알파긱에게 매니징을 맡기는건 조심해야한다.
인맥
개발의 세상은 좁다. 인맥의 힘에 따라 성공하고 실패하기에 인맥에 집중하자.
테크리드
기술은 시니어 개발자의 필수조건이기에 기술만 보고 테크리드를 선정하는건 잘못된 선택이다.
테크리드는 코드를 혼자 이끌어간다고 생각하면 안되고 모든 문제를 공유하고 문제를 같이 이끌어 나가야한다.
좋은 테크리드 되기
아키텍처를 이해한다.
팀원 전체가 역량을 키울 수 있도록 팀 플레이어를 한다.
기술 결정을 테크리드가 독단적으로 하기보다는 기술결정을 팀원전체가 결정할지 아님 테크리드가 주도로 할지등의 기술 결정의 방법을 공유해야한다.
팀의 생산성을 위해서 팀원들 대신 회의에 혼자 참여하고 회의 결과를 공유하라. 의사소통이 테크리드에 큰 역할이다.
매니저
좋은 매니저는 착한사람도 일을 잘 하는사람이 아닌 후배를 성장시키는 사람이다.
팀은 팀원 개개인의 상태이다. 건강한 팀원을 위해서는 매니저로서 당신이 각 팀원들에게 큰 영향을 끼친다는걸 명심하자.
마이크로 매내징은 고성과자를 한순간에 저성과자로 만들 수 있다. 위임과 마이크로매니징 사이를 구분하자. (위임은 포기가 아니다.)
마이크로 매니징을 하기 전 미리 확인할 수 있는 지표는 직접 시스템 정보로 확인해라
팀의 표준양식을 도입하라
좋은정보든 나쁜 정보든 정보를 개방하게 하자
- 정답은 없고 주어진 상황에 맞게 환경과 프로젝트 성격을 이해하고 그속에서 가장 효율적있는 프로세스를 만들어야 한다.
- 공유는 그 정보가 나쁜 내용을 가지고 있다고 할지라도 비판해서는 안된다. 투명하게 모든 사람에게 공유한다는 것이 누구에게는 용기를 낸 행동이고 우리는 그 용기에 감사해야하며 또 그런 문화를 만들 수 있도록 노력해야한다.

개발 7년차, 매니저 1일차

댓글