[개발자] 내가 싫어했던 매니저가 나에게 가르쳐준 교훈

내가 싫어했던 매니저가 나에게 가르쳐준 교훈 

https://www.blog4ems.com/p/the-manager-i-hated

The manager I hated and the lesson he taught me

• 지금은 엔지니어링 매니저가 되었지만 내가 소프트웨어 엔지니어로 일하던 시절, 복잡한 기능을 며칠간 작업해 PR를 올렸음
• 피드백은 단호하고 냉정했음 “오버 엔지니어링임. 복잡함. 리팩토링하시오”는 간단한 문장이 전부였음
• 칭찬 한마디 없이 비판만 받은 경험에 분노했으나, 그 매니저와의 일화는 단지 시작에 불과했음

감정을 배려하지 않는 리더 스타일

• 이 매니저는 기존에 알고 있던 리더들과 달랐음
• 손을 잡아주지도, 부드러운 말도 하지 않음
• 다음과 같은 특징이 있었음
  • 설익은 아이디어는 바로 거절함
  • 복잡함을 위한 복잡함을 싫어함
  • 깔끔하고 유지 보수 가능한 효율적인 코드만 중요시함
• 회고에서도 돌려 말하지 않고 문제를 직접 지적함
• 처음에는 냉혹한 성격이라 생각했지만, 그 이면에는 다른 철학이 있었음

자존심을 흔든 피드백의 전환점

• 스프린트 리뷰에서 자신 있는 기능을 시연했지만 매니저는 중간에 끊고 물음“이건 취약해. 부하 상황에선 어떻게 돼? 롤백 계획은?”
• 대답을 제대로 하지 못하자 매니저는 말함:“지금 넌 코더처럼 생각하고 있어. 엔지니어처럼 생각해야 해”
• 처음엔 화났지만, 결국 스스로의 코드 스타일이 회복력보다는 영리함에 치중했다는 걸 자각하게 됨

진짜 교훈: 그 매니저는 나를 개인적으로 공격한 게 아니었음

• 사고방식에 큰 변화가 생김
  • “똑똑한” 코드 대신 읽기 쉬운 코드를 작성함
  • 실패 상황을 대비한 설계에 집중함
  • 본인을 위한 코드가 아니라 후속 개발자를 위한 코드를 작성함
• 이후 그 매니저의 코드 리뷰는 거침없이 통과됨
• 매니저가 달라진 게 아니라, 나 자신이 성장했기 때문임

내 리더십 스타일에 남긴 영향

• 엔지니어링 매니저가 된 후 그 경험을 많이 떠올렸음
• 사람들이 싫어하는 리더는 되고 싶지 않았지만, 부드럽기만 한 리더도 되고 싶지 않았음
• 다음과 같은 방식으로 스타일을 정립함
  • 배경 설명이 있는 직설적인 피드백을 줌
  • 시스템적 사고를 강조함
  • 높은 기준은 유지하되 인간적인 피드백을 제공함
• 엔지니어들은 도전받는 걸 원하지만 무시당하는 느낌은 싫어함

단호한 매니저가 필요할 때

• 리더십에는 자존심, 마감, 압박이 얽혀 있어 혼란스러움
• 단호한 매니저는 다음을 통해 이 혼란을 걷어냄
  • 기능이 아닌 확장성을 생각하게 함
  • 영리한 코드보다 유지 가능한 코드를 쓰게 함
  • 실패와 예외 상황을 미리 대비하게 함
• 감정보다 코드의 생존 가능성을 더 중요하게 여김

단호한 매니저 아래에서 생존하고 성장하는 방법

• 숨 막히는 리더 아래에 있다면 다음과 같이 대처할 수 있음
  • 개인적인 공격으로 받아들이지 말 것: 피드백은 코드에 대한 것
  • 피드백 이후 “왜?”를 물어볼 것: 대부분 단호한 리더는 호기심을 존중함
  • 실패 지점을 스스로 먼저 생각해 볼 것: 매니저처럼 사고하기 시작해야 함
• 리더라면 다음을 실천해야 함
  • 높은 기준을 제시하되, 그 기준이 중요한 이유를 설명할 것
  • 모호한 피드백 대신 구체적으로 말할 것
  • 성공보다 성장을 축하할 것: 개발자가 매니저보다 먼저 문제를 포착했다면 칭찬할 것

거절된 Pull Request가 준 최고의 선물

• 처음엔 자존심이 상했지만, 지금 돌아보면 그 거절된 PR은 인생 최고의 기회였음
• 코딩을 개인 프로젝트가 아닌 시스템 구축으로 보게 되는 계기였음
• 단호한 매니저는 기분을 좋게 해주진 않지만, 개발자로서 성장하게 함
• 진정한 성장은 PR이 통과될 때가 아니라, 거절될 때 시작됨

 

저는 여전히 소프트웨어 엔지니어였습니다.

모든 것은 코드 리뷰에서 시작되었습니다.

며칠 동안 복잡한 기능을 작업했습니다. 수백 줄의 코드, 엣지 케이스 처리, 성능 조정까지 완료했습니다. 저는 그것이 자랑스러웠습니다. "풀 리퀘스트 생성"을 누르고 피드백을 기다렸습니다. 아마도 한두 개의 댓글 정도를 예상했습니다.

제가 받은 것은 잔혹했습니다.

"오버 엔지니어링. 너무 많은 움직이는 부분. 리팩토링."

그게 전부였습니다. "잘 했어요"도, "좋은 시도였어요"도 없었습니다. 그냥 단호한 중단이었습니다.

저는 화가 나서 앉아 있었습니다. '이 사람은 사람들을 깎아내리는 걸 즐기는 걸까?'라고 생각했습니다.

하지만 이건 시작에 불과했습니다.

내 감정 따위는 신경 쓰지 않는 매니저

그는 제가 함께 일했던 다른 리더들과는 달랐습니다.

어떤 손길도, 허세도 없었습니다.

그는 반쯤 익은 아이디어를 눈 하나 깜짝하지 않고 거절했습니다.

그는 영리함을 위한 복잡성을 혐오했습니다.

그는 한 가지, 즉 깨끗하고 유지 보수 가능하며 효율적인 코드에만 관심이 있었습니다.

스프린트 회고에서 그는 상황을 미화하지 않았습니다. 마감일을 놓쳤나요? 그는 "우리가 범위를 잘못 잡았어. 고치자."라고 말했습니다. 확장성이 없는 것을 만들었나요? "그건 기술 부채야. 감당할 수 없어."라고 말했습니다.

처음에는 그가 그저 엔지니어를 불행하게 만드는 그런 매니저라고 생각했습니다. 하지만 더 깊은 무언가가 있었습니다.

이런 게시물을 즐겨 읽으신다면, 제 작업을 지원하고 이 뉴스레터를 구독해 보세요.

무료 구독자는 다음을 얻습니다.

• ✉️ 주간 게시물 1개
• 🧑‍🎓 엔지니어링 매니저 마스터클래스 이용 권한

유료 구독자는 다음을 얻습니다.

• 🔒 50개 이상의 템플릿과 플레이북 (79달러 상당)
• 🔒 EM이 직면하는 실제 과제에서 나오는 주간 "당신이라면 어떻게 하시겠어요?" 시나리오 및 분석
• 🔒 전체 아카이브에 대한 완전한 액세스 권한 고성능 팀을 만드는 것에 대한 주간 기사를 읽는 최고의 엔지니어링 리더들과 함께 하세요!

구독하기

모든 것을 바꿔놓은 자아 점검

결정적인 순간은 스프린트 리뷰 중에 찾아왔습니다.

저는 그에게 깊은 인상을 줄 것이라고 확신했던 기능을 시연했습니다. 대신 그는 중간에 저를 끊었습니다.

"이건 약해. 부하가 걸리면 어떻게 되지? 롤백 계획은?"

저는 답을 찾기 위해 더듬거렸지만 제대로 된 답이 없었습니다. 그는 잠시 멈추더니 말했습니다. "당신은 코더처럼 생각하고 있어, 엔지니어처럼 생각하고 있지 않아. 실패를 견딜 수 있는 것을 만들어."

그것은 저에게 힘든 순간이었습니다.

저는 밤새도록 그 말을 곱씹었습니다. 처음에는 화가 났습니다. 하지만 생각할수록 그가 옳다는 것을 깨달았습니다. 저는 회복력이 있는 해결책이 아닌 영리한 해결책에 너무 집중하고 있었습니다.

진정한 교훈: 그것은 나에 대한 것이 아니었다

저는 제 일에 접근하는 방식을 바꾸기 시작했습니다.

저는 "똑똑한" 코드를 쓰는 것을 멈추고 읽기 쉬운 코드를 쓰기 시작했습니다.

저는 이상적인 경우뿐만 아니라 실패 시나리오를 염두에 두고 설계했습니다.

저는 저 자신을 위해 코딩하는 것을 멈추고 다음에 제 코드베이스를 건드릴 사람을 위해 코딩하기 시작했습니다.

그리고 놀라운 일이 일어났습니다.

그가 검토하는 제 풀 리퀘스트가 막힘없이 통과되기 시작했습니다.

그가 부드러워진 것이 아니었습니다. 제가 마침내 성장한 것입니다.

그것이 제 자신의 리더십 스타일에 미친 영향

제가 결국 엔지니어링 매니저가 되었을 때, 저는 그 경험에 대해 많은 생각을 했습니다.

저는 사람들이 싫어하는 그런 리더가 되고 싶지 않았습니다. 하지만 부드럽기만 한 리더도 되고 싶지 않았습니다.

그래서 저는 효과가 있었던 부분을 훔쳤습니다.

• 맥락이 뒷받침되는 잔혹할 정도의 솔직함. "이건 엉망이야"라고 말하는 대신 "이건 숨겨진 기술 부채를 만들어. 이유는 이거야."라고 말합니다.
• 시스템 사고에 집중. 저는 엔지니어들에게 그들의 티켓을 넘어 그들의 코드가 더 큰 그림에 어떻게 들어맞는지 생각하도록 밀어붙입니다.
• 높은 기준, 하지만 인간적인 피드백. 저는 단지 결함을 지적하는 것이 아니라 나아갈 길을 제시합니다.

저는 엔지니어가 도전을 원하지만, 그 과정에서 무시당하는 느낌을 받고 싶어하지 않는다는 것을 알게 되었습니다.

왜 터프한 엔지니어링 매니저가 당신에게 꼭 필요한 존재일 수 있는가

리더십은 엉망진창입니다. 자아, 자존심, 마감일, 그리고 압박이 있습니다.

터프한 매니저는 그 소음을 뚫고 나아갑니다. 그들은:

• 기능뿐만 아니라 확장성에 대해 생각하도록 강요합니다.
• 영리한 코드뿐만 아니라 유지 보수가 가능한 코드를 작성하도록 밀어붙입니다.
• 엣지 케이스와 실패는 일어날 것이기 때문에 그것들을 계획하도록 가르칩니다.

이러한 매니저들은 당신이 어떻게 느끼는지보다는 당신의 코드가 프로덕션 환경에서 살아남을 수 있을지에 더 관심을 가집니다. 그리고 그것은 나쁜 것이 아닙니다.

터프한 매니저 밑에서 살아남고 번성하는 방법

만약 당신이 현재 목덜미에 숨결을 불어넣는 것처럼 느껴지는 매니저 밑에 있다면, 이것이 효과를 발휘하게 만드는 방법입니다.

• 개인적으로 받아들이지 마세요. 피드백이 코드에 대한 것이라면, 그것은 당신에 대한 것이 아닙니다.
• 모든 피드백 후에 "왜"를 물어보세요. 대부분의 터프한 매니저는 호기심을 존중합니다.
• 그들이 지적하기 전에 실패 지점을 예측하세요. 그들이 하는 것처럼 생각하기 시작하세요.

만약 당신이 엔지니어를 관리하고 있다면:

• 기준을 높게 설정하되, 무엇이 걸려 있는지 설명하세요. 엔지니어는 높은 기준이 왜 중요한지 알 때 그것을 존중합니다.
• 피드백을 구체적으로 하세요. 모호한 비판은 사람들을 좌절시킵니다. 요점을 말하세요.
• 성공뿐만 아니라 성장을 축하하세요. 누군가가 당신보다 먼저 문제를 발견하는 첫 번째 순간은요? 그것을 칭찬하세요.

내가 거절당해서 기쁜 풀 리퀘스트

그 잔혹했던 풀 리퀘스트를 돌이켜보면, 그것은 엔지니어로서 저에게 일어난 최고의 일 중 하나였다고 말할 수 있습니다.

그것은 제가 코딩을 개인적인 예술 프로젝트로 취급하는 것을 멈추고 시스템 구축자처럼 생각하기 시작하도록 강요했습니다. 엔지니어처럼요.

터프한 매니저는 당신을 기분 좋게 만들지는 않을 것입니다. 하지만 그들은 당신을 더 나은 존재로 만들 것입니다. 그리고 당신이 당신의 자아를 넘어서면, 그들이 당신에게 남기는 교훈은 당신의 경력 전체에 걸쳐 지속될 것입니다.

때때로, 최고의 PR은 거절당하는 PR입니다. 왜냐하면 그곳이 진정한 성장이 일어나는 곳이기 때문입니다.

 

https://news.hada.io/topic?id=20051