Hacker News 의견

• 몇 년 전에 Hacker News에 "Mochary Method"란 이름의 구글 문서 세트가 공유된 적이 있었음, 이 자료는 이런 식의 매니지먼트 스킬을 매우 인간적인 시선으로 다루고 있어서 비매니저인 나에게도 정말 와닿았음, 북마크해서 자주 참고하고 있음

  • 실수에 대응하는 법 문서가 있음

  • Matt가 좀 더 상세하게 설명하는 동영상도 있음

  • 해당 기사와 비슷한 접근 방식이지만, 필요하면 "rewind and redo"를 적극적으로 권장함

  • 전체 커리큘럼 링크도 공유함

  • 혹시 그 모든 구글 문서들의 링크를 가지고 있으면 공유 가능한지 궁금함, 대부분의 내용이 상식일 수도 있지만, 글로 정리된 것을 보는 것만으로도 멈춰서 생각하게 되고 더 나아질 수 있다고 생각함

• 내 경험상 IC(Individual Contributor)와 매니저의 가장 큰 차이는 '책임감'임

  • 미안하다고 말하는 것은 쉽지만 진짜 좋은 매니저가 되기 위해 내가 최선을 다하는 부분은 나 자신에게 책임감을 갖는 것임

  • 구체적으로 1) 무슨 이슈가 발생했는지 정확히 파악하고(특히 내가 원인일 때), 2) 재발 방지 시스템을 마련하는 것임

  • 직원들은 매니저가 책임감이 부족하면 정말 확실히 느끼게 됨. 특히 중간 이상, 상위 매니지는 실제로 업무 생산성과 인생의 질 전부를 향상시키고 싶으면, 말로만 잘못했다고 끝내지 말고 본인의 리소스를 걸어서 동일한 문제가 재발하지 않게 시스템을 개선해야 함

  • 보통 이건 무리하게 업무를 더 주지 않고, 우선순위를 잘 조정하거나 필요시 "노"를 더 잘하는 것임

  • 2번에 대체로 동의하지만, 시스템을 너무 많이 도입해서 오히려 아무 일도 못 하게 될 수 있으니 균형이 가장 중요한 것임

  • 당신이 말한 것과 더불어, 나쁜 매니저의 최악의 형태는 실수를 바로잡는다면서 본인을 보호하려 애쓰는 유형임. 이런 매니저는 지나치게 신경질적이고 갈등을 못 견뎌서, 개별 실수나 문제 상황마다 임의의 시스템을 만들어 회피함

    • 이런 유형은 시스템 자체를 재평가하지 않고 자기 자아 방어를 위해 시스템을 둠
    • 예를 들어 “이 직원은 내가 별로 마음에 안 들어서 부족한 것처럼 느껴지고, 어차피 시스템도 있으니!”처럼 생각함
    • 적응에 어려움을 느낌. 충분히 위임하려면 신뢰가 필요하지만, 실무를 직접 다 하지 않게 하려면 타인을 신뢰해야 하는데, 이를 못 함
    • 이런 사람은 커뮤니케이션 덕분에 승진했다고 착각하지만 실은 성장할 여지가 있다는 사실을 스스로 깨닫지 못함

  • 실수를 인정하는 매니저가 승진도 그만큼 자주 할 수 있을지, 아니면 적당히 숨기는 게 더 승진에 유리할지 궁금함

  • 좋은 시스템적 사고와 지속적으로 성장하고자 하는 동기나 인센티브가 결합되면 진짜 좋은 매니지먼트가 나온다고 생각함

  • 누군가에게 신뢰가 가는 이유는 자신과 자신의 행동에 책임을 지되, 타인이나 타인의 행동까지 책임지려 들지 않는 경계가 확실한 것임, 매니저, 직속 부하, 동료 모두에게 이 한가지만 바라는 마음임

• 이 내용은 엔지니어에게도 똑같이 적용된다고 생각함

  • 나에게 senior developer에게 가장 바라는 핵심 스킬은 '겸손함'임, 경력이 아니라 태도의 문제임

  • 실수를 부정하거나 독선적인 시니어는 팀을 독으로 물들임, 반면 주니어 의견도 듣고 피드백을 받아들이는 시니어는 모두가 신뢰하고 따른다고 생각함

  • 우리는 모두 인간임. 심지어 LLM조차도 실수함

  • 내가 면접에서 제일 주의 깊게 보는 건, 지원자가 "잘 모르겠습니다"라고 말하는 순간임

    • “모른다고 말 못 하는” 사람과 같이 일한 경험이 별로였음

  • 정말 공감됨, 많은 사람이 좋은 매니지먼트 스킬과 뛰어난 시니어 엔지니어 스킬이 상당 부분 겹친다는 걸 잘 모름

    • 방향 제시, 힘든 피드백 주고받기, 동료 성장시키기, 스트레스 대화에 현명하게 임하기 같은 걸 말함
    • 이런 스킬 없이 "기술 하나만 믿고" 실력주의만 추구하는 엔지니어는 커리어 한계가 명확함
    • 팀 내에 기술적으로 훌륭한데도 이 점 때문에 내보낸 인원이 있었음
    • 기술 업계에서 정말 아무에게도 안 섞이고 혼자 코딩만 하며 성장하는 포지션은 매우 드물고 특히 위로 갈수록 더 어려움

  • 지금까지 "이건 선생님에게도 해당!", "부모에게도 해당!", "엔지니어에게도 해당!" 의견이 나왔는데 결국 인간이면 누구에게나 해당되는 이야기임

  • LLM도 실수 많이 함, 현재 다른 창에서 LLM이 내 사이트 CSS 고치려고 계속 반복 작업하고 있음

  • LLM은 대놓고 자신만만하게 헛소리를 많이 하므로 주의해야 함

    • 하지만 사회적으로는 겸손이 오히려 불이익을 받고, 자신감은 보상받는 구조임
    • 그래서 겸손해지려 하지 않는 사람이 많은 건 본인에게 불리하게 작용할 걸 알기 때문임

• 전직 교사 겸 코치로서, 아이들과 신뢰 쌓을 때 꼭 이 방식을 썼었음

  • 너무 자주 '내가 완벽한 리더, 너희는 불완전한 학생' 식 관계로만 접근하는데, 그런 분위기로는 진짜 교감이나 개성 존중이 어려움
  • 난 항상 다 같이 인간이고, 실수도 하고 도전도 하면서 롤모델과 신뢰가 함께 성장한다고 믿어왔음

• 팀원(Implementer)은 아기가 아니고 매니저는 부모가 아님

  • 진짜 중요한 매니지먼트 역량은 매니저가 본인이 팀의 일부임을 인식하고, 사과 방법보다 팀의 목표를 이루는 데 집중하는 것임

  • 기사에서 말하듯 “진짜 일하는 소프트웨어를 배포하고, 팀 성장을 돕고, 모두가 최선을 낼 수 있는 환경을 만드는 것”이 진짜 매니저 역할임

  • 매니저가 자신의 인간미를 강조하며 감성적으로 사과를 하든 아니든, 반복적으로 똑같은 실수를 계속하면서 내 일에 방해만 안 한다면 진짜 별 상관없음

  • 인용한 책도 틀린 건 아니지만 좀 좁은 시각임, 관계에서 정말 중요한 건 rupture(균열)이 아닌 repair(회복)임

    • work 관계도 결국 인간관계라는 게 보편적인 상식이라고 생각함
    • 만약 당신이 감정적으로 일에서 완전히 분리된 소수라 해도, 대부분 사람은 인간관계를 직장에 끌고 들어옴. 이를 묵살하는 건 나쁜 매니저가 되는 1단계임
    • 그렇다고 해서 적절한 경계선, 피드백 없이 다 포용하라는 건 아님
    • 뛰어난 매니저는 각자 직원의 개인적 니즈에 맞게 접근법을 바꾸고, 본인이 위 글을 진심으로 믿는 직원이라면 딱 할 말만 하고 결과 중심적으로 일함
    • 개인적 경험으로, ‘감정은 나쁘다’는 관념에 익숙해진 사람이 가장 관리하기 힘들었음. 마음엔 무덤덤하다가도 결정적으로 감정이 건드려지면 갑작스러운 행동이 생김
    • 내가 선호하는 타입은 감정 표현을 적절히 해주는 사람임. 실수했다거나 피드백에 감정이 생기면 바로 말해주는 직원이 오히려 더 쉽게 소통, 공감하며 피드백과 한계를 동시에 관리할 수 있음

  • “관리자가 자기 잘못을 드라마틱한 방식으로 사과하든 말든, 반복되지 않게만 해주면 됨”이라는 당신 시각에는 공감하지 않을 수 있지만, 관리자가 자신의 기준만을 그대로 적용하면 오히려 문제가 됨

    • 관리자가 "이 직원은 신경 안 쓴다고 해도, 또 다른 사람은 전혀 다르게 받아들일 수 있다"는 걸 반드시 기억해야 함
    • 매니저가 그런 점을 간과하면 더 큰 실수를 하게 됨

• 내게 최고의 매니저는 임원진으로부터 팀을 보호하는 능력이 가장 뛰어났음

  • 엉뚱한 순간에 데드라인을 갑자기 줄이라는 요구나 이상한 신규 기능 요청 등 말도 안 되는 요청을 임원진에게 단호히 "NO" 했었음
  • 인수합병 당시에도 내 이름을 높여줘서 감원 명단에서 살아남음
  • 본인 연차가 많고 승진에 관심 없어서, 나쁜 매니저들이 팀을 버리고 본인만 살려는 모습과 확실히 달랐음

• 내가 인정하거나 고치기 제일 힘든 실수는 채용 실수임

  • "이 사람은 꼭 잘 해줄 수 있다"는 신념으로 오래 버텨봤는데, 팀이 커지다 보니 문화적으로 안 맞는 사람 하나가 비용이 너무 커짐

  • 예전엔 기회를 충분히 주다가 결국 PIP(Performance Improvement Plan)로 전환했는데, 너무 오래 끌면 팀 전체가 더 힘들어지는 걸 깨닫고 요즘은 더 빠르게 절차를 밟음

  • 직원의 역량 부족보다 기술적 실수를 인정하는 게 훨씬 쉬움, 특히 사람이 착할수록 더 힘듦

  • 상대가 힘든 캐릭터일 땐 조금 더 수월하지만, 어쨌든 직원 문제는 항상 어려운 숙제임

  • 나도 한때는 모든 사람을 코칭해서 퍼포먼스를 끌어올릴 수 있다고 믿었음

    • 하지만 경험상, 팀원 모두가 서로 믿고 잘 지내야 생산성이 몇 배 오름
    • 단 한 명의 어울리지 않는 사람만 있어도 팀 전체에 엄청난 부정적 영향이 있음

• 이 조언이 정말 좋다고 생각함

  • 내면 성찰이 있고, 솔직히 더 나아지고 싶은 매니저라면 큰 도움이 될 것임

  • 하지만 그런 매니저는 극히 드묾

  • 대부분 자신의 편견과 약점을 스스로 인지 못하고, 진정한 의미의 실적 리뷰나 생산성 평가도 없으며, 사실상 매니저 역할이 주주 권한의 대행자 역할로만 규정된 경우가 대다수임

  • 팀을 위해 진짜 잘하고 싶어서 노력하는 엔지니어링 매니저가 있다면 진심으로 박수 보냄, 찾아보기 힘듦

  • 하지만 IC(개별 실무자)의 입장에서는 나쁜 매니저 밑에서 벗어날 방법은 직장이나 팀을 옮기는 것뿐임

  • 동의하지만, 그마저도 쉬운 선택은 아님

• 좋은 매니저와 "자리를 지키는" 매니저는 다른 존재라는 게 문제라고 생각함

  • 인센티브가 전자가 아니라 후자에 더 강하게 맞춰져 있음

    • 요즘 나도 그런 생각이 더 강하게 드는 중임. "인센티브가 뭔지 알려주면 결과가 뭔지 보여줄 수 있다"는 말이 점점 진리처럼 느껴짐
    • 직장, 생계 등 '진짜 중요한 순간'이 오면 인센티브가 거의 전부를 결정함, 개개인의 의지는 그 틈새에 적은 정도라고 느낌

  • 예전에 한 매니저가 자기 손으로 뽑은 모든 사람을 해고함, 나는 남은 인원 중 하나였는데 동료를 감쌌다고 나도 잘림, 옆 사람은 강등 됨

    • 결국 회사 상황이 안 좋아지자 그 매니저 포함 많은 매니저가 해고당함
    • 내 친구는 “이제 여기 나가면 프로그래밍 업계 영영 떠난다”고 할 정도였음, 너무 아쉬운 일이라고 생각함

  • "great flattening" 얘기 많이 하지만, 정작 management layer는 layoff에서 유독 면역력이 강한 것 같음

    • 대기업은 매니지먼트 레이어를 끝없이 원함, CEO들이 관리직 하나도 항상 반기더라는 게 내 체감임

• 지난 50년간 미국 문화의 가장 큰 변화는 "잘못되는 것"보다 더 최악은 없다는 정서임

  • 이 현상은 공적 영역이든 회사든 일관적으로 나타나는 걸 봄
  • 어떻게 해결해야 할지 모르겠지만, 사람들에게 "미안하다"거나 보상할 기회를 허용하지 않는 것, 그리고 그것을 안 하는 사람들에게 책임을 묻지 않는 게 사회 문제의 큰 두 축이라고 봄