Hacker News 의견들

• 예전에 한 매니저가 “가끔은 사람을 실패하게 놔둬야 한다”고 말했던 게 떠오름
  어떤 사람들을 계속 떠받치는 데 너무 많은 에너지가 들었음. 언젠가는 스스로 헤엄치길 바랐지만, 때로는 그 노력이 더 나은 곳에 쓰이는 게 맞았음
  내 참여 없이 진행된 프로젝트가 있었는데, 내 지식 없이는 절대 성공할 수 없었음. 그 팀은 너무 형편없어서 질문을 일처럼 섞어가며 일했음
  게다가 경영진이 내 팀을 깎아내리고 그들을 칭찬한다는 걸 알게 되었을 때 정말 모욕감을 느꼈음. 그들의 구현은 끔찍했음

  • 나는 “가끔은 매니저를 실패하게 놔둬야 한다”고 자주 말함
    어떤 매니저들은 자신의 아이디어가 안 통한다고 말하는 걸 싫어함. 반박하면 실패의 원인으로 몰림
    그래서 나는 일을 진행하되, 그들에게 자주 상황을 공유함. 그래야 그들이 예상된 실패를 직접 보게 되고, 나를 실패와 분리시켜줌
  • 경영진이 실패하면 서로를 탓하지 않음. 대신 컨설턴트를 불러 시니어 엔지니어를 해고함
  • “사람은 스스로 데이터를 모아야 한다”는 말을 들은 적 있음. 결국 직접 부딪혀봐야 배움
  • 사람의 실패와 프로젝트의 실패는 다르다고 생각함
    개인의 실패는 비용이 적고 교육적임. 오히려 그들의 접근이 통할 때도 있어 조직이 새로운 지식 자산을 얻기도 함
  • 사람을 스스로 배우게 두는 건 위험한 일임. 그들이 자기 인식을 갖고 있는지, 내 지원에 기대고 있지 않은지 믿어야 함
    실패하고 배우지 못할 수도 있음. 하지만 최선을 다했다면 양심의 평안은 가질 수 있음

• 프로젝트의 “나쁨”은 대부분의 생애주기 동안 주관적임
  외부인이 프로젝트를 반대하며 중단시키려 한 적이 있었는데, 끝내 출시해 성공하자 그들의 신뢰가 무너졌음
  평판을 어디에 쓸지 신중해야 함

  • 나도 비슷한 일을 겪었음. 협업을 위한 조직에서 이렇게 노골적인 이기심을 본 건 처음이었음
    세상은 항상 햇살과 무지개로 가득하지 않다는 걸 알지만, 그때는 정말 실망스러웠음

• “내 원숭이 아님, 내 서커스 아님”이라는 말처럼, 내 책임이 아닌 일엔 관여하지 않음
  아키텍트로 일할 때도 내 영역이 아닌 UI나 비즈니스 로직엔 불필요한 조언을 하지 않았음
  상위 매니저가 결정한 일엔 그냥 따름. 컨설턴트로 일하면서도 같은 원칙을 지킴
  내 전문 분야에서만 조심스럽게 개입함. 그것도 C-suite의 승인이 있을 때만 함

• 이 조언은 중소기업엔 꽤 적절함. 하지만 대기업에선 프로젝트에 반대 의견을 내는 게 거의 의미 없음
  성공하면 바보처럼 보이고, 실패해도 기억되지 않음
  진짜 ROI는 실패 후 해결책을 제시할 때 생김. 사람들은 “문제 해결사”를 좋아함
  예전에 자동화된 E2E 테스트를 제안했다가 거절당했는데, 나중에 문제가 터지자 그 프레임워크를 꺼내와 영웅 취급을 받았음

  • 회사에서 위로 올라갈수록 남의 잘못에 책임을 져야 하고 보상은 적음
    차라리 하위 직급에서 스트레스 없이 사는 게 현명하다고 느낌
  • 스타트업은 몇 명의 엔지니어가 “이건 말도 안 돼”라고 말하면 재앙을 막을 수 있음
    반면 대기업은 정치 때문에 수년과 수백만 달러를 낭비함

• “문제를 무시하면 안 된다”는 입장임
  도울 수 있는 위치라면 조용히라도 다른 접근법을 제안해야 함. 굳이 감정적으로 대응할 필요는 없음

  • “도울 수 있는 위치”라는 조건이 핵심임
    작은 조직에선 좋은 아이디어가 쉽게 반영되지만, 큰 조직에선 정치적 리스크가 훨씬 큼
    실제로 도울 확률보다 평판을 잃을 확률이 더 높음. 그래서 싸움을 고르는 게 중요함
  • 작은 조직에선 초기에 개입하는 게 의무일 수도 있음
    하지만 큰 조직에서 이미 진행 중인 프로젝트를 바꾸려면 막대한 시간과 에너지가 듦
  • “나쁜 프로젝트를 그냥 두라”는 표현은 오해의 소지가 있음
    사실 우리는 그 프로젝트를 통제할 수 없을 때가 많음. “다른 팀이 왜 그렇게 하는지 모른다”가 더 정확한 제목임
  • 나도 실패가 예상되면 문서로 의견을 남기고 끝냄
    프로페셔널리즘이란 말해야 할 때 말하는 것임. 하지만 경험상 바뀌는 일은 거의 없음
  • 알고 있다면 말하되, 그 후엔 감정적 부담을 지지 않음. 조언을 무시당했다면 그건 내 문제가 아님

• 지금 실제로 이런 상황을 보고 있음
  사업주가 비용과 속도 때문에 로우코드 플랫폼을 선택했는데, 결국 거대한 해킹 수준의 커스터마이징이 필요해짐
  내 팀은 TypeScript로 하루에도 여러 번 배포하지만, 그 팀은 한 달에 한 번 배포하며 curl로 이상한 짓을 하고 있음

• 이 조언은 빅테크의 정치적 현실에선 훌륭하지만, 결국 기업적 평화주의 같음
  다른 환경에서는 돈과 동기를 태워버릴 여유가 없음
  (그래도 Lalit은 복잡한 조직 역학을 짧은 글에 잘 담음)

  • 나는 빅테크에서 일해본 적 없지만, 작은 조직에서도 같은 현상을 봄
    계속 트집 잡는 사람은 결국 부정적인 사람으로 낙인찍힘
    결국 중요한 순간을 위해 에너지를 아껴두라는 게 핵심 조언임. 모든 문제가 회사의 존망을 좌우하진 않음
  • 평화주의는 무행동이 아님. 오히려 가장 적극적이고 효과적인 정치적 행동임

• 엔지니어는 정치적으로 나쁜 프로젝트를 “실패하게 놔둘” 권한이 없음
  그건 경영진의 책임임. 엔지니어는 기술적 조언만 하면 됨
  다만 이런 역학을 이해해야 커리어에 영향받지 않음
  제품팀과 플랫폼팀의 영역 다툼은 명확한 리더십의 부재 때문임
  이런 일이 왜 자주 일어나는지 궁금하다면, Google 관련 글을 참고할 만함

• 이런 사고방식은 대형 조직, 특히 정부 기관에서 흔함
  비용은 다른 부서가 부담하고, 관리 인원 수로 권력을 측정하는 구조임
  이런 조직적 괴사를 막으려면 리더가 명확한 측정과 예방 체계를 세워야 함

  • 인간은 본능적으로 긍정적인 사람을 좋아하고 부정적인 사람을 싫어함
    정치적 자본을 무시한다고 사라지지 않음

• 좋은 비유임
  리더십과 신뢰를 쌓으면 “당신이 틀렸다”고 말할 수 있는 공간이 생김
  하지만 리더가 항상 엔지니어를 믿지 않는 이유는, 때로는 엔지니어가 틀리기 때문임
  엔지니어는 결함을 찾는 데 뛰어나지만, 비즈니스 맥락을 이해하는 데는 약함
  그래서 “멍청해 보이는 아이디어”라도 맥락을 이해한 뒤 판단해야 함
  진짜로 죽여야 할 아이디어와 그냥 결함이 있는 아이디어를 구분할 수 있을 때, 조직 내 신뢰를 얻게 됨