스태프 소프트웨어 엔지니어로서 기술 회사 정치에 영향을 미치는 방법

 (seangoedecke.com)
11P by GN⁺ | ★ favorite | 댓글 1개
  • 기술 회사에서 엔지니어가 조직 정치에 효과적으로 참여할 수 있는 실용적 전략을 제시하는 글로, 많은 엔지니어들이 가진 정치적 무력감을 극복하는 방법을 다룸
  • 엔지니어는 정치 게임의 플레이어가 아닌 도구이지만, 고위직 프로젝트의 성공을 적극 지원하거나 조직의 우선순위 변화에 맞춰 기술 아이디어를 제안함으로써 정치적 영향력을 행사할 수 있음
  • 조직의 관심사는 파도처럼 변화하므로, 안정성, 개발자 경험, 성능 개선 등 다양한 방향의 기술 프로그램을 미리 준비해두고 적절한 시점에 제안하는 것이 핵심 전략
  • 정치적 필요성과 좋은 아이디어의 부재가 충돌할 때 최악의 기술적 결정이 내려지며, 시니어 엔지니어는 적시에 올바른 아이디어를 제시할 책임이 있음
  • 이는 냉소적으로는 권력 투쟁의 도구가 되는 것이지만, 낙관적으로는 경영진의 우선순위 설정을 존중하면서 자신의 기술적 목표를 달성하는 방법으로 볼 수 있음

엔지니어의 정치적 무력감에 대한 일반적 믿음

  • 많은 소프트웨어 엔지니어들은 회사 정치에 대해 운명론적 태도를 가지고 있으며, 참여가 무의미하다고 믿음
    • 기술적 결정이 종종 완전히 이기적인 이유로 이루어져 선의의 엔지니어가 영향을 미칠 수 없음
    • 강력한 이해관계자들이 너무 무능하고 기능 장애적이어서 그들의 요구를 파악하고 솔루션을 제공하는 것이 사실상 불가능함
    • 정치 게임은 엔지니어가 가지지 못한 비공개 정보에 의존하므로, 참여 시도는 그저 허둥대는 결과만 초래함
    • 관리자와 경영진은 대부분의 시간을 정치에 쓰는 반면 엔지니어는 엔지니어링에 쓰므로, 엔지니어는 시작부터 심각한 정치적 불리함에 처함
  • 소프트웨어 엔지니어는 진정한 정치 운영자들과 같은 수준에서 게임을 할 수 없다는 것이 사실
  • 엔지니어가 Game of Thrones처럼 음모를 꾸미기 시작하는 것은 끔찍한 실수이며, 그러한 계략은 즉시 발각되어 불리하게 이용됨
  • 계략을 꾸미려면 연습과 권력이 필요하지만, 둘 다 소프트웨어 엔지니어에게는 없음

정치 참여의 실용적 방법

  • 대기업에서 소프트웨어 엔지니어는 정치 게임의 플레이어가 아닌 도구라는 것이 단순한 사실이지만, 계략 없이도 정치에 참여하는 많은 방법이 존재함
  • 가장 쉬운 방법은 고위 프로필 프로젝트의 성공을 위해 적극적으로 일하는 것
    • 이는 일반적인 업무의 일부로 해야 할 일과 거의 같음
    • 회사가 새로운 프로젝트(요즘은 AI 프로젝트일 가능성이 높음)에 많은 투자를 하고 있다면, 엔지니어링 능력을 사용해 성공시키는 것은 해당 프로젝트를 주도하는 VP나 임원에게 정치적으로 유리한 움직임
    • 그 대가로 보너스, 승진 도움, 향후 고위 프로필 프로젝트의 직위 등 임원이 기술 회사에서 줄 수 있는 보상을 받게 됨

기술 아이디어를 정치적 캠페인에 활용하기

  • 조금 더 어렵지만 더 많은 통제권을 주는 방법은 자신의 선호 아이디어를 기존 정치 캠페인에 활용 가능하게 만드는 것
  • 기존 기능을 별도 서비스로 분리하고 싶다고 가정할 때 두 가지 방법이 있음
    • 어려운 방법: 자신의 정치적 자본을 소비하여 지지를 모으고, 관리자에게 중요성을 알리고, 회의론자들을 천천히 설득하여 프로젝트 승인을 받음
    • 쉬운 방법: 임원이 (훨씬 더 큰) 자신의 정치적 자본을 프로젝트에 쓰도록 허용함
      • 프로젝트와 일치하는 목표에 대한 전사적 지시가 있을 때까지 기다림 (예: 주요 사건 이후 안정성 강조)
      • 그런 다음 관리자에게 자신의 프로젝트가 이에 적합할 수 있다고 제안
      • 올바르게 판단했다면 조직이 프로젝트를 지지하며, 정치적 자본을 소비하는 대신 오히려 증가시킴

조직의 관심사 파도 타기

  • 조직의 관심은 파도처럼 찾아옴
    • 안정성 시기가 되면 VP들은 무언가를 하는 것에 절박해하며, 상사에게 보여줄 그럴듯한 안정성 프로젝트를 찾고 싶어하지만 스스로 할 능력이 없음
    • 이들은 일반적으로 엔지니어링 팀이 제안하는 것이면 무엇이든 기꺼이 자금을 지원함
    • 반면 조직의 주의가 다른 곳(예: 대규모 신제품 출시)에 집중되어 있을 때는, 엔지니어가 고객에게 보이지 않는 내부 안정성 중심 리팩터링에 시간을 쓰는 것을 원하지 않음
  • 기술 회사에서 기술적 작업을 완수하려면 적절한 파도를 기다려야 함
  • 여러 다른 방향의 기술 프로그램을 미리 준비하는 것이 좋은 아이디어
    • 강력한 엔지니어는 일반적인 업무 과정에서 자동으로 이런 것들을 발견함
    • 예시 계획들:
      • 청구 코드를 캐시된 API 호출 대신 웹훅으로 업데이트되는 저장 데이터로 마이그레이션
      • 오래된 수제 빌드 파이프라인을 제거하고 Vite로 교체
      • 트래픽이 많은 지저분한 Python 서비스를 Golang으로 재작성
      • 공개 문서를 지원하는 느린 CMS 프론트엔드를 빠른 정적 사이트로 교체

적시 제안의 중요성

  • 임원들이 청구에 대해 우려할 때 청구 리팩터링을 안정성 개선으로 제안할 수 있음
  • 개발자 경험에 대해 우려할 때 빌드 파이프라인 교체를 제안할 수 있음
  • 고객이 성능에 대해 불평할 때 Golang 재작성을 좋은 옵션으로 제시할 수 있음
  • CEO가 공개 문서 상태를 확인하고 당황할 때 정적 사이트로 재구축할 수 있는 주장을 펼칠 수 있음
  • 중요한 것은 그달의 유행이 무엇이든 간에 즉시 실행 가능한 상세하고 효과적인 작업 프로그램을 준비해두는 것

최악의 기술적 결정이 만들어지는 순간

  • 이런 방식을 따르지 않아도 어떤 프로그램은 자금을 받게 되지만, 이렇게 하지 않으면 어떤 프로그램이 될지 통제할 수 없음
  • 회사가 최악의 기술적 결정을 내리는 곳이 바로 여기: 무언가를 해야 한다는 정치적 필요성과 좋은 아이디어의 부재가 충돌할 때
  • 좋은 아이디어가 없을 때는 나쁜 아이디어라도 쓰게 되지만, 아무도 이 결과를 선호하지 않음
    • 임원에게 나쁨: 실망스러운 기술적 결과를 성공인 것처럼 팔아야 함
    • 엔지니어에게 나쁨: 시간과 노력을 잘못된 아이디어를 구축하는 데 써야 함
  • 매우 시니어한 엔지니어라면 VP들이 조용히 이를 비난할 것이며, 그들이 옳음
  • 적시에 올바른 아이디어를 준비하는 것은 당신의 책임

두 가지 관점

  • 냉소적 관점: 회사를 운영하는 소시오패스들이 끝없는 내부 권력 투쟁에서 사용할 편리한 도구가 되라는 제안으로 읽을 수 있음
  • 낙관적 관점: 임원들이 회사의 전반적 우선순위를 설정하도록 하고(그것이 그들의 일이므로), 자신의 기술 계획을 거기에 맞추라는 제안으로 읽을 수 있음
  • 어느 쪽이든, 적시에 올바른 계획을 추진하면 더 많은 기술적 목표를 달성할 수 있음

Hacker News 반응 및 관련 인용

  • 이 글은 Hacker News에서 주목을 받았으며, 정치에 관한 다른 글들보다 훨씬 긍정적인 반응을 받음
  • 한 댓글은 Milton Friedman의 인용문을 언급하며 이 글의 아이디어를 일반 정치 정책에 적용
    • "위기(실제든 인식된 것이든)만이 진정한 변화를 만들어냄. 그 위기가 발생했을 때, 취해지는 행동은 주변에 있는 아이디어에 달려 있음. 이것이 우리의 기본 기능: 기존 정책에 대한 대안을 개발하고, 정치적으로 불가능한 것이 정치적으로 불가피한 것이 될 때까지 살아있고 이용 가능하게 유지하는 것"
  • 일부 댓글은 이 접근법을 지나치게 게임적이고 이기적이라고 비판했지만, 저자는 이것이 목표에 달려 있다고 봄
  • 한 댓글은 이 글의 요지를 잘 요약함: "지시를 기다리고 공백이 있을 때 나쁜 아이디어에 냉소적이며 원하는 것을 하지 않는 대신, 저자는 중요한 사람이 무언가가 우선순위라고 말할 때를 위해 제기할 좋고 중요한 아이디어의 백로그를 유지함. 타이밍에서 타협하면서 원하는 것을 완수함"

함께 보면 좋은 글 β

GN⁺   [-]
Hacker News 의견

  • 이 포스트의 요점은 다음과 같음

    1. 매니저가 명확하게 원하는 것이 있다면 그 일을 하면 됨
    2. 매니저가 명확하게 원하는 것이 없다면, 앞으로 그들이 필요로 할 만한 일을 미리 예측하고, 실행 가능한 준비를 해놓으면 됨 좋은 조언이라고 생각함. 다만 추가하고 싶은 점은, 가끔은 매니저와 리더십이 원래 요청과 약간 다른 결과물을 받아들일 수 있는데, 그게 더 높은 차원의 원래 니즈를 충족할 경우임. 물론 리스키하지만, 성공한다면 존중과 자율성을 빠르게 얻을 수 있는 방법임

    • 첫 번째 포인트는 당연하게 들릴 수 있지만, 경력 초기의 많은 사람들에게 여러 번 코칭해온 주제임 어려움이나 PIP로 향하던 많은 사람들이 아래의 루프만 잘 실행해도 전환점이 되었음

      1. 매니저에게 가장 우선순위가 무엇인지 직접 묻고, 상황에 변화가 있을 때마다 재확인함
      2. 그 우선순위를 기록해서 매일 눈에 보이게 관리함
      3. 완수할 때까지 우선순위에 집중하고, 끝났다고 생각되는 시점에 매니저가 정말 완료로 생각하는지 확인함 커리어 초기에 이 루프를 내재화한 사람에게는 쉽지만, 많은 사람들은 명확히 알려줄 때까지 잘 모름. 종종 산만해지거나, 매니저가 아닌 사람들에게서 너무 많은 일을 받아오거나, 흥미로운 일에 집중하면서 실제 매니저의 요청을 회피하는 경향이 있음

    • 2번을 나만의 어젠다 준비로 해석함. 예를 들어 코드베이스를 더 미니멀하게 만들고 싶다면, 기회가 왔을 때 바로 제안할 수 있도록 PoC와 관련 디테일을 준비함 준비한 덕분에 사이트 속도, SEO 관련 이슈나 버그가 터지면 그 미니멀 아이디어를 솔루션으로 제안할 수도 있음 이런 개념이 흥미롭기는 한데 실제로 어떻게 적용해볼지는 고민이 많음. 미래에 쓸 준비 문서를 만들어 둘까 고민도 자주 함. 블로그 운영하듯 내 작업을 꾸준히 문서화하고 기회를 기다리는 식임 많은 추가 작업이 헛되이 끝날 수도 있지만, 사실 그런 일은 이미 많이 하고 있다고 생각함

    • 한 가지 더 추가하고 싶은 점은, 내 매니저보다 더 정치적 힘이 센 사람들이 반대하는 일을 함부로 하지 말라는 것임. 단, 누구든 그보다 더 힘 있는 사람이 공개적으로 지시하면 예외임 그들이 원하는 것을 굳이 하라는 게 아니라, 괜히 그 사람들을 불쾌하게 만들지 않도록 조심하는 게 중요함 적은 만들 가치가 거의 없고, 대부분의 매니저들은 위기 상황에서 자기 보호를 위해 나를 희생양으로 삼기도 함

    • 나는 매니저에게 ‘무엇을 해야 할지’ 직접 제안하는 쪽을 선호함. 중요한 이슈를 테이블에 올리고 그 이유를 어필함 내 전문성을 통해 매니저가 이득을 보도록 적극적으로 나서야 함 나도 아직 이런 경험이 많진 않지만, 몇 번의 성공 사례는 있음

    • 이런 조언은 위로 올라갈수록 더 중요해짐. 엔지니어링 매니저에게도 마찬가지이고, 내가 CTO에게 직접 보고하던 디렉터일 때도 이 원칙을 적용하려 했음

  • 내가 좋아하는 인용구 중 하나가 있음: "실제 위기, 혹은 인식된 위기만이 진정한 변화를 만듦. 그 때의 행동은 주변에 돌아다니던 아이디어에 의해 결정됨. 우리의 기본 기능은 대안적 정책을 개발하고, 그것을 계속 살아있게 만드는 것, 그리고 정치적으로 불가능해 보였던 것을 정치적으로 불가피하게 만드는 것임" - Milton Friedman 1 Pager와 기술 문서를 작성해서 미리 공유해 두고, 위기가 닥쳤을 때 다시 인용하는 방식이 내 아이디어를 띄우는 데 효과적이었음 내가 원하는 아키텍처 방향을 점진적으로 밀어붙이며 점점 목표에 다가간 적이 있었고, 합의를 쌓는 게 중요함 물론 나보다 정치 기술이 뛰어난 VP나 디렉터에게 밀린 적도 많았음 하지만 1 Pager 라이브러리를 준비해두고, 슬쩍 공유해서 계속 공기 중에 ‘퍼뜨려’ 놓고, 실행할 동기가 생길 때까지 기다리는 방식이 훨씬 효과적이었음

    • "정치 싸움에서 졌다"는 부분에 공감함. 중간 관리자 이상이 되고 느낀 놀라운 점은, 하위 레벨 임직원이 정치질을 하는 것이 굉장히 잘 보인다는 것이었음 많은 IC나 1레벨 EM은 자기 정치적 감각이나 소셜 IQ를 과대평가함 또, 조직 내 커뮤니케이션의 깊이나 폭이 달라서, 누군가를 설득한다 생각하고 움직여도 그 스테이크홀더가 종료 후 관리자에게 슬쩍 정황을 알려버림 우리가 관리팀에서 어설픈 정치질을 조용히 통제하려고 노력하면서, 여러 번 이런 장면을 목격했음

    • "1 Pager와 기술 문서를 떠돌게 한다"는 게 구체적으로 어떤 방식인지 궁금함

    • 저 인용구에 공감하고 이 방법이 효과 있을 것 같음. 다만 현실에서는 시간 스케일이 미칠 듯이 길어서 지칠 수 있음 또, 위기가 아예 무시되는 경우도 많아서 통상적으로 인식되지 않거나 정상화되어 버릴 때도 있음

    • 1 Pager 덕분에 인정을 받고 커리어도 승진할 수 있었는지, 아니면 아이디어가 실제로 실현되는 데만 도움이 되었는지 궁금함

  • 내가 생각하는 가장 좋은 방법임

    • 자주 프로덕션에 배포함(이론적인 작업보다는 현실적인 딜리버리 중심)

    • 의미 있는 결과(wins)를 달성함(합의된 메트릭으로)

    • 매니지먼트나 PM 중 내 성공을 잘 팔아줄 ‘세일즈맨’이 있음 하지만 여전히 문제가 생김. 언제나 새로운 VP나 리더가 혁신을 보여주려고 함. 기존 시스템을 유지관리하는 팀은 틀렸다고 찍히고, 새 VP는 AI 등 진보적인 아이디어로 자신의 노선을 강조함. 내 코드가 배포되는 순간부터 "레거시" 취급받음 그러면 VP는 화려한 미래의 약속을 막 던지는데, 지금 현실을 유지하는 내 역할로는 절대 경쟁이 안 됨. 현실은 섹시하지도, 재미도 없으니까. 그렇게 구세력이 되어버림 결국 본질은 후견인 관계, 즉 내 윗선 VP를 성공시켜주고, 그 사람이 이직할 때 같이 옮겨가는 포지션을 만드는 일임

    • 정말 맞는 말이라고 생각함. 한 단계 더 들어가면 staff engineer로서 "나는 코드 그 자체가 아니다"라는 인식을 확실히 주는 게 중요함. 코드는 배포되는 순간부터 부채/레거시임 나는 "코드 옹호자"가 아니라 리더십, 제품, 의사결정권자 등과 EQUAL PARTNER로 자리매김하는 게 베스트임. 이건 단순히 관점의/frame의 문제임. 똑같은 행동을 해도 내가 ‘업무의 동반자’로 보이면 리더들이 나를 적극적인 조력자로 여기고, 그렇지 않으면 억지로 설득해야 하는 걸림돌로 환산되어 차이가 큼

    • "PM 중 내 성과를 잘 파는 사람이 있어야 한다"는 말에 크게 공감함. 돌이켜 보면, 커리어에서 가장 큰 변화를 만들 수 있었던 건 나쁜 PM에게서 벗어나는 속도였을 것임 좋은 PM은 모든 것을 개선시키지만 찾기 어려움. 반대로 PM이 방향을 잘 못 잡으면 모두 망가지고, 해당 PM만 없어진 순간 기류가 확 바뀌었음

    • "미래 약속 경쟁이 안 된다"는 표현이 정말 좋았음. 그런 경우가 너무 자주 일어남. 심지어 그 약속이 이전 26번이나 지켜진 적 없어도, “영광스러운 미래”는 언제나 대단하기 마련임

    • 실제 일하면 자주 프로덕션에 배포한다는 개념(rep=실행 중심, 이론 금지)은 좋은데, VP가 뜬구름 잡는 미래 약속은 왜 실현 가능성보다 더 가치 있게 여겨지는지 의문임

    • ‘이론적 작업’이라는 말을 들어본 적은 없지만, 매일 배포하는 곳은 분명 존재함. 하지만 자주 배포하는 게 이상적이지 않다고 생각함. 하루 만에 실질적인 무언가를 어떻게 배포할 수 있는지 의문임. 나처럼 회사에 추가 매출을 주는 프로젝트는 하루 만에 끝낼 수 없음. 하루에 끝날 업무였다면 연간 네 번만 엔지니어가 필요하다는 소리와 같음. 그래서 이런 ‘자주 배포’는 오히려 Vanity Metric임

  • 나도 dysfunctional(비효율적)한 회사에서 일해본 적이 없어서, 이 글의 첫 부분에 공감이 전혀 안됨 내 경험상, 항상 탑-다운 커뮤니케이션이 활발했고, 내가 동의하지 않는 방향으로 개발하더라도 사전에 충분히 논의해서 왜 똑똑한 동료가 나와 다르게 보는지 흥미로운 지점이 생겼음 엔지니어가 창업한 회사에서만 일했기 때문인지, 아니면 단순히 운이 좋은 건지 잘 모르겠음

    • 대형 기업의 상위 VP들은 목표도 광범위하고, 수단의 개념도 더 광범위함. 꼭 나쁜 것만은 아님. 특정 기술이나 방법론에 고정되기 전에 여러 방안을 시도할 기회가 있음. 물론 낭비도 있지만, 산업의 지각 변동에 즉각적으로 대응해서 경영진의 임무를 충족하는 데 효율적이기도 함

    • 어떤 규모의 회사에서 일해봤는지 궁금함

  • "조금 더 어려운 길이지만 더 많은 통제권을 얻는 방법은, 내가 가진 아이디어를 기존의 정치적 캠페인에 합류시키는 방식임" 나는 VP가 주도하는 프로젝트에 잘 빌붙는 기술을 터득했음. 씁쓸하지만 효과는 확실함

  • 이 캠프에서 흔히 듣는 좌절의 목소리는 “난 코드 전체 리팩터링을 완벽하게 해놨는데 아무도 알아주지 않는다”는 것임 예전 지인이 데이터 파이프라인을 수개월간 완벽하게 청소했다고 자랑했지만 아무도 그 가치를 몰라준 것을 들으며 여러 생각이 들었음 엔지니어인 나는 이런 일이 가치 있다는 걸 알지만, PM/EM 관점에서는 마치 PM이 한 달간 사내 모든 엔지니어링 문서를 점찍어서 정렬했다고 하더라도 “그래서 회사에 무슨 영향이 있지?”란 반응과 비슷하다고 생각함 PM 입장에선 영향력 있는 엔지니어와 ‘단순 포맷팅 작업’만 하는 엔지니어를 어떻게 구분해야 할지 모호해짐 결국은, 계획하고 있는 일을 사전에 비-기술인 관객에게 맞는 포맷으로 명확히 설명하는 게 중요함 예전에 유닛 테스트와 통합 테스트를 밀었지만 정치적 의지가 부족해서 번번이 우선순위 안에 못 넣었음. 실제 큰 SEV(중대 사고)가 터지고 나서 "이런 걸 막으려면 테스트가 필요하다"고 얘기하니 그제야 모두가 가치에 동의했음. 이제는 누구나 테스트의 필요성을 이해하고 있음

    • 정말 동의함. 만약 내가 어떤 행동을 우선순위로 추진하는 입장이라면, 그걸 우선순위를 결정하는 사람의 논리와 언어로 설명해줘야 내 말이 먹힘 예를 들어, PM은 통상적으로 화폐 단위로 생각함. 테스트 커버리지 확장 등 내 기술적 목표가 연간 200 dev hour를 필요로 하지만 연간 400 dev hour를 절약할 수 있다, 지원 티켓을 15% 줄일 수 있다, 미래 비즈니스 시나리오를 가능하게 한다, 등으로 제시하면 훨씬 더 설득이 쉬워짐 내가 좋아하는 트릭은, tech debt 작업을 "기술 작업"이 아니라 명확한 비즈니스 효과로 포장해서, 오히려 PM이 스스로 로드맵에 넣게 만드는 것임 이런 방식은 경력이 쌓일수록 더 쉬워짐. 처음엔 회의적이더라도 시간 지나면 내 추정과 성과의 신뢰도가 쌓이고, 전에는 몇 번의 회의가 필요했던 일들이 이제는 10분짜리 대화로 끝남

    • 이 의견에도 동의함. 하지만 역으로 생각해볼 수도 있다고 느낌 예를 들면, 건설현장에서 누군가 안전 시스템을 꼼꼼히 검사하고 유지해서 사고를 예방했다고 해도, 매니지먼트는 그 가치를 전혀 인정하지 않고 보상을 주지 않는 일이 많음 정량적으로 ROI로 표시되지 않으면 어떤 이득도 인정하지 않는 것 자체가 매니지먼트의 엄청난 실패이고, 안전이 생명과 직결된 경우에는 도덕적 실패이기도 함 실제로는 이것이 지금 Boeing에서 일어나고 있는 현실임

    • 청중이 이해할 수 있는 가치로 설명하는 게 포인트임. 이건 결국 영업 스킬인데, 대다수 개발자는 경험도 없고 알아차리기 어렵다고 생각함. 좋은 매니저가 잘 지원해주면 이상적이고, 나와 마인드가 맞는 staff dev, engineering manager가 함께 하면 정말 성과가 크게 남 나도 이런 동료들과 협업할 때 늘 고마움을 느낌

    • 손 씻기의 필요성을 굳이 설명해서 투자 결정을 받아야 한다면 팀에 뭔가 문제가 있음. 탑 클래스 레스토랑 셰프에게 '비누를 살지 말지'로 설득할 필요 자체가 없는 것처럼, 그런 게 당연한 조직에 들어가는 게 경력의 한 단계라는 생각임. 성공한 SWE는 그 수준이 기본인 팀에서 일하는 사람임

    • 동의함. 리팩터링은 개발자가 자연스럽게 책임지는 일임. 기능 개발할 때 자연스럽게 같이 진행해서 마감 일정 업데이트하면, 기술자들끼리만 소통하면 되니 훨씬 설득이 쉬워지고, 장기적으로 코드베이스 퀄리티가 급격히 좋아짐. 그 결과 유지보수가 쉬워지고 신규 기능 개발이 빨라짐

  • 내가 쌓을 수 있는 최대의 정치적 자산은 나의 기술적 이해와 역량임. 하지만 이 힘은 회사 전체 전략과 맥락 안에서 조언하고 실질적으로 딜리버리할 때 쓸모가 있음 적절한 조언을 하고 회사를 위해 실천하면 사람들이 나에게 귀를 기울이고 의존하게 됨. 결국 내가 방향을 정할 수 있는 권한이 만들어짐 별도의 플랜B 같은 리스크 관리안을 준비하고, 그것을 필요할 때 제안, 실행하는 것이 최고의 방법임

    • "플랜을 준비해서 필요할 때 실행한다"는 접근법을 더 자세히 듣고 싶음. 플랜을 어디에, 어떻게 저장하고 있는지 궁금함

  • 꽤 과격하지만 좋은 포인트를 담고 있는 커리어 서적이 있음 그 중 하나는 기술적 능력이 오히려 내 커리어와 파워에 해가 될 수 있다는 것임. 내 시간과 에너지를 실제 무언가 행동하는 데 쓰면, 유능한 매니저는 내가 가급적 정치적으로 영향력을 못 가지도록 내 자리에 묶어두려 적극적으로 노력함 반대로 매니저가 되면, 아무 일도 실제로 하지 말고 이니셔티브(프로젝트, 정책, 변화)를 가능한 많이 시작해서, 내가 가진 정치력을 능수능란하게 조율하면 됨 그 이니셔티브가 실제 가치 창출에 성공하는 것은 중요하지 않고 아예 신경 안 써도 됨. 나는 이미 판을 떠났고, 여전히 여기서 성공과 가치에 집착하면서 일하는 사람들은 뒤처지는 것임 필요하다면, 매니저는 사후적으로 ‘내가 했다’고 크레딧만 가져가도 됨

    • 조금 다르게 생각함. 정치적 사다리에서 더 위로 올라가고 싶은 매니저들은, 본인 정치 목표를 공개적, 사적으로 잘 지지해주는 부하에게는 얼마든지 영향력을 부여함 본인을 밑에서 밀어주고, 위에서는 끌어줘야 하거든. 단, ‘코스트’ 타는 매니저라면 경쟁자를 만들기 싫어서 아무에게도 영향 안 줌 엔지니어들은 종종 두 종류를 구분 못 하고, 쓸데없는 자존심 때문에 도리어 매니저를 무너뜨리려 함

  • "Flavor of the month"에 맞춘 태세 전환 전담팀들이 있어야 일이 된다 - 이게 내 정치 이론임. 워싱턴 DC도 마찬가지임. 거대한 계획은 없고, 찬스가 오면 바로 피칭할 군단이 상시 대기 중임

    • 단순히 슬라이드만 있는 게 아니라, 로비스트들은 이미 입법 초안까지 써둠

  • 정치싸움을 연습하고 권력을 쌓아야 한다면, 새로운 회사를 찾는 게 맞음 내가 순진하다고 생각할 수 있지만, 모두 그런 회사만 있는 게 아님. 내 회사는 그렇지 않음

답변달기