The Staff Engineer's Path — 쉽게 이해하기
Tanya Reilly, The Staff Engineer's Path: A Guide for Individual Contributors Navigating Growth and Change (2022, O'Reilly) 를 파인만 학습법으로 풀어쓴 재구성 해설 노트입니다.
원서의 요약이 아니라, 핵심 개념을 한국어 비유와 설명으로 다시 짠 것. 정확한 인용·세부 사례·저자의 원래 표현은 원서를 직접 보세요.
⚠️ 이 책은 "스태프 엔지니어" 라는 직급 사다리가 존재하는 미국 테크 기업 을 전제합니다. 그 전제가 없는 조직에 옮길 때 어디가 깨지는지는 이 문서 11장에서 따로 다룹니다.
0. 이 문서를 읽는 법
- ⚠️ 장 번호 규약: 아래의 "N장" 은 이 문서 의 번호입니다. 원서는 9장까지 이고, 각 절 머리에 대응하는 원서 장을 따로 적어 두었습니다. 다른 학습 노트를 가리킬 때도 "구글 문서 8장" 처럼 문서 라고 적었습니다 — 그 책 원서의 장 번호가 아닙니다. 인용할 때 섞지 마세요.
- 1장(무엇이 이 역할인가) → 2장(내 일을 스스로 정의하기) 이 골격입니다. 시간 없으면 이 둘만.
- 3장부터는 원서의 3부 구조를 따릅니다: 큰 그림 → 실행 → 남을 성장시키기.
- 각 장 끝의 "한 줄 요약" 으로 복습.
- 이 책은 유난히 "당신 상황에 맞춰 답하라" 로 끝나는 절이 많습니다. 그럴 때마다 멈추고 자기 조직의 이름과 숫자를 넣어 다시 읽으세요. 그게 이 책을 써먹는 법입니다. (다만 이 성질이 왜 동시에 이 책의 약점이기도 한지는 11-3 에서 따로 다룹니다.)
앞의 네 권과의 결
| 다루는 것 | |
|---|---|
| 달리오 | 결정·조직의 원칙 |
| 메도즈 | 시스템 의 일반 법칙 |
| 그로브 | 매니저 의 일상 실무 |
| 구글 책 | 소프트웨어 엔지니어의 실무 — 시간·규모 의 축 |
| 이 책 | 관리 권한이 없는 상위 엔지니어(스태프+) 의 일상 실무 — 영향력 이라는 축 |
그로브의 책과 짝으로 읽으면 가장 선명합니다. 그로브는 부하 직원이 있는 사람 이 어떻게 산출을 만드는지를 씁니다. 릴리는 부하 직원이 없는 사람 이 같은 크기의 산출을 어떻게 만드는지를 씁니다. 도구가 하나 빠진 상태에서 같은 일을 하는 셈입니다 — 그래서 훨씬 어렵고, 그래서 책 한 권이 필요합니다.
1. 이 책이 답하려는 질문
(원서 서문 및 1장 "What Would You Say You Do Here?")
한 문장으로 줄이면 이렇습니다.
"매니저가 되지 않고도 계속 성장하려면, 대체 무엇을 해야 하는가?"
1-1. 왜 이게 질문이 되는가
시니어 엔지니어까지는 경로가 비교적 분명합니다. 코드를 잘 짜고, 어려운 문제를 풀고, 팀의 일을 감당하면 됩니다. 그 위로 올라가면 상황이 바뀝니다.
- 더 이상 코드를 더 많이 짜서 올라갈 수 없습니다. 하루는 여전히 24시간이니까.
- 하는 일의 배합이 바뀝니다. 책은 이 직급에 필요한 기량을 넷으로 봅니다 — 기술 자체, 제품 감각, 프로젝트 관리, 사람 관리. 위로 갈수록 뒤의 셋이 늘어나는데, 직함에는 그게 안 적혀 있습니다.
- 그런데 회사는 더 큰 임팩트 를 기대합니다.
- 그 임팩트를 만들 권한 은 주지 않습니다. 사람을 배치할 수도, 예산을 쓸 수도, 우선순위를 지시할 수도 없습니다.
책이 다루는 것이 정확히 이 간극입니다. 권한 없이 조직 규모의 결과를 만드는 일. 원서 부제의 "성장과 변화를 헤쳐 나가는 개인 기여자" 가 가리키는 것이 이 상태입니다.
1-2. "스태프+" 라는 말
용어부터 정리합니다.
- Staff, Senior Staff, Principal, Distinguished — 시니어 위의 개인 기여자(IC) 직급들. 회사마다 이름과 개수가 다릅니다.
- Staff+ — 이 직급들을 뭉뚱그린 업계 통칭. 이 책의 대상.
- 중요한 것: 이건 매니저 트랙과 나란히 놓인 다른 트랙 입니다. 위가 아니라 옆.
책이 반복해서 못박는 사실 하나:
스태프 엔지니어의 직무 정의는 회사마다 다르다. 같은 회사 안에서도 팀마다 다르다.
이 문장이 짜증나게 들릴 수 있는데, 이건 저자의 회피가 아니라 관찰된 사실 입니다. 그리고 이 사실에서 책의 첫 번째 실무 지침이 나옵니다 — 네 일이 뭔지 네가 알아내야 한다.
1-3. 세 개의 기둥
원서 서문에서 제시되고, 책 전체(3부 구성)가 이 세 가지로 짜여 있습니다.
| 기둥 | 무엇인가 | 안 하면 생기는 일 |
|---|---|---|
| 큰 그림 보기 (big-picture thinking) | 지금 결정이 1년·3년 뒤에 어떻게 되는지, 옆 팀·옆 조직에 어떤 영향을 주는지를 본다 | 팀은 각자 열심히 하는데 전체는 같은 자리 |
| 실행 (execution) | 크고·모호하고·여러 팀이 얽힌 일을 실제로 끝낸다 | 좋은 아이디어가 문서로만 남음 |
| 남을 성장시키기 (leveling up) | 내가 아는 것을 조직의 능력으로 바꾼다 | 내가 병목이 됨 |
세 기둥은 동시에 필요합니다. 하나만 잘하면 흔한 실패 유형이 됩니다. (아래 세 이름은 책의 분류가 아니라 제 정리입니다.)
- 큰 그림만: 아키텍처 우주비행사. 너무 높이 올라가서 지상이 안 보이는 상태 — 그림은 멋진데 그걸 실제로 짜야 하는 사람의 하루와 닿지 않습니다.
- 실행만: 일 빠른 엔지니어 한 명. 직급만 올라갔고 하는 일은 그대로.
- 성장시키기만: 인기 있는 멘토. 사람들은 좋아하는데 조직의 문제는 그대로.
1장 한 줄 요약: 스태프+ 는 매니저의 위가 아니라 옆이다. 권한 없이 조직 규모의 결과를 만드는 역할이고, 큰 그림 · 실행 · 남을 성장시키기 세 가지가 동시에 필요하다. 직무 정의는 회사마다 다르므로 스스로 알아내야 한다.
2. 내 일이 무엇인지 스스로 정의하기
(원서 1장)
책의 가장 실용적인 부분입니다. "당신의 일은 이것입니다" 를 알려주는 대신, 당신의 일을 결정하는 변수들 을 줍니다.
2-1. 네 개의 변수
| 변수 | 질문 | 왜 중요한가 |
|---|---|---|
| 보고 라인 | 내 매니저는 누구인가? 팀장인가, 부문장인가, CTO인가? | 내가 보는 정보의 높이 와 내 말의 기본 무게 가 여기서 결정됨 |
| 범위 (scope) | 내 책임 영역은 팀인가, 여러 팀인가, 조직 전체인가, 회사인가? | 너무 넓으면 아무것도 못 하고, 너무 좁으면 직급값을 못 함 |
| 주된 초점 | 기술 자체인가, 기술을 둘러싼 사람·프로세스인가? | 같은 직급인데 하는 일이 완전히 다른 이유 |
| 일의 형태 | 혼자 깊게 파는가, 여러 팀을 연결하는가, 위기를 해결하는가? | 하루 일과의 모양이 여기서 결정됨 |
이 네 개를 채우면 당신의 직무 기술서가 나옵니다. 회사가 주지 않은 것을 스스로 쓰는 것입니다.
2-2. 범위 — "너무 넓음" 도 실패다
직관에 반하는 지점이라 따로 봅니다. 보통 우리는 범위가 넓을수록 좋다 고 생각합니다. 책의 관찰은 다릅니다.
범위가 너무 넓을 때 생기는 일:
- 모든 것에 조금씩 관여하고 아무것도 끝내지 못함.
- 결정이 필요한 자리에 항상 늦게 도착.
- "그 사람은 의견은 많은데 책임지는 건 없다" 는 평판.
범위가 너무 좁을 때 생기는 일:
- 한 팀의 시니어 엔지니어와 구별되지 않음.
- 자기 팀에 최적이지만 회사에는 손해인 결정을 내리게 됨.
책의 처방: 범위를 명시적으로 정하고, 명시적으로 말하라. 매니저와 합의하고, 주변에 알리고, 바뀌면 다시 말하라. 정하지 않으면 남들이 정해 줍니다 — 보통 아무도 안 하려는 일 로.
2-3. 네 가지 흔한 형태 (Larson 의 분류)
여기서 자주 인용되는 네 가지 유형이 있습니다. 단, 이건 이 책이 아니라 Will Larson 의 Staff Engineer (2021) 에서 나온 분류 입니다. 릴리의 책은 이를 참고 좌표로 소개합니다. 출처를 섞지 마세요.
| 유형 | 하는 일 | 하루의 모양 |
|---|---|---|
| Tech Lead | 한 팀(또는 몇 팀)의 기술 방향을 이끔 | 매니저와 짝을 이뤄 일함. 가장 흔한 형태 |
| Architect | 특정 도메인의 설계·품질·방향을 책임짐 | 여러 팀을 가로지르는 설계 결정 |
| Solver | 조직이 지금 가장 아픈 문제에 투입됨 | 문제마다 옮겨 다님 |
| Right Hand | 임원을 대신해 조직의 문제를 본다 | 임원 회의에 배석하고, 그 자리에서 나온 결정을 현장 언어로 옮김 |
자기 유형은 지난 한 달의 캘린더 를 보면 대체로 나옵니다. 회의 대부분이 한 팀 안에 있으면 Tech Lead, 여러 팀의 설계 논의면 Architect, 매달 주제가 바뀌면 Solver, 임원 일정과 붙어 있으면 Right Hand 쪽입니다.
자기 유형을 알면 실용적으로 이런 게 달라집니다: 다른 유형의 기준으로 자기를 평가하지 않게 됩니다. Solver 가 "나는 왜 안정적인 도메인 오너십이 없지" 라고 자책할 필요가 없고, Architect 가 "나는 왜 코드를 덜 짜지" 라고 자책할 필요가 없습니다.
2-4. 무엇을 안 할 것인가
스태프+ 가 되면 요청이 쏟아집니다. 리뷰해 달라, 회의에 들어와 달라, 이 결정을 봐 달라. 전부 정당한 요청이고, 전부 받으면 아무것도 못 합니다.
실무 기준선으로 쓸 만한 두 질문: "내가 아니면 안 되는 일인가?" 그리고 "이게 지금 조직에서 가장 중요한 일인가?" 둘 다 아니오면 넘기거나 거절합니다. 넘기는 것 자체가 3부(남을 성장시키기)의 일이기도 합니다.
2장 한 줄 요약: 회사가 직무 기술서를 안 준다. 보고 라인 · 범위 · 초점 · 일의 형태 네 변수로 스스로 쓰고, 명시적으로 합의하라. 범위는 좁아도 실패지만 넓어도 실패다.
3. 세 개의 지도
(원서 2장 "Three Maps")
책에서 가장 널리 인용되는 비유입니다. 조직을 이해하는 세 가지 시선을 지도에 빗댑니다.
3-1. 위치 지도 (Locator Map) — "나는 지금 어디 있는가"
지도 앱을 떠올리면 됩니다. 내 위치에 핀이 찍혀 있는 건 기본이고, 핵심 기술은 손가락으로 줌아웃하는 것 — 같은 핀을 축척을 바꿔 가며 보는 것입니다.
- 축척 1: 내 팀 안에서 나는 중요한 사람이고, 내 프로젝트는 큰 일입니다.
- 축척 2: 부문 으로 줌아웃하면, 내 프로젝트는 다섯 개 중 하나입니다.
- 축척 3: 회사 로 줌아웃하면, 내 부문 전체가 이번 분기 우선순위에 없을 수도 있습니다.
이건 자기를 깎아내리려는 게 아닙니다. 자기 일의 실제 크기를 알아야 시간을 제대로 배분할 수 있기 때문 입니다. 줌아웃하면 종종 이런 게 보입니다: 내가 3개월 매달린 최적화보다, 옆 팀이 겪는 배포 지옥이 회사에 더 큰 문제라는 것.
3-2. 지형 지도 (Topographical Map) — "여긴 어떤 땅인가"
조직도는 공식 지도입니다. 지형 지도는 실제로 걸어보면 알게 되는 것들 입니다.
- 어느 팀과 어느 팀 사이에 골이 깊은가.
- 어떤 결정이 어디서 실제로 나는가 (회의실이 아니라 점심시간일 수도).
- 누가 직급과 무관하게 실질적 영향력 을 갖는가 — 책은 이 실질 권력 구조를 그림자 조직도(shadow org chart) 라고 부릅니다.
- 무엇이 말해도 되는 것 이고 무엇이 지뢰 인가.
이 지형을 읽는 축들도 제시합니다. 자기 조직이 각 축의 어디쯤인지 표시해 보면 지도 한 장이 나옵니다.
| 축 | 한쪽 끝 | 반대쪽 끝 |
|---|---|---|
| 정보 | 기본이 비공개 | 기본이 공개 |
| 매체 | 구두 문화 | 문서 문화 |
| 방향 | 톱다운 | 보텀업 |
| 변화 속도 | 빠르게 바꾸고 고침 | 신중하게 검토하고 바꿈 |
| 경로 | 뒷채널·인맥 | 정문·공식 절차 |
| 역할 | 유동적 | 고정적 |
책은 이를 정치라고 부르는 걸 피하지 않습니다. 다만 정의를 바꿉니다 — 정치는 더러운 것이 아니라, 여러 사람이 얽힌 조직에서 일이 실제로 움직이는 방식 입니다. 지형을 모르면 아무리 옳은 제안도 벽에 부딪힙니다.
지형을 안 다음 실제로 제안을 통과시키려 할 때의 순서 (원서에서는 다음 장인 3장에서 더 자세히 다룹니다):
- 이 제안이 통과하려면 누가 찬성해야 하는가.
- 그 사람이 반대할 이유는 무엇인가 (보통 그 사람의 목표 안에 있습니다).
- 그 사람에게 이 제안을 그 사람의 언어 로 어떻게 말할 수 있는가.
이건 조작이 아니라 번역입니다. 같은 제안이 인프라 팀에는 "운영 부담 감소" 로, 제품 팀에는 "출시 속도" 로, 재무에는 "클라우드 비용" 으로 들립니다.
3-3. 보물 지도 (Treasure Map) — "우리는 어디로 가는가"
세 번째 지도가 가장 자주 비어 있습니다. 목적지가 없으면 모든 길이 똑같이 좋아 보입니다.
증상:
- "왜 이걸 하죠?" 에 대한 답이 "위에서 하라고 해서" 뿐.
- 팀마다 다른 미래를 가정하고 각자 최적화. 3년 뒤에 서로 안 맞는 시스템 다섯 개.
- 기술 부채를 갚자는 말은 늘 나오는데 어떤 상태를 향해 갚는지가 없음.
이 지도가 없을 때 실제로 벌어지는 일을 하나만 따라가 봅니다. 세 팀이 각자 인증을 처리해야 합니다. 목적지 그림이 없으니 A팀은 기존 세션 방식을 확장하고, B팀은 새 토큰 방식을 도입하고, C팀은 급해서 A팀 코드를 복사합니다. 세 결정 모두 각자의 자리에서는 합리적입니다. 2년 뒤 인증 방식이 세 개가 되고, 그때부터는 어느 하나를 고쳐도 나머지 둘이 깨집니다. 누구도 잘못한 사람이 없는데 결과는 나쁜 상태 — 목적지 없음이 만드는 전형적인 모양입니다.
스태프+ 의 일 중 하나가 이 지도를 그려서 공유하는 것 입니다. 다음 장의 주제입니다.
3장 한 줄 요약: 조직을 세 지도로 본다 — 내 위치(축척을 바꿔 보기), 지형(실제 권력과 골짜기), 목적지(우리가 향하는 곳). 세 번째가 대개 비어 있고, 그걸 그리는 게 스태프+ 의 일이다.
4. 큰 그림을 만든다 — 비전과 전략
(원서 3장 "Creating the Big Picture")
앞 장의 보물 지도를 실제로 그리는 방법입니다. 책은 두 종류의 문서를 구분합니다.
4-1. 기술 비전 vs 기술 전략
| 답하는 질문 | 성격 | |
|---|---|---|
| 기술 비전 (technical vision) | 성공했다면 3년 뒤 우리 시스템은 어떤 모습인가? | 목적지의 그림. 어떻게 갈지는 말하지 않음 |
| 기술 전략 (technical strategy) | 거기까지 어떻게 갈 것인가? 무엇을 포기하는가? | 경로와 트레이드오프. 선택이 들어감 |
둘의 차이를 감으로 잡는 예:
- 비전: "모든 서비스가 같은 배포 파이프라인을 쓰고, 새 서비스는 하루 안에 프로덕션에 뜬다."
- 전략: "먼저 상위 트래픽 5개 서비스만 옮긴다. 레거시 결제 시스템은 이번 라운드에서 건드리지 않는다. 자체 도구 대신 상용 제품을 쓴다."
전략에는 포기가 명시 되어 있어야 합니다. 아무것도 포기하지 않는 문서는 전략이 아니라 소원 목록입니다.
책은 전략의 뼈대로 Richard Rumelt 의 Good Strategy Bad Strategy 에서 온 3요소를 빌려 씁니다.
| 요소 | 질문 |
|---|---|
| 진단 (diagnosis) | 지금 진짜 문제가 무엇인가? |
| 방침 (guiding policy) | 그 문제에 어떤 방향으로 대응할 것인가? |
| 행동 (coherent actions) | 그 방침에 맞는 구체적 행동은 무엇인가? |
이 셋 중 진단이 빠진 전략 문서가 가장 흔합니다. 문제 정의 없이 해야 할 일 목록부터 시작하는 문서 — 읽는 사람이 동의할 이유가 없습니다.
4-2. 이 문서는 쓰는 것 이 아니라 합의하는 것
여기가 초보 스태프 엔지니어가 가장 자주 실수하는 곳입니다.
흔한 실패 경로:
- 주말에 훌륭한 아키텍처 문서를 혼자 씁니다.
- 월요일에 전체 채널에 공유합니다.
- 아무 일도 일어나지 않습니다.
이유는 문서의 품질이 아닙니다. 그 문서에 자기 지분이 있는 사람이 아무도 없기 때문 입니다. 책의 처방은 정반대 순서입니다.
- 사람들을 먼저 인터뷰합니다. 각 팀이 뭘 아파하는지, 뭘 원하는지.
- 초안임을 밝히고 일찍 돌립니다. 다 만든 뒤에 보여주면 고칠 자리가 없습니다.
- 반대할 가능성이 큰 사람을 먼저, 따로 찾아갑니다. 공개 회의에서 처음 부딪히면 늦습니다. (일본어에서 온 네마와시(根回し) — 뿌리를 미리 다듬어 둔다는 뜻 — 를 책은 이 작업의 이름으로 씁니다.)
- 결정권자에게 서명을 받습니다. 그 사람이 이 문서를 자기 것 으로 말할 수 있어야 합니다.
즉 문서는 산출물이 아니라 합의의 흔적 입니다. 문서가 좋아서 통과되는 게 아니라, 통과된 것이 문서에 남는 것입니다.
4-3. 글쓰기가 실제로 일이다
책이 반복하는 다소 불편한 사실: 이 직급에서는 글이 곧 영향력의 전달 매체 입니다. 회의에서 한 말은 그 방에 있던 여덟 명에게만 갑니다. 문서는 3년 뒤 새로 들어온 사람에게도 갑니다.
"저는 코드가 더 좋은데요" 라는 마음은 자연스럽지만, 이 직급의 레버리지는 대부분 글에 있습니다. 그로브식으로 말하면 고레버리지 활동 이 옮겨간 것입니다.
4장 한 줄 요약: 목적지 그림(비전)과 경로·포기(전략)를 문서로 만든다. 그러나 문서는 혼자 쓰는 게 아니라 합의를 모으는 과정 이다. 훌륭한 문서를 혼자 써서 공유하면 아무 일도 일어나지 않는다.
5. 유한한 시간 — 자원으로서의 나
(원서 4장 "Finite Time")
개인적으로 가장 실용적인 부분입니다.
5-1. 유한한 것은 시간만이 아니다
책은 시간(일주일 168시간)을 큰 틀로 놓고, 그 안에서 함께 관리해야 할 자원을 다섯 가지 더 셉니다.
| 자원 | 줄어드는 방식 | 채워지는 방식 |
|---|---|---|
| 에너지 | 갈등, 정치, 관심 없는 일 | 잘 맞는 일, 성과, 쉼 |
| 삶의 질 | 야근, 온콜, 만성적 갈등 | 스스로 지켜야 함 |
| 신뢰 자본 (credibility) | 틀린 예측, 안 지킨 약속, 남의 영역 침범 | 맞춘 예측, 끝낸 일, 남을 도운 기록 |
| 사회적 자본 (social capital) | 부탁, 밀어붙인 제안 | 도움, 협업, 함께한 성공 |
| 기술 (skills) | 쓴다고 줄지 않음 — 대신 안 쓰면 녹슴 | 새로운 문제, 새로운 도메인 |
마지막 줄이 중요합니다. 기술은 이 목록에서 유일하게 쓸수록 늘어나는 자원 입니다. 그래서 일을 고를 때의 계산이 달라집니다 — 신뢰 자본과 에너지를 쓰는 일이라도, 기술이 크게 느는 일이면 남는 장사일 수 있습니다. 반대로 아무것도 배울 게 없으면서 에너지만 잡아먹는 일은 조직에 필요하더라도 내가 계속 잡고 있을 이유가 약합니다.
다만 "안 쓰면 줄지 않는다" 는 뜻은 아닙니다. 책이 반복해서 경고하는 반대 방향의 위험이 있습니다 — 한 조직에 오래 머물면서 코드에서 멀어지면, 남는 것이 그 조직에서만 통하는 지식 뿐인 상태가 됩니다. 회사를 옮기는 순간 가치가 급락하는 종류의 자산입니다.
신뢰 자본과 사회적 자본을 구분 하는 것도 이 장의 핵심입니다.
- 신뢰 자본: "이 사람 말은 맞더라." → 기술적으로 옳았던 기록에서 나옵니다.
- 사회적 자본: "이 사람 부탁이면 들어줄 만하다." → 관계에서 나옵니다.
둘 다 쓰면 줄어드는 자원입니다. 논쟁에서 이기고 밀어붙일 때마다 조금씩 씁니다. 그래서 책의 조언은: 아무 언덕에서나 죽지 마라. 정말 중요한 싸움을 위해 남겨 두세요.
5-2. 글루 워크 — 보이지만 안 세지는 일
저자를 유명하게 만든 개념입니다. 원래는 이 책이 아니라 저자의 발표 "Being Glue" 에서 나왔습니다 (2018년 Write/Speak/Code 가 처음, 널리 퍼진 것은 2019년 LeadDev New York 버전. 슬라이드와 노트는 noidea.dog/glue). 책에도 같은 결로 들어와 있습니다.
글루 워크(glue work) — 프로젝트를 실제로 굴러가게 만드는 접착제 같은 일들:
- 회의록 정리, 문서 최신화
- 팀 사이 조율, 놓친 것 찾아내기
- 신입 온보딩, 질문 답하기
- 릴리즈 챙기기, 남의 PR 리뷰
이 일들의 공통점: 없으면 프로젝트가 망하는데, 승진 심사에서는 잘 안 세집니다. 심사는 보통 "당신이 설계·구현한 것" 을 묻지 "당신이 없었으면 무너졌을 것" 을 묻지 않습니다.
여기서 저자의 조언이 둘로 갈립니다. 이 두 갈래를 같이 봐야 균형이 잡힙니다.
- 스태프+ 에게: 이건 당신 일의 정당한 일부입니다. 글루 워크가 조직 규모로 작동하는 게 이 직급의 실체입니다.
- 아직 그 아래 직급인 사람에게: 조심하세요. 글루 워크만 하면 승진에 필요한 기술적 기록이 쌓이지 않습니다. 저자가 특히 강조하는 지점은 이 일이 여성과 소수자에게 불균형하게 몰린다 는 것입니다 — 원래 이 지적이 Being Glue 발표의 핵심이었고, 발표 대상도 그 자리에 있던 여성 엔지니어들이었습니다. 하고 싶으면 하되, 눈을 뜨고 하세요.
두 번째 조언이 특히 정직합니다. "다 좋은 일이니 하세요" 로 끝내지 않습니다.
5-3. 실무적으로 어떻게 하나
자기 시간의 실제 사용을 한 주만 기록해 보기. 대부분 자기가 생각하는 것과 다릅니다.
지금 하는 일이 본 퀘스트인지 사이드 퀘스트인지 구분하기. 책은 게임 비유를 씁니다.
유형 무엇인가 본 퀘스트 (main quest) 조직이 나에게 기대하는 주된 일 사이드 퀘스트 (side quest) 가치는 있지만 곁가지인 일 딴짓 (distraction) 재미있어서 하는 일 참견 (meddling) 남이 잘하고 있는 일에 끼어드는 것 사이드 퀘스트가 나쁘다는 게 아닙니다. 문제는 사이드 퀘스트만으로 채워진 역할 이 되기가 너무 쉽다는 것 — 하루하루는 바쁘고 유용한데 본 퀘스트는 한 발도 안 나간 상태.
일정을 100% 채우지 않기. 스태프+ 에게 오는 일 상당수는 계획할 수 없는 것들(갑자기 터진 문제, 누군가의 질문, 잘못 가고 있는 결정)입니다. 여유가 없으면 그 일을 못 받습니다.
2-4 의 두 질문으로 필터링. 아니면 넘기고, 넘기는 걸 남의 성장 기회로 씁니다 (9-4 참조).
보이지 않는 일을 보이게 만들기. 한 일을 짧게 기록해 두는 습관. 자랑이 아니라 심사 때 자기를 방어할 데이터 입니다.
"예" 를 기본값으로 두지 않기. 즉답하지 말고 "확인하고 답드릴게요" 를 기본값으로.
5장 한 줄 요약: 시간뿐 아니라 에너지 · 삶의 질 · 신뢰 자본 · 사회적 자본이 모두 유한한 자원이고, 기술만이 쓸수록 늘어난다. 아무 언덕에서나 죽지 마라. 글루 워크는 이 직급의 정당한 일이지만, 그 아래 직급에서는 눈을 뜨고 선택해야 하는 함정이기도 하다.
6. 큰 프로젝트를 이끈다는 것
(원서 5장 "Leading Big Projects")
여러 팀이 얽힌 크고 모호한 프로젝트를 맡았을 때의 이야기입니다.
6-1. 시작 전에 할 일
책이 강조하는 지점: 처음의 모호함을 견디는 것이 일의 절반 입니다. 큰 프로젝트는 대개 이런 상태로 옵니다 — "결제 시스템 좀 어떻게 해 봐요."
이때 코드를 열기 전에 확보해야 할 것들:
| 확보할 것 | 확인 질문 |
|---|---|
| 왜 | 이걸 왜 지금 하는가? 성공하면 무엇이 달라지는가? |
| 범위 | 무엇이 이 프로젝트 안이고, 무엇이 명시적으로 밖 인가? |
| 성공 조건 | 어떤 상태가 되면 끝난 것인가? |
| 역할 | 결정은 누가 하는가? 나는 결정자인가 조언자인가? |
| 이해관계자 | 이 결과에 영향받는 사람은 누구인가? |
"명시적으로 밖" 이 특히 중요합니다. 적어 두지 않으면 프로젝트는 언제나 커집니다.
6-2. 프로젝트는 코드가 아니다
큰 프로젝트에서 코드 작성은 일부일 뿐입니다. 나머지가 더 큽니다.
- 설계 문서와 리뷰
- 팀 간 인터페이스 합의 (누가 무엇을 언제까지)
- 진행 상황을 올바른 사람들에게 알리는 일
- 막힌 곳을 찾아 뚫는 일
- 계획이 틀렸음을 인정하고 다시 짜는 일
여기서 흔한 실패: 가장 재미있는 부분(어려운 기술 문제)을 자기가 잡고, 나머지는 방치. 그러면 그 재미있는 부분은 잘 되고 프로젝트는 실패합니다.
6-3. 신뢰를 유지하는 커뮤니케이션
여러 팀이 얽힌 프로젝트는 정보가 끊기는 지점 에서 죽습니다. 실무 습관 몇 가지:
- 정기적이고 지루한 업데이트. 나쁜 소식일수록 일찍, 짧게.
- 결정을 기록. "왜 이렇게 정했는지" 를 남기지 않으면 6개월 뒤 같은 논쟁을 반복합니다.
- 한 곳에 진실을 둔다. 문서 다섯 개가 조금씩 다른 상태가 프로젝트를 죽입니다.
- 수박을 만들지 않기. 책에 나오는 표현으로 수박 프로젝트(watermelon project) — 상태 보고는 초록불인데 속을 갈라보면 빨간 상태. 위로 올라갈수록 초록이 되는 보고 라인은 조직의 구조적 문제이고, 그걸 깨는 것도 스태프+ 의 일입니다.
- 역할을 문서로 못박기. 누가 결정하고, 누가 실행하고, 누가 자문받고, 누가 통보만 받는지 (RACI 같은 도구). "당연히 알겠지" 가 가장 비싼 가정입니다.
6장 한 줄 요약: 큰 프로젝트의 시작은 모호함을 정리하는 일이다 — 왜 · 범위(특히 밖) · 성공 조건 · 결정권 · 이해관계자. 그리고 프로젝트의 대부분은 코드가 아니라 합의와 커뮤니케이션이다.
7. 왜 멈췄는가 — 막힌 프로젝트
(원서 6장 "Why Have We Stopped?")
제목부터 좋은 장입니다. 프로젝트는 극적으로 실패하지 않습니다. 조용히 멈춥니다.
7-1. 멈추는 두 가지 방식
책은 일시적 정지를 크게 둘로 나눕니다.
| 유형 | 증상 | 대응 |
|---|---|---|
| 막힘 (blocked) | 남의 결정·남의 팀·승인·리뷰를 기다리는 중 | 기다리지 말고 찾아가라. 대개 상대는 자기가 막고 있는 줄 모릅니다 |
| 길 잃음 (lost) | 다들 바쁜데 방향이 없음 | 무엇을 모르는지부터 구분: 어디로 가는지 모르나, 어떻게 가는지 모르나, 지금 어디쯤인지 모르나 |
"찾아가라" 가 막연하니 한 단계 더 내려갑니다. 막힌 쪽에 보낼 메시지는 대개 이 형태입니다.
"○○ 리뷰를 기다리는 중인데, 이게 저희 쪽 다음 단계를 막고 있어서요. 이번 주 안에 어려우시면 다른 분께 부탁드리거나 범위를 줄여서 다시 올릴까 하는데, 어느 쪽이 나을까요?"
세 가지가 들어 있습니다 — 무엇을 기다리는지, 그게 무엇을 막고 있는지, 그리고 상대가 고를 수 있는 선택지. 마지막이 핵심입니다. 재촉은 상대에게 부담만 주지만, 선택지는 상대가 답하기 쉽게 만듭니다.
막힘의 하위 유형 중 하나는 따로 볼 만합니다 — 아무에게도 배정되지 않은 일에 막힌 경우. 모두의 일이라서 아무의 일도 아닌 상태입니다. 조직에는 항상 "누구 일인지 애매해서 아무도 안 하는 중요한 일" 이 있고, 그걸 집어들어 이름을 붙이는 것이 스태프+ 가 존재하는 이유 중 하나입니다. (원서가 이걸 별도 대분류로 세우지는 않습니다.)
7-2. 끝내는 일은 별도의 기술이다
프로젝트의 마지막 10%가 90%의 시간을 먹는 이유:
- 남은 게 다 재미없는 일 입니다 (마이그레이션 잔여분, 문서, 정리).
- 사람들이 이미 다음 흥미로운 일 로 마음이 떠났습니다.
- "거의 다 됐다" 는 상태가 몇 달 갑니다.
책의 처방: "끝났다" 의 정의를 처음에 못박고, 마지막 구간을 명시적인 일로 계획하라. 코드가 완성된 것 과 실제로 출시되어 쓰이는 것 은 다르고, 구 시스템을 실제로 꺼야 끝난 것입니다. 안 끄면 두 시스템을 영원히 유지하게 됩니다.
(구글 문서 8장의 "구·신 공존 → 둘 다 유지 → 비용 두 배" 와 같은 결입니다. 다만 두 책의 화자는 다릅니다 — 구글 책은 API 제공자 가 사용자 마이그레이션 비용까지 떠안아야 한다는 이야기이고, 여기는 프로젝트를 이끄는 사람 이 마지막 10%를 계획에 넣어야 한다는 이야기입니다.)
그리고 끝났으면 끝났다고 알리고 축하하는 것 까지가 일입니다. 조용히 끝난 프로젝트는 사람들의 기억에 남지 않고, 다음 프로젝트를 위한 신뢰로도 바뀌지 않습니다.
7-3. 취소도 결과다
멈춘 프로젝트를 되살리는 것만이 답은 아닙니다. 더 이상 가치 없는 프로젝트를 명시적으로 죽이는 것도 스태프+ 의 일 입니다. 조용히 방치하는 것보다 낫습니다 — 방치된 프로젝트는 사람들의 시간과 조직의 주의를 계속 먹습니다.
취소는 실패의 인정이라 감정적으로 어렵습니다. 그래서 직급과 신뢰 자본이 있는 사람이 해야 하는 일입니다.
7장 한 줄 요약: 프로젝트는 폭발하지 않고 조용히 멈춘다. 막힘과 길 잃음을 구분해 대응하고, 특히 주인 없는 일을 집어들어라. 마지막 10%를 계획에 넣고, 가치 없어진 프로젝트는 명시적으로 죽여라.
8. 롤모델이 된다는 것 (미안하지만)
(원서 7장 "You're a Role Model Now (Sorry)")
3부의 시작입니다. 직급이 올라가면 원하든 원치 않든 사람들이 당신의 행동을 기준으로 삼습니다.
8-1. 왜 "미안하지만" 인가
이건 특권이 아니라 제약이기 때문입니다.
- 회의에서 짜증을 내면, 그게 이 회사에서 시니어가 행동하는 방식 이 됩니다.
- 테스트를 건너뛰면, 그게 여기서는 그래도 되는 것 이 됩니다.
- 모른다고 말하지 않으면, 아무도 모른다고 말하지 않게 됩니다.
즉 당신의 나쁜 습관이 조직 규모로 복제 됩니다. 그리고 복제는 대칭이 아닙니다 — 좋은 습관은 "저 사람이니까 되는 것" 으로 여겨지기 쉬운 반면, 나쁜 습관은 허용의 신호 로 즉시 읽힙니다. 이 비대칭이 이 직급의 숨은 비용입니다.
8-2. 무엇의 롤모델인가
책은 네 가지를 듭니다.
| 축 | 의미 | 내일 당장 할 수 있는 것 |
|---|---|---|
| 유능함 | 기술을 계속 유지한다 | 자기가 리뷰한 PR 중 제대로 안 읽고 승인한 것 이 있는지 돌아보기. 있으면 다시 열어서 읽기 |
| 책임감 | 결과를 자기 것으로 안는다 | 최근 장애의 회고에서 "누가 그랬나" 대신 "이 상황에서 누구라도 그랬을 텐데 왜 막히지 않았나" 를 묻기 |
| 목표를 잊지 않기 | 지금 논쟁이 무엇을 위한 것이었는지 놓치지 않는다 | 30분 넘어간 기술 논쟁에서 "우리가 지금 뭘 좋게 만들려는 거였죠?" 한 번 말하기 |
| 앞을 내다보기 | 3년 뒤를 생각한다 | 급하게 내리는 결정에 "이건 나중에 되돌리기 쉬운가, 어려운가" 한 줄을 붙여 기록하기 |
8-3. "모른다" 를 말하는 힘
이 장에서 가장 실전적인 한 가지. 스태프+ 가 회의에서 "죄송한데 그게 뭔지 모르겠어요, 설명해 주실 수 있나요?" 라고 말하면 두 가지가 동시에 일어납니다.
- 그 자리에서 모르고 있던 다른 네 명 이 구원받습니다.
- 이 조직에서 모른다고 말해도 안전하다는 신호가 나갑니다.
구글 문서 3장에서 다룬 심리적 안전 — 그리고 그걸 떠받치는 HRT(겸손·존중·신뢰) — 과 같은 결입니다. 다만 그 책이 문화와 제도 로 접근하는 반면, 여기서는 권한 없는 개인이 자기 행동 하나로 만든다는 점이 다릅니다.
8장 한 줄 요약: 직급이 올라가면 행동이 조직 규모로 복제된다. 유능함 · 책임감 · 목표 기억 · 앞을 보는 것의 본보기가 되어야 하고, 그중 가장 강력한 한 수는 "모른다" 를 공개적으로 말하는 것이다.
9. 영향력의 규모
(원서 8장 "Good Influence at Scale")
내가 아는 것을 조직의 능력으로 바꾸는 방법입니다. 핵심 질문:
한 사람에게 두 시간을 쓰는 것과, 백 사람에게 닿는 문서에 두 시간을 쓰는 것 중 무엇이 옳은가?
답은 "경우에 따라" 이고, 책은 그 경우를 두 개의 축으로 나눕니다.
9-1. 축 하나 — 닿는 범위
| 범위 | 뜻 | 강점 / 약점 |
|---|---|---|
| 개인 | 특정 한 사람에게 직접 | 맥락에 정확히 맞음 / 비싸고 나만 할 수 있음 |
| 그룹 | 팀·여러 팀에 한 번에 | 한 번 만들어 여러 번 씀 / 개별 맥락을 못 맞춤 |
| 촉매 (catalyst) | 내가 직접 닿지 않는 곳 까지 퍼짐 | 내가 없어도 작동 / 통제 불가, 틀리면 크게 틀림 |
세 번째가 이 장의 핵심 개념입니다. 촉매란 내가 백 명을 만나는 게 아니라, 내가 만든 것이 나 없이 퍼져 나가는 상태 입니다. 좋은 템플릿 하나, 잘 만든 기본값 하나, 남이 계속 인용하는 문서 하나.
9-2. 축 둘 — 쓰는 수단
| 수단 | 하는 일 | 주의 |
|---|---|---|
| 조언 (advice) | 내 의견을 준다 | 가장 싸고 빠름. 단, 상대가 원하는 게 조언이 아니라 공감 일 때가 많습니다 |
| 가르침 (teaching) | 상대가 스스로 할 수 있게 만든다 | 느리지만 남음 |
| 가드레일 (guardrails) | 틀리기 어렵게 만든다 | 린터, 템플릿, 안전한 기본값, 리뷰 절차 |
| 기회 (opportunity) | 남에게 성장할 자리를 넘긴다 | 위임과 스폰서십. 9-4 참조 |
두 축은 곱셈으로 조합됩니다. 같은 "조언" 이라도 세 규모가 다 있습니다 — 후배에게 하는 1:1 조언(개인), 팀 채널에 올리는 설계 의견(그룹), 그리고 사람들이 자기들끼리 링크를 돌려가며 인용하는 문서 한 편(촉매). 마지막이 촉매인 이유는 내가 그 자리에 없어도 조언이 계속 전달되기 때문입니다.
9-3. 그래서 어느 쪽을 고르나
처음의 질문 — 한 사람에게 두 시간 vs 백 사람에게 닿는 문서에 두 시간 — 으로 돌아갑니다. 판단에 쓸 만한 기준 셋:
- 이 문제가 반복되는가? 같은 질문을 세 번째 받았다면 그건 개인의 문제가 아니라 구조의 문제입니다. 문서나 가드레일로 올라갈 신호.
- 맥락이 얼마나 개별적인가? "이 사람의 커리어 고민" 은 문서로 안 됩니다. "이 API 를 쓰는 법" 은 문서로 됩니다.
- 틀렸을 때 비용이 얼마인가? 규모가 클수록 틀린 것도 함께 퍼집니다. 확신이 낮은 것은 개인 규모에서 시험해 보고 올리세요.
거칠게 줄이면: 반복되고, 개별성이 낮고, 확신이 높은 것부터 위 규모로 올린다.
가드레일 개념이 특히 유용합니다. 사람들에게 "이렇게 하세요" 라고 말하는 대신 잘못하기 어렵게 만드는 것. 사람이 아니라 구조를 건드린다는 점에서 메도즈의 시스템 사고와 통합니다. 단, 메도즈 문서 9장의 단서도 같이 기억하세요 — "구조가 행동을 만든다" 를 끝까지 밀면 구조결정론이 되고, 사람의 판단이 필요한 자리 까지 규칙으로 덮게 됩니다. 가드레일은 판단을 대체하는 게 아니라 판단할 필요가 없는 것들을 걷어내서 판단할 시간을 만드는 것 입니다.
9-4. 멘토십과 스폰서십은 다르다
책이 분명하게 구분하는 지점이고, 실무적으로 중요합니다.
| 멘토십 | 스폰서십 | |
|---|---|---|
| 하는 일 | 조언한다 | 기회를 준다 |
| 쓰는 것 | 내 시간 | 내 신뢰 자본 |
| 예시 | "이렇게 접근해 보면 어떨까요" | "이번 설계 발표는 이 사람이 합니다" |
| 위험 | 낮음 | 실패하면 내 평판도 같이 감 |
관찰: 조언은 많이 받지만 기회는 못 받는 사람들이 있습니다. 스폰서십이 실제로 커리어를 움직이고, 그래서 더 비쌉니다. 내 신뢰 자본을 남에게 빌려주는 행위 이기 때문입니다.
9-5. 가르치되 대신 해 주지 않기
흔한 실패: 질문받을 때마다 답을 줘서 영원한 병목 이 되는 것. 책의 조언은 답 대신 접근법 을 주라는 것입니다. "이건 이렇게 하세요" 대신 "저라면 이 세 가지를 확인해 보겠어요, 어떻게 나오는지 알려주세요."
느리고 답답하지만, 이게 세 번째 기둥(레벨업)의 실체입니다.
9장 한 줄 요약: 영향력은 닿는 범위(개인 · 그룹 · 촉매) 와 수단(조언 · 가르침 · 가드레일 · 기회) 의 곱이다. 반복되고, 개별성이 낮고, 확신이 높은 것부터 위 규모로 올려라. 멘토십은 내 시간을 쓰고 스폰서십은 내 신뢰 자본을 쓴다. 답을 주면 병목이 되고, 접근법을 주면 사람이 큰다.
10. 다음은 무엇인가
(원서 9장 "What's Next?")
마지막 장은 커리어 자체를 다룹니다.
10-1. 승진은 목표가 아니라 부산물
책의 태도는 담백합니다. 스태프+ 로 승진하는 건 좋지만, 그게 목표가 되면 이상해집니다. 승진 심사에 잘 보이는 일만 고르게 되고, 그건 대개 조직에 필요한 일과 다릅니다.
동시에 순진하지도 않습니다. 승진 심사가 존재하고, 그 심사가 보는 것이 있고, 자기 일을 보이게 만드는 건 정당한 자기 관리라고 씁니다. 눈 감고 일만 하는 쪽과 심사용 실적만 고르는 쪽 사이에서 균형을 잡습니다.
10-2. 정체됐다고 느낄 때의 점검
- 지금 배우고 있는가? 아니라면 무엇을 배울 수 있는 자리로 갈 수 있는가.
- 지금 하는 일이 내가 잘하는 것 인가, 남이 나에게 기대하는 것 인가.
- 이 회사에서 다음 단계가 실제로 존재하는가. (없는 회사도 많습니다.)
- 나는 지금 즐거운가. — 책은 이 질문을 진지하게 다룹니다.
- 옮긴다면: 새 조직에서는 세 지도를 처음부터 다시 그려야 합니다. 옛 조직의 규칙을 그대로 들고 가는 것이 이직한 시니어의 가장 흔한 실패입니다.
10-3. 매니저로 갈까
책의 프레이밍: 매니지먼트는 승진이 아니라 다른 직업입니다. 위아래가 아니라 옆입니다. 그리고 조건을 하나 답니다 — 엔지니어로서 충분히 단단해지기 전에 넘어가지 말 것. 기술적 기반이 없는 상태로 넘어가면 돌아올 길도 좁아집니다.
(참고: 이 왕복을 "양방향 문" 이나 "engineer/manager pendulum" 이라고 부르는 관용어가 업계에 있지만, 그건 각각 아마존과 Charity Majors 쪽 어휘이지 이 책의 표현이 아닙니다.)
스스로 판단할 때 쓸 만한 질문 하나 — 이건 책의 문장이 아니라 제 정리입니다: "사람들의 문제를 푸는 하루" 와 "기술 문제를 푸는 하루" 중 어느 쪽이 끝났을 때 덜 지치는가?
10장 한 줄 요약: 승진은 목표가 아니라 부산물이지만, 자기 일을 보이게 만드는 건 정당한 자기 관리다. 매니지먼트는 승진이 아니라 다른 직업이고, 옮겨도 돌아와도 실패가 아니다.
11. 정직한 비판 — 이 책의 한계
이 책은 스태프+ 라는 주제에 관해 현재 가장 잘 정리된 책 중 하나지만, 무비판적으로 받아들이면 안 됩니다.
11-1. 이 사다리가 없는 회사가 더 많다
가장 큰 한계입니다.
- 책은 스태프/프린시펄 트랙이 제도로 존재하는 회사 를 전제합니다. 저자의 배경(Google, Squarespace)이 그렇습니다.
- 한국을 포함해 많은 조직에는 이 트랙이 없습니다. 시니어 위는 팀장이고, 그 위는 부문장입니다.
- 트랙이 없는 곳에서 이 책의 조언을 그대로 하면 평가받지 않는 일을 하는 사람 이 될 위험이 있습니다. 조직에는 이롭고 개인에게는 손해인 상태.
스케일 다운해서 쓰는 법: 이 책을 직급 안내서 가 아니라 역할 안내서 로 읽으세요. 세 기둥(큰 그림·실행·레벨업)과 세 지도, 자원 관리, 글루 워크 개념은 직급 제도와 무관하게 작동합니다. 반면 "스태프 승진 심사", "프린시펄의 범위" 같은 절은 제도가 없으면 의미가 없습니다.
11-2. 검증 가능한 근거가 거의 없다
- 근거의 대부분이 저자 자신의 경험 + 다른 엔지니어들에게서 들은 일화 입니다.
- 통계도, 대조군도, 실패한 스태프 엔지니어에 대한 체계적 분석도 없습니다. 생존자들의 이야기입니다.
- "이렇게 하면 잘 된다" 의 반례 — 이렇게 했는데 안 된 사람들 — 이 거의 안 보입니다.
이건 이 장르의 구조적 한계이기도 합니다. 그로브(인텔 한 회사), 구글 책(구글 한 회사)과 같은 문제입니다. 여러 회사의 이야기가 섞여 있다는 점은 낫지만, 그 이야기들이 어떻게 수집되고 선별되었는지 는 책에서 밝혀지지 않습니다. 좋은 결말로 끝나는 일화만 남았을 가능성을 배제할 방법이 독자에게 없습니다.
11-3. 조언이 부드럽고, 그래서 반증하기 어렵다
책의 조언 상당수는 이런 형태입니다 — "상황에 따라 다르니 당신 맥락에서 판단하세요."
정직한 태도지만 동시에 틀릴 수 없는 조언 이기도 합니다. 어떤 결과가 나와도 "맥락이 달랐다" 로 설명됩니다. 읽고 나서 뭘 해야 할지 명확해지지 않는 절이 꽤 있고, 그건 독자의 이해 부족이 아니라 책의 성질입니다.
11-4. 정치를 다루지만 권력을 덜 다룬다
책은 조직 정치를 정면으로 다룹니다. 그런데 권력 그 자체 — 누가 왜 자원을 갖는가, 잘못된 결정을 한 사람이 왜 계속 결정권을 갖는가, 조직이 구조적으로 특정 사람들에게 불리할 때 개인의 전략이 무슨 소용인가 — 는 상대적으로 약합니다.
글루 워크가 여성·소수자에게 몰린다는 지적은 하지만, 그 이후의 처방은 대체로 개인이 조심하는 법 입니다. 구조를 바꾸는 이야기는 개인이 할 수 있는 범위를 넘기 때문일 텐데, 그렇다면 그 한계를 더 분명히 말했어야 한다고 봅니다.
11-5. 그럼에도 살아남는 부분
환경 의존도가 낮고 일반화되는 것들 (괄호는 원서 기준 위치):
- 세 기둥 — 큰 그림 · 실행 · 레벨업 (서문).
- 세 지도 — 위치 · 지형 · 목적지 (2장).
- 자원으로서의 자기 관리 — 특히 신뢰 자본과 사회적 자본의 구분, 그리고 기술만이 쓸수록 는다는 것 (4장).
- 글루 워크의 이중성 — 필요하지만 안 세지는 일 (4장).
- 프로젝트는 조용히 멈춘다 (6장).
- 멘토십 ≠ 스폰서십 (8장).
이 여섯 개는 직급 제도가 없는 조직에서도 쓸 수 있습니다. 다만 그대로 는 아닙니다 — 열 명짜리 팀에 그림자 조직도랄 게 있을 리 없고, 촉매 규모의 영향력을 논할 대상도 없습니다. 규모가 작아지면 개념은 남고 도구는 줄어듭니다. 세 지도는 종이 한 장으로, 자원 관리는 자기 시간표 하나로, 영향력은 옆자리 사람 한 명으로 축소해서 쓰면 됩니다.
11-6. 다음 단계로 갈 사람에게
- Will Larson, Staff Engineer (2021) — 같은 주제의 자매서. Larson 은 구조와 유형 에 강하고 Reilly 는 실무 감각 에 강합니다. 같이 읽으면 보완됩니다.
- Camille Fournier, The Manager's Path — 반대편 트랙. 이 책의 제목이 그 책의 제목을 의식하고 있습니다. 두 트랙을 같이 봐야 자기 선택이 보입니다.
- 자기 조직에서 실제로 시험 — 세 지도 중 지형 지도 를 한 장 그려 보세요. 종이에. 아무에게도 안 보여주는 걸로. 그게 이 책에서 가장 빨리 현금화되는 연습입니다.
닫는 글
권한은 직급이 주지만 영향력은 신뢰가 줍니다. 신뢰는 쌓는 데 오래 걸리고 쓰면 줄어드는 자원입니다.
이 책의 절반은 그 자원을 어디에 쓸지 정하는 방법 이고, 나머지 절반은 그걸 다 쓰기 전에 조직의 능력으로 바꿔 놓는 방법 입니다. 직급 제도도 미국 테크 기업의 맥락도 빼고 남는 것이 그 둘입니다.
책이 답하지 않는 질문도 하나 남습니다 — 그 신뢰를 쌓을 기회 자체가 고르게 주어지지 않는 조직에서는 어떻게 하는가. 11-4 에서 적은 대로, 이 책은 그 지점에서 개인의 전략까지만 말하고 멈춥니다.
끝.