TLDR
밑바닥에서 시작하는 초기 스타트업 개발팀 빌딩 (진태양 / 볼타 CTO)
- 스타트업, 대기업의 개발자 경험과 창업 후 팀빌딩 경험 공유해 주셨다.
- 경력에서 배운 것
- 스타트업
- Product Growth 경험
- 우선순위, 제품 탐색 전략, GTM 전략 (Go To Market) 등을 배운 시간
- 대기업
- 경험해보지 못한 영역의 상상력을 기르는 경험
- 혼자 1억, 2억은 벌 수 있지만, 100억, 1000억은 어떻게 벌 수 있을지 인사이트를 얻는 시간
- 창업 후 팀빌딩의 원칙을 세워 매년 30% growth하는 팀을 빌딩
- 1) 같이 일해본 경험이 있는 분은 풀타임으로 채용하지 않는다.
- 팀을 인맥, 지인으로 채우면 조직의 개성이 없어진다. (= 새로운 자극이 없어진다. 새로운 자극이 있어야 챌린지가 생긴다.)
- 지인끼리는 건강하게 갈등을 풀어가기 어렵다.
- 친분이 있으면 갈등을 회피한다. 이는 조직 발전에 제동으로 작용한다.
- 지인의 도움은 파트타임으로 받는다.
- 2) 팀과 fit이 맞으면서 최대한 기존 팀에 없는 캐릭터를 가지신 분을 채용.
- 3) 주요 포지션에서 양적 확장이 가능하신 분을 채용
- 기존 팀원이 하는 일을 당연히 할 수 있으면서도 새로운 영역으로 확장하는데 기여할 수 있는 분
- 초기 스타트업이 3000명 이상의 지원을 받은 비법 (HR적인 노력)
- 회사에서 내 인생의 중요한 시간을 불태울 가치가 있을지 근거를 전달한다.
- 5000자 이상의 job description 작성.
- 개발 커뮤니티 적극 홍보
- 4시간 이상의 인터뷰
- 팀, 회사, 제품 소개 60분
- 문화 적합성 인터뷰 60분
- 직무 적합성 인터뷰 120분
- 채용 지원자 모두에 대한 피드백 제공(400 ~900자)
진태양님
OCP : 다양한 사람들에게 Open, 문제는 Close (송재영 / Xangle CTO)
- 17년간 개발자 커리어를 지속하며 얻은 리더십과 매니징에 대한 인사이트를 공유해 주셨다.
- 세상에는 다양한 개발자가 있다.
- 묵묵히 자기일을 처리하는 개발자
- 새로운 기능에 열정이 넘치는 개발자
- 일을 빠르게 해내는 개발자
- 리드의 말을 잘 든는 개발자
- 코드 퀄리티가 높은 개발자
개발자와 능력치 - 개발자 개인은 각자의 역량이 다르다.
- 문제는 다양한 개발자 사이 갈등에서 생긴다.
- 팀원A vs 팀원C
- 테크적으로 뛰어난 팀원A는 커뮤니케이션이 뛰어난 팀원C를 인정하지 못한다.
- 커뮤니케이션이 뛰어난 팀원C는 테크만 뛰어난 팀원A를 인정하지 못한다.
- 앞서 언급한 멋진 개발자 들이 단점만 부각되고 갈등의 원인이 될 수 있다.
묵묵히 자기일을 처리하는 개발자 -> 다른 팀원 일은 관심없고 자기일만새로운 기능에 열정이 넘치는 개발자 -> 새로운 기술만 찬양하는 팀원일을 빠르게 해내는 개발자 -> 디테일이 약하고 버그가 많은 팀원리드의 말을 잘 든는 개발자 -> Yes만 하고 일이 느린 팀원코드 퀄리티가 높은 개발자 -> 일정보다 예술작품 하는 팀원
다름에서 오는 갈등
- 리드의 역할
- 팀원을 내버려두면 바뀌지 않는다. = 갈등이 해결되지 않는다.
- 테크 기술이 부족한 팀원C를 팀원A가 인정할 최소 테크 역량으로 끌어올린다.
- 커뮤니케이션 능력이 부족한 팀원A의 커뮤니케이션 역량을 끌어올린다.
- 팀원, 팀의 변화를 이끄는 것이 리드의 역할이다.
조율하는 리더
- 리드의 역할을 수행하기 위해서는 리더의 철학, 역량이 필요하다.
- 리드의 특성 - 신뢰, 친화력, 태도, 책임, 참을성, 이기주의, 경험, 협동, 의리, 믿음 . . .
- 리더의 종류 예시
- 덕장 스타일
- 맹장 스타일
- 자신만의 스타일
- 나의 삶, 철학이 다르기 때문의 나의 방향이 정답이다.
-
- 협동의 의미을 공유한다.
- 업계에 천재들이 많다. 하지만 천재들도 혼자서는 일을 할 수 없다.
- 따라서 협동을 팀원에게 알려주는 것이 중요하다.
- 협동이란? 예를 들어 MSA를 구현한다. 팀원이 MSA를 모른다. MSA 교육시키는 것도 협력이다.
- 생소한 개념에도 다같이 교류가 가능한 장을 만드는 것이 리드의 역할
- 멋진 코드로 개발 하였으나 혼자만 해당 코드로 개발한다면?
- 팀에서는 일관성, 협동심이 더 중요하다.
- 만약 멋진 코드로 개발하고 싶다면 팀원들을 설득하 팀에 전파하여 일관성을 만들어라.
- 회의 만들어 세미나, 설득
- 팀 다같이 업그레이드 해야한다.
- 책임감, 직업의 의미를 상기시킨다.
- 시스템 간헐적으로 다운 현상 발견 → 팀원이 매번이래요 괜찮아요. 라고 말한다면 책임감의 태도를 주입.
- 목표의 인지, 선악을 뺀 이익적 사고 감각이 필요하다.
- DAU 15만 목표 . . .
- 기획자가 15만 가능하게 상상, 공상 기획 . . .
- 기획을 올바르게 동작하게 하는 것이 개발자. IT업계는 상상과 공상이 없다면 성장하지 못한다.
- 어려운 기획을 다 아니라고 하지말고 같이 목표 달성하려는 노력이 필요하다.
일터의 코더 (박성철 / 마켓컬리 풀필먼트 본부장)
- 타회사에 초청받아 비공개로 강연했던 내용을 공유
- 대부분의 개발자는 코딩에 대해서 잘못 알고 있다.
- 코드란? 소스코드란? 코딩이란?
- 코드 -> CPU 제어하는 데 사용하는 기계 명령어로 구성된 컴퓨터 코드
- 소스코드 -> 소스코드는 코드가 아니다. 사람이 읽는 설계 문서에 가깝다. 프로그래밍 언어로 작성된 텍스트 파일이다.
- 코딩 -> 소스코드를 코드로 변환하는 작업 (컴퓨터가 수행)
- 소프트웨어 설계의 본질
- 코드를 구축하는 것(코딩)은 컴파일러가 하는 작업이다. (건설로 따지면 무료에 가까운 시간)
- 소프트웨어 설계를 너무 엄격하게 하지 않아도 된다.
- 소스코드가 설계이다. ⇒ 시도, 변경, 개선 가능
- 개발자는 지식노동자이다.
- 업무를 수행하며 연구, 탐색하는 과정이 필요하다.
- 연구, 탐색하는 과정은 단순 지시로 수행이 불가한 영역이다.
- 연구 탐색이 이루어지게 하려면 어떻게 해야할까?
- 좋은 팀
- 좋은 팀이 연구, 탐색을 할 수 있게 한다.
- 팀은 서로 상호의존관계를 가진다.
- 새로운 도전, 연구, 탐색에 있어서 서로 의지할 수 있는 동료가 있다면 심리적 안정감을 제공한다.
- 상호의존하는 관계가 만들어진 팀은 더 큰 일에 도전하고 큰 일을 만들 수 있다.
- 1+1 > 2 와 같은 뛰어난 팀이 뛰어난 제품을 만든다.
- 일터의 만족
- 일터에서 삶의 만족을 얻을 수 있는 본인의 기준이 있어야한다.
- 과거 회사의 당근과 채찍이 하는 동기부여는 한계가 명확하다.
- 급여와 같은 외적동기 보다 내적동기, 개인의 성취, 인정과 같은 요소가 통계적으로 더 높은 동기부여와 만족을 가져온다.
동기부여의 종류
2편 - https://yeoon.tistory.com/176