[세미나] 한기용 CTO - 9번의 개발팀 리드와 팀 세팅을 거친 인사이트

date

Sep 3, 2023

slug

20230901-한기용-cto-view

author

status

Public

tags

Seminar

summary

지난 9월 1일 모두의연구소에서 주최한 한기용 그렙 CTO님의 세미나에 참석했다. 강연 내용 중 중요하다고 느껴지는 것들을 정리, 요약해보았다.

type

Post

thumbnail

category

😎 Insights

updatedAt

Sep 5, 2023 01:30 PM

매니저가 해야할 일

성공적인 채용을 하기 위해

• 팀빌딩의 시작은 정말 필요한 사람을 뽑고 온보딩 잘하고 피드백 잘 주는 것

• 채용성공을 위해…
• JD를 잘 쓸 것, 온보딩을 사전에 계획할 것
• 면접관들을 사전에 양성하고 꼭 훈련을 해야함
• 주니어 면접관은 꼭 필요. 주니어 면접관을 만들고 어떻게 훈련할 것인지를 계획해야함
• 사전에 훈련을 해야 회사와 면접관, 그리고 면접관들 사이에 얼라인이 된다.
• 이러한 것들이 채용 시작 전에 준비되어있어야 면접프로세스를 체계적으로 가져갈 수 있다.

피드백의 중요성

• 해고를 하는 경험을 통해서 피드백의 중요성에 대해 알게 되었다.
• 한번도 일을 못한다는 말을 안한 상태에서 해고하면 합의도출이 힘듦(ex. 맘에 안드는거 있으면 미리 말해줬어야지…;;) → 피드백의 중요성, 피드백을 잘 주면 해고가 쉬워짐(?)
• 팀원의 성장에 초점을 맞춰 피드백을 주기

• 매니저는 팀원들에게 인기있는 사람이 되기 위한 자리가 아니다.
• 좋은 피드백(= 팀원의 성장을 위한 피드백)은 팀원과 약간 불편한 관계가 되는 것을 전제로 한다.

팀의 성장을 어떻게 이끌 것인가?(feat. 스타트업)

• 팀빌딩
• 팀이 성장하면 중간 매니저는 주로 초기멤버, 즉 경험이 없다 → 채용실패
• 또 성장을 어느정도 하고 나면 인원을 충원해도 전체적으로 capa가 생각만큼 좋지 않다. 인원 2배 뽑아도 아웃풋은 1.5배(= 인재밀도가 낮아지고, 의사소통 비용이 증가)
• 따라서 outbound 시니어 채용이 중요해진다.
• 지인들 레퍼럴로 데려오거나 임원이 찍어서 들어오거나.. 두 가지 밖에 없다.

• 성장을 멈춘 초기 멤버
• 초기멤버가 0부터 0.7까지는 되어도, 그 이상은 경험이 없기 때문에 힘듦
• 이들을 잘 성장하게 해야하지만, 경험상 초기멤버들은 서로 자리싸움하느라 방해가 되는 경우가 많음
• 이때 어떻게 피드백을 줄 것인가가 중요
• 필요하다면 스테이지가 바뀔때마다 구성원을 교체해야한다.(!!!)

개발자는 어떤 사람일까?

어떤 개발자가 되어야할까?

• 개발자들을 만나서 이야기 해보면 대체로 오래 IC로 일하고 싶어함 - 안정성을 위해
• 개발을 계속하면 안정적으로 오래 일 할 수 있을거라 생각함…
• 매니저 되고 싶은 사람 별로 없음

• 또, 새로운 기술을 계속 배우고 싶어함 - 안정성을 위해

• 그러나 개발을 계속하고 싶으면 영향력이 있는 개발자가 되어야함
• 개발에서 손떼는 것을 내 커리어 성장을 멈춘다고 생각하지 않기
• 레벨이 올라가면 주변에 좋은 영향력을 끼치는, 혼자만 개발하는 사람이 아닌…
• 의외로 매니저로 있어도 코딩을 못하게 되지는 않는다. 해야하면 다 하게 됨;
• 결국 커리어에서 중요한 것은 문제를 해결하는 경험, 결과를 만들어내는 경험. 그 수단은 코딩이든 매니징이든 중요하지 않다.

일 잘하는 개발자?

• 회사의 입장에서 필요한 것은 기술지향적인 개발자가 되지 않고, 결과 지향적인 개발자가 되는 것
⇒ 주니어의 관점에서 결과지향적인 개발자가 되는 것은 어떤게 있을까?
• 내가 맡은 일을 잘하기 위해 필요한 게 뭔지 고민하고 그걸 잘하게 되는게 중요
• 예를 들어 주니어 개발자들이 흔히 하는 고민: “회사는 성장하는 것 같지만 나는 성장하지 못하는 것 같다(= 나는 트렌디한 기술 사용하고 싶은데 회사는 오래된 기술을 사용한다!)”
• 회사가 만약 잘되고 있고 내가 인정받고 있는 상황이라면 이런 고민도 크게 문제되지 않는다.
• 하지만 또렷한 이유없이 새로운 프레임웍을 좇아다니는 것은 의미 없을 가능성이 크다. → 어떻게 문제를 해결했는지가 중요하지, 어떤 기술을 잘 사용하는지가 더 중요하지는 않다.(실제로 트렌디한 프레임웍을 다룬다고 채용하지는 않는다)

• 내 앞의 테스크 5개가 있다면 얼마나 빨리 해결하느냐가 아니라, 우선순위를 찾고, 이를 잘 해결하는게 중요 → 우선순위는 일을 만든 사람한테서 찾아야함
• 문제정의를 잘하는 게 중요 = 의사소통을 잘하는 것 = 질문을 잘하는 것(자기검열 하지말기)

경험에서 얻은 것(feat. 매니저로 행복하게 일하기)

1. Practice makes perfect

• 하다보면 잘하게 됨. 미리 걱정할 필요 없음.

• 경험을 바탕으로 다음에 어떻게 잘할까?라는 사고방식 지니기

• 실수하지 않으려고 시도하지 않는게 최악의 결정

• 힘든 경험도 상처로 남지만 않으면 다 도움이 됨 = 고민한 만큼 감정소모한 만큼 성장함

2. Don’t do IC roles

• 팀에 주니어 밖에 없으면 시니어를 뽑아야함

• 7-8명이 넘어가는데 내가 아직도 개발하면 문제 있는거임 - 팀빌딩에 문제있거나 내가 개발에서 손을 안떼거나 → 이렇게 되면 팀 발전 못함

• 점진적으로 IC역할에서 팀빌딩으로 역할을 전환해야함

• 매니저는 1:1하고 피드백하고… 등등 이런 중요한 일을 해야함

• 개발에서 손 뗐다고 해서 개발 못하게 되지 않는다.

• 필요하면 매니징하고 필요하면 코딩하고 이런식으로 해도 된다.

3. 리더십이라는 것은 인기 콘테스트가 아니다.

• 매니저는 결국 팀원을 성장시키고 결정을 내리고 원칙을 세우는 사람

• 팀원들이 나를 좋아하기를 원하는 마음이 있다면…
• 좋은 결정을 하거나 도움이 되는 피드백 주기 힘들다
• 팀원에게 최선이 무엇인지 항상 생각하고 그렇게 실천해야함

4. 선의를 바탕으로 유용한 피드백 제공 방법은?

• 피드백을 주는 것은 매니저의 필수역할

• 다음 퍼포먼스 사이클까지 바로바로 줘야한다.

• 긍정적인 피드백은 구체적으로

• 부정적인 피드백은 신뢰가 기반 (책 <The Five Dysfunctions of a Team> 참고)
• 매니저가 약한 모습을 보여줘야함(실수 인정하고 사과, 모르면 모른다고 물어보기) ⇒ vulnerability based trust 생긴다
• 이렇게 되면 팀원들이 실수했을때 숨기지 않는다!
• 신뢰가 쌓인 첫번째 증거: 매니저에게 질문을 편하게 함
• 기대 ⇒ 관찰된 바 ⇒ 그 사이의 갭에 대해 이야기 해보기 ⇒ 임팩트 expectation ⇒ observation ⇒ gap ⇒ impact
• 이렇게 되면 miscommunication을 막을 수 있음
• 사람에 대해 얘기하는게 아니라 일을 두고 얘기하기
• 캐주얼하게 이야기 하기
• 이런 이야기를 안하면 왜 이번주까지 하기로 했는데 안하고 있지?? 이런식으로 감정적으로 생각하게 됨
• 내가 옳다고 생각하지 않기
• 패턴이 보이면(반복되면) 임팩트에 대해 더 이야기
• 최종적인 동기부여는 본인의 몫 → 매니저의 역할은 아님

5. 일잘러 vs 일못러

• 일못하는 사람과 많은 시간을 보내면서 성장시키려고 했던 실수…
• 결국 그사람의 일을 내가 해주고 있게 됨
• 일못러의 특징은 한번 도와주면 스스로 해야하는데, 또 도움을 요청함
• 일을 잘하는 사람도 어텐션이 필요함. 시간을 같이 보내줘야함

• 항상 되묻기
• 팀원이 매니저에게 언제까지 해달라고 결정해달라는 식의 요청이 있을때 팀원의 생각은 어떤지 오히려 거꾸로 되물어보기. 그러면 대화가 된다.

6. 충돌해결

• 빨리 해결하지 않으면 감정싸움으로 바뀔 위험

• 충돌이라고 하지만 결국은 다른 의견일 뿐

• 두 사람이 싸울때 한사람 손을 들어준다고 해서 갈등이 더 커지지 않는다. 합리적인 이유가 있으면 됨

• 충돌해결은 매니저의 책임

• 계속해서 나름대로의 원칙을 만들고 이를 팀원과 공유할 수 있으면 더 좋다.

7. 매니저가 버틀넥이 되면 안된다. make yourself redundant

• 매니저가 버틀넥이 되어버리면 휴가를 마음대로 못감..ㅠㅠ

• 후계자를 미리 생각해두기
• 애플의 경우 자기의 후계자를 두명 적어내게끔함 → 좋은 점 부족한 점 까지.. 그러면 내가 해당 팀원을 어떻게 도와줘야 하는지까지 보이게 됨

• 팀의 효율성 증대
1. 불필요한 일이나 낮은 ROI 일들을 줄이기
2. 필요하면 자동화

8. 다양한 문제들과 행복하게 공존하기

• 모든 문제를 해결해서 아무 문제 없이 행복하게 산다는 것은 불가능하다.

• 즉 모든 문제를 해결하려는 시도는 부질없음

• 나만 스트레스 받고 가족한테 화풀이 하게 됨 ㅠ

• 더 중요한 문제들 중 내가 컨트롤 할 수 있는 문제들이 무엇인지 파악해야함
• 그런 문제들부터 해결
• 내 컨트롤이 없는 중요한 문제는 해결가능한 사람들에게 언급/논의

9. 팀의 다양성은 중요하다

• 팀의 구성원들이 다양할수록 더 많은 리퍼럴 기회가 생김

• 초기에는 보통 같은 대학, 같은 회사 출신 사람들을 많이 채용하게 되는데, 이는 경계해야함

• 다양성은 채용의 관점에서 굉장히 중요

• 다양성이 있는 팀이 더 면접을 잘함 → 연령대, 성비, 인종 등

• 미팅 등에서 다양한 시각, 관점을 더 쉽게 이야기 할 수 있음

• 팀원 중에 누가 무의식적인 bias를 가지고 있는가? → 인종, 출신, 학력, 성별 등 백그라운드가 비슷하면 ok 아니면 no하는 경우가 많음;

• 신뢰가 있는 환경이라면 의견을 자유롭게 이야기 하면서 생각의 다른 점을 깨달을 수 있음

좋은 채용 프로세스 만들기

1. JD 작성과 온보딩 태스크 준비
1. JD를 쓸때 너무 복잡하게 안쓰기
1. 보너스 스킬 같은거 많이 써두면 자기 검열러들이 안씀
2. 1년안에 쓸 것 같은 것만 적기
2. 이때 온보딩 태스크도 같이 써보면 JD가 명확해짐

2. 면접준비
1. 리쿠르터 결정 후 협업 모델 결정
1. 누가 이력서 스크리닝을 할지 결정( 리쿠르터? 매니저?)
2. 면접 질문과 면접 팀 결정
1. 보통 이걸 안함. 걍 면접 들어가서 각자 질문함
2. 그렇게 하면 해당 포지션에 대한 이해도가 각자 다르기 때문에 얼라인이 필요

3. 이력서 스크리닝과 전화, 줌 스크리닝 면접

4. 온사이트 면접과 면접 브리핑
1. 끝나면 모든 면접관 모여서 같이 이야기 꼭해야함
2. yes or no로 꼭 정해야함
1. 그 이유는 무엇인지까지..
3. bias 있는 사람 찾을 수도 있음
1. 질문과 답변을 놓고 볼때 왜 좋은지 알 수 없는 경우
2. 비슷한 사람을 처음부터 첫인상으로 좋아하거나 싫어하는 경우
3. 이런 경향이 보이면 1:1 미팅에서 꼭 얘기해줘야함

5. 오퍼협상

6. 레퍼런스 체크
1. 경력이 있는 사람은 꼭 해야함
2. 약간의 압박으로 체크..
1. 어떻게 만났냐?
2. 이 사람이 들어와서 할일이 무엇이고, 중요하다고 강조, 이사람이 잘할 것 같은지?
3. 단점을 물으면 안됨. 내가 이 사람을 어떻게 하면 어떻게 도와줘야할지 물어봐야함
4. 커리어에서 중요한 것은 긍정적인 사람이 되어야함!! 부정적이면 실력이 좋아도 개차반

7. 온보딩과 수습기간 리뷰
1. 90일간 어떤 일을 주고 어떻게 평가할 것인지 정해두기

QnA

결과지향적인 개발자가 되기 위해서 해야할 일?

• 새로운 기술을 계속 쫓아다니는 것은 지양해야 한다고 해서 기술이 중요하지 않다는 것은 아님. 기술에 대한 이해도는 기본, 기본기는 당연히 깔고가야함

• 스타텁 주니어 개발자가 많이 고민하는 것 두가지
1. 내가 잘하는지 모르겠다
1. 이 근본 걱정은 대기업에 가면 더 잘하지 않을까? 같은 걱정
2. 이 의구심은 너무 갖지 않고, 내가 알고 있는 걸로 빠르게 행동해보고 회고하고 고치고 하기
3. 내 경험으로 얻은 것은 오래감
4. 본인을 믿고 하기!
2. 나는 개발만 하고 싶은데 다른 거 해야하나?
1. 어떤 일을 성공으로 이끌려면 개발만 하는게 아니라 다른 팀과 얼라인 맞추고 CS팀과 협업해서 피드백있는지 물어보고 해야함

영향력이 있는 개발자란?

• 맡은 일을 잘하는 사람

• 혼자만 잘하는 게 아니라, 다른 사람의 성장 돕기
• 주니어 코칭
• 코드리뷰 잘 해주기

• 윈도우를 맥으로 바꾸자라고 주장하면서 수치를 제시하고 본인의 컴터 뿐만 아니라 팀원들의 컴터 다 바꾸자고 제안한 개발자가 기억에 남음
• 모든 팀원들을 생각하는 사람이 되기
• 이 사람이 있으면 전체적인 역량이 올라가는 사람

개발팀 리드가 가져야하는 역량?

• 리드와 매니저의 차이점
• 매니저는 사람관리
• 리드는 팀원들 평가는 하지 않음
• 리드가 매니저에게 인풋을 많이 주긴 함

• 영향력이 있어야함
• 팀원들이 존경할만한 사람
• 코딩만 잘하는게 아니라 시스템 디자인, 아키텍처적인 영역에서 디자인을 할 수 있어야함