<div id="readability-page-1" class="page"><div><h2 id="976e">Q. 미정님처럼 리더가 되고 싶은 여성 개발자들에게 조언을 부탁드려요.</h2><p id="f8cf">저는 14년 동안 업으로 개발을 해오면서 약 7년 정도 리더 역할을 해오고 있어요. 다양한 개발자 동료 혹은 커피챗을 통해 새롭게 만난 분들로부터 유사한 질문을 종종 받았어요.</p><p id="1b38">개발 리더는 개발자의 역량과 리더의 역량을 잘 갖춰야겠죠. 리더가 팀의 적절한 의사결정을 내리기 위해 당연히 개발 역량이 기반이 되어야 하고, 일과 사람을 관리하는 리더의 역량이 모두 필요해요.</p><p id="994e">많은 분이 개발 역량에만 초점을 두고 애쓰는 것 같아요. 개발 공부를 열심히 한다거나, 시간을 더 투자해서 개발 업무를 남들보다 많이 한다거나. 하지만, 리더의 기회는 다른 것에서 주어지는 경우가 많다고 생각해요. 내가 어떻게 문제를 정의하는지, 해결책을 찾아가는 과정이 어떤지, 팀과 소통하고 협업하는 방식은 어떤지. 이러한 것들이 드러나야 일과 사람을 관리할 수 있는 리더의 기회가 주어질 거예요.</p><p id="9150">개발 역량은 이미 잘하고 있거나 충분히 노력하고 있을 거예요. 내가 뭘 더 공부하고 얼마나 더 일해야 하나에 애쓰지 말고, 이미 잘 하고있는 걸 드러내는 데 애쓰라고 말해주고 싶어요.</p><h2 id="c33e">Q. 작업에 대한 기록을 평소에도 하시나요?</h2><p id="fa52">우선, 저는 원래 기록을 좋아하는 사람이에요. 어릴 때부터 일기 쓰던 습관이 지금까지 이어질 정도로 기록에 대한 거부감이 없는 사람임을 미리 밝혀요.</p><p id="b7ef">일을 할 때 다양한 기록을 유지하고 있어요. 우선 출근하면 가장 먼저 하는 일이 오늘 해야 할 일을 나열하고, 나열한 일의 우선순위를 정해요. 그리고 마지막으로 필요한 시간을 측정하고 할 수 있는 일을 확정해요.</p><p id="8d19">또 다른 종류의 기록을 요즘 시작했는데요. 바로, 실제로 일을 하면서 일의 맥락이 바뀔 때마다 기록하는 거예요. 몇 시부터 몇 시까지 어떤 일을 했는지. 이 기록을 시작한 이유는 시간 관리가 잘 안된다고 느껴서예요. 팀 2개를 리드하고 지속적으로 맥락이 많아지다 보니 시간 관리가 어렵더라고요. 그래서 내가 실제로 중요하지 않은 일에 시간을 쏟고 있는 건 아닌지 추적해 보고 진짜 중요한 일에 시간을 쓰고 싶어요.</p><figure></figure><p id="215d">그 외, 팀 문화 관점에서도 ‘기록’ 은 여전히 중요한 키워드예요. 저는 팀이 투명할 때 팀이 더 중요한 일을 잘할 수 있다고 믿어요. 데일리 스크럼 쓰레드, 데일리 리뷰 쓰레드, Weekly 노트, OKR 회고/수립 노트 등 팀의 문화에는 ‘기록’ 이라는 장치가 많아요.</p><h2 id="d60c">Q. 내가 중요하다고 생각하는 원칙을 팀원들과 동기화 할 수 있는 방법은 무엇인가요?</h2><p id="8dfc">기본적으로 ‘내가 중요하다고 생각하는 것을 팀이 100% 공감할 수 없다’, ‘이런건 원래 시간이 필요한 일이다’ 라는 점을 인정하는 마음이 필요해요.</p><p id="cc90">팀에 동기화하는 가장 효과적인 방법은 문제를 겪는(?) 거예요. 아무 일도 일어나지 않았는데 새로운 문화 혹은 규칙을 제안하는 것보다 실제로 겪은 문제의 재발을 방지하기 위해 제안하는 것이 당연히 효과적이겠죠. 그렇다고 일부러 문제를 만들라는 의도는 아니고, 크고 작은 문제 상황을 기회로 삼고 놓치지 말라는 의미에요.</p><p id="1ee5">제가 좋아하는 또 다른 방법은, 저와 결이 유사한 사람을 팀에 끌어들이는 거예요. 새로운 원칙을 제안하기 전에 2명 이상의 팀원이 행동과 결과를 보여주면 팀에 받아들여지는 경우가 있더라고요.</p></div></div>

Stories by Mijeong (Rachel) on Medium

나는 ‘개발자 원칙’ 이라는 책의 저자 중 한 명이고, 6월 21일 책의 저자들이 모두 모여서 라이트닝 토크와 패널 토크를 진행했다. 당시 사전 질문 중, 시간 관계상 모두 답변하지 못한 내용에 대해 가볍게 기록한다.
Q. 미정님처럼 리더가 되고 싶은 여성 개발자들에게 조언을 부탁드려요.
저는 14년 동안 업으로 개발을 해오면서 약 7년 정도 리더 역할을 해오고 있어요. 다양한 개발자 동료 혹은 커피챗을 통해 새롭게 만난 분들로부터 유사한 질문을 종종 받았어요.
개발 리더는 개발자의 역량과 리더의 역량을 잘 갖춰야겠죠. 리더가 팀의 적절한 의사결정을 내리기 위해 당연히 개발 역량이 기반이 되어야 하고, 일과 사람을 관리하는 리더의 역량이 모두 필요해요.
많은 분이 개발 역량에만 초점을 두고 애쓰는 것 같아요. 개발 공부를 열심히 한다거나, 시간을 더 투자해서 개발 업무를 남들보다 많이 한다거나. 하지만, 리더의 기회는 다른 것에서 주어지는 경우가 많다고 생각해요. 내가 어떻게 문제를 정의하는지, 해결책을 찾아가는 과정이 어떤지, 팀과 소통하고 협업하는 방식은 어떤지. 이러한 것들이 드러나야 일과 사람을 관리할 수 있는 리더의 기회가 주어질 거예요.
개발 역량은 이미 잘하고 있거나 충분히 노력하고 있을 거예요. 내가 뭘 더 공부하고 얼마나 더 일해야 하나에 애쓰지 말고, 이미 잘 하고있는 걸 드러내는 데 애쓰라고 말해주고 싶어요.
Q. 작업에 대한 기록을 평소에도 하시나요?
우선, 저는 원래 기록을 좋아하는 사람이에요. 어릴 때부터 일기 쓰던 습관이 지금까지 이어질 정도로 기록에 대한 거부감이 없는 사람임을 미리 밝혀요.
일을 할 때 다양한 기록을 유지하고 있어요. 우선 출근하면 가장 먼저 하는 일이 오늘 해야 할 일을 나열하고, 나열한 일의 우선순위를 정해요. 그리고 마지막으로 필요한 시간을 측정하고 할 수 있는 일을 확정해요.
또 다른 종류의 기록을 요즘 시작했는데요. 바로, 실제로 일을 하면서 일의 맥락이 바뀔 때마다 기록하는 거예요. 몇 시부터 몇 시까지 어떤 일을 했는지. 이 기록을 시작한 이유는 시간 관리가 잘 안된다고 느껴서예요. 팀 2개를 리드하고 지속적으로 맥락이 많아지다 보니 시간 관리가 어렵더라고요. 그래서 내가 실제로 중요하지 않은 일에 시간을 쏟고 있는 건 아닌지 추적해 보고 진짜 중요한 일에 시간을 쓰고 싶어요.
그 외, 팀 문화 관점에서도 ‘기록’ 은 여전히 중요한 키워드예요. 저는 팀이 투명할 때 팀이 더 중요한 일을 잘할 수 있다고 믿어요. 데일리 스크럼 쓰레드, 데일리 리뷰 쓰레드, Weekly 노트, OKR 회고/수립 노트 등 팀의 문화에는 ‘기록’ 이라는 장치가 많아요.
Q. 내가 중요하다고 생각하는 원칙을 팀원들과 동기화 할 수 있는 방법은 무엇인가요?
기본적으로 ‘내가 중요하다고 생각하는 것을 팀이 100% 공감할 수 없다’, ‘이런건 원래 시간이 필요한 일이다’ 라는 점을 인정하는 마음이 필요해요.
팀에 동기화하는 가장 효과적인 방법은 문제를 겪는(?) 거예요. 아무 일도 일어나지 않았는데 새로운 문화 혹은 규칙을 제안하는 것보다 실제로 겪은 문제의 재발을 방지하기 위해 제안하는 것이 당연히 효과적이겠죠. 그렇다고 일부러 문제를 만들라는 의도는 아니고, 크고 작은 문제 상황을 기회로 삼고 놓치지 말라는 의미에요.
제가 좋아하는 또 다른 방법은, 저와 결이 유사한 사람을 팀에 끌어들이는 거예요. 새로운 원칙을 제안하기 전에 2명 이상의 팀원이 행동과 결과를 보여주면 팀에 받아들여지는 경우가 있더라고요.
이 글을 읽어주시는 모든 분의 건강한 원칙을 응원해요.

개발자 원칙, 래빗톡 못다 한 이야기

댓글