처음 Project Managing을 했을 때 든 생각
프로젝트 매니저가 되고 나서 처음 든 생각은 자신감이 아니었다.
회사의 팀 프로젝트를 대강 나눠보면 아래와 같다.
- 내 회사 사람들과 함께하는 프로젝트
- 다른 회사 사람들과 함께하는 프로젝트
1번은 하다가 모르는 것이 생기면 해당 팀에게 자세히 물어볼 수 있다. 2번은 그게 쉽지 않다.
내가 하는 Role은 이런 것이었다. 아래 같은 프로젝트를 리드하는 것.
- 고객은 반도체를 설계해보고 실제 칩을 확인해보니, 특정 문제를 발견했다.
- 고객은 이 문제를 Synopsys가 분석해서, 재발 방지 하는 EDA 기능을 요구했다.
- 고객은 모든 EDA Tool들이 해당 기능을 사용 할 수 있게 해야하고, Cadence, SIEMENS 같은 3rd party EDA tool에도 호환 가능하도록 하는 Standard format도 만들어주는 것이 고객 바램이다.
"고객들이 나보다 훨씬 잘 아는데, 내가 어떻게 이 프로젝트를 리드하지?"
"이 기능을 실제로 개발하는 R&D가 나한테 뭘 물어보면, 이걸 어떻게 답변하지?"
원래 나는 엔지니어였다. 문제가 생기면 직접 분석하고, 직접 답을 찾는 게 내 방식이었다.
근데 갑자기 PM이 되니까 내가 가장 모르는 사람이 된 것 같은 느낌이 들었다. 고객은 그 도메인에서 수십 년을 보낸 전문가들이고, 나는 그 산업을 겨우 파악하는 중이었다.
이게 불안했다. 솔직히.
문제는 내가 리더십을 잘못 이해하고 있었던 것
MBA 수업에서 이런 프레임을 배웠다.
Technical Challenge vs. Adaptive Challenge.
| Technical | Adaptive | |
|---|---|---|
| 문제 | 명확하다 | 불명확하다 |
| 해결책 | 이미 존재한다 | 학습이 필요하다 |
| 누가 푸나 | 전문가, 권위자 | 문제를 가진 사람들 |
나는 그동안 모든 걸 Technical Challenge로 접근했다.
리더 = 가장 많이 아는 사람. 그래서 내가 모르면 리드할 자격이 없다고 생각했다.
근데 PM의 일은 처음부터 Adaptive Challenge였다. 정답이 없고, 고객도 모르고, 나도 모른다. 다같이 학습하면서 방향을 만들어가야 하는 일.
오펜하이머는 핵물리학 최고 전문가가 아니었다
MBA 동기가 말했다. "너, 맨해튼 프로젝트 하는거라고 생각해봐. 오펜하이머처럼 해봐."
오펜하이머는 Feynman보다 물리를 못했고, Fermi보다 실험을 못했고, Teller보다 이론이 약했다. 그럼에도 불구하고 역사상 가장 복잡한 프로젝트를 이끌었다.
그가 한 건 따로 있었다.
- 천재들을 한 자리에 모았고, 같은 방향을 보게 만든 것
- 서로 다른 분야가 충돌하지 않고 연결되게 한 것
- "우리가 왜 이걸 하는가"를 팀 전체가 잊지 않게 한 것
천재들을 위한 무대를 만든 것.
이게 Adaptive Challenge에서 리더가 하는 일이다.
나의 실제 포지션
고객 (공정 / 설계에서 최고 권위자들)
↓
나 (설계도 해봤고, EDA 코드도 봄)
↓
R&D (EDA 최고 권위자들)
고객, R&D가 나를 얕볼 수도 있는 구도이고, 내가 유일한 도메인 통역사이다.
그래서 나에게 진짜 필요한 건
고객한테는 → Credibility 리더십
- 고객이 나에게 원하는 것: "이 사람이 내 문제를 진짜 이해하고 있나? 그래야 해결을 해줄텐데"
- 내가 20년 설계 / 공정 경험을 이길 수 없음, 대신 "EDA 제품 관점에서 가장 정확히 아는 사람"
- 이 프로젝트를 정복 가능하도록, 여러가지 작은 문제로 분할 해줄 수 있는 사람.
- 이 프로젝트를 마일스톤으로 나누고, 관리를 해줄 수 있는 사람
- 이 문제가 뭐 때문에 발생하고, 이 문제를 해결 할 수 있는 사람이 누구인지 연결해줄 수 있는 사람
R&D한테는 → Domain Authority 리더십
"이 기능이 실제 반도체 플로우에서 어떻게 쓰이는지. 고객이 원하는 input과 output이 무엇인지. 그 input과 output이 어떤 관계식을 갖는지"
그 다음은 R&D가 "내가 이런식으로 만들었는데 평가해줘" 하면, 이건 내가 줄 수 있다.
여기서 자연스럽게 관계가 생긴다.
R&D한테는 기술 권위자 고객한테는 툴 전문가 로 각각 다른 포지션
수정된 최종 조합
고객 대면 → Credibility + Visionary
(신뢰 먼저, 방향 제시)
R&D 대면 → Domain Authority + Democratic
(내가 왜를 알려주고, 어떻게는 맡김)
- 문제가 Adaptive인지 Technical인지 구분하는 것 — 엔지니어 출신은 모든 걸 Technical로 풀려는 습관이 있다. 조심해야 한다.
- 사람들이 같은 방향을 보게 만드는 것 — 전문가들을 설득하는 게 아니라, 연결하는 것.
- "왜"를 계속 remind하는 것 — 프로젝트가 복잡해질수록 Action에만 매몰된다. Values로 돌아가야 한다.
나보다 더 잘 아는 사람들, 나보다 직급이 높은 사람들을 리드하는 건 불가능한 일이 아니다.