엔지니어들이 매니저에게 분노를 느끼게 되는 흔한 관리 안티패턴과, 신뢰와 존중을 얻는 좋은 매니저들의 행동을 정리한다.
대부분의 엔지니어는 매니저와 복잡한 관계를 맺고 있다. 그리고 “복잡하다”는 말은, 가벼운 짜증부터 들끓는 원망 사이 어딘가를 뜻한다. 이 양쪽을 모두 경험해 본 입장에서 — 엔지니어로 10년 넘게 일하다가 관리로 전향했기 때문에 — 나는 이 긴장을 거의 모든 각도에서 겪어 왔다.
여기 불편한 진실이 있다: 엔지니어는 매니저에게 좌절할 만한 그럴듯한 이유가 있는 경우가 많다. 하지만 왜 이런 일이 벌어지는지 이해하는 것이, 이를 고치는(혹은 그냥 견디는?) 첫 단계다.
엔지니어들이 책상을 뒤엎고 싶게 만드는 가장 흔한 관리 안티패턴을 하나씩 짚어 보겠다 — 그리고 끝까지 읽어라. 엔지니어의 존중을 실제로 얻어 내는 최고의 매니저들이 무엇을 다르게 하는지도 함께 공유하겠다.
당신이 엔지니어라면 “드디어 누가 내 마음을 알아주네.” 하며 고개를 끄덕일 가능성이 크다. 당신이 매니저라면, 음… 여기서 자기 모습을 발견할지도 모른다. 괜찮다 — 자각이 첫 단계다.
당신은 몰입 상태의 한가운데 있다. 몇 주 동안 프로덕션을 괴롭혀 온 복잡한 버그를 마침내 이해해 가고 있다. 헤드폰을 끼고, 세상은 사라졌고, 당신은 거의—
“잠깐 싱크할 수 있어?”
매니저가 나타난다. 우선순위를 논의하는 데 “딱 5분만” 필요하다고 한다. 그 5분은 30분이 되고, 책상으로 돌아왔을 때 당신이 구축해 둔 그 아름다운 정신적 모델은? 사라져 있다. 어디까지 했는지 떠올리는 데만 또 한 시간이 필요하다.
나쁜 매니저는 프로그래밍에는 깊은 집중이 필요하다는 것을 이해하지 못한다. 엔지니어를, 원하면 언제든 멈췄다가 다시 시작할 수 있는 공장 노동자처럼 다룬다. 코딩하기 좋은 시간대에 회의를 잡아 놓고, 왜 속도가 떨어졌는지 의아해한다.
엔지니어를 미치게 만드는 또 하나: 코드를 한 번도 써 본 적 없는 매니저가 기술적 결정을 내리는 것이다. 마치 운전을 한 번도 해 본 적 없는 사람이 좌석 색깔만 보고 당신이 어떤 차를 사야 하는지 결정하는 것과 같다.
나는 기술적으로 불가능한 기능을 약속하는 매니저, 팀과 상의도 없이 마감일을 확정하는 매니저, 그리고 최악으로 — 실제로는 매우 어려운 변경을 “간단한” 수정이라고 말하는 매니저를 봐 왔다. 엔지니어가 반대하면 “팀플레이어가 아니다”라는 낙인이 찍힌다.
비극은, 이런 매니저들 중 일부는 원래 엔지니어였다는 점이다. 하지만 코드를 떠난 지 너무 오래되어, 실제로 어떤 느낌인지 잊어버렸다. 그들은 장밋빛 안경을 낀 채 코딩을 기억한다. 모든 것이 실제보다 더 단순하고 더 빠르던 시절로.
엔지니어의 동기를 더 빨리 꺾는 것은 없다. 매니저가 자기 공로로 당신의 일을 가져가는 모습을 보는 것만큼은. 당신은 밤과 주말을 바쳐 그 불가능한 마감일을 맞추고, 복잡한 문제에 우아한 해법을 만들었다. 그런데 전사 미팅에서 매니저는 그것을 “이번 분기에 내가 납품한 것”으로 발표한다.
좋은 엔지니어는 문제를 해결한다. 나쁜 매니저는 자기가 해결했다고 주장한다. 그리고 이것이 항상 악의적이진 않다 — 때로는 매니저가 “팀을 가능하게 했다”는 것이 곧 본인이 일을 했다는 뜻이라고 진심으로 믿는다. 하지만 실제로 코드를 쓴 엔지니어에게 그 말을 해 보라.
엔지니어들은 농담으로 말하지만, 고통스러울 정도로 현실적이다. 이메일로 보냈으면 될 일을 회의로 잡는 매니저. 그러고는 “가시성을 위해” 팀 전체를 초대한다. 그리고 “정렬 상태를 유지하자”며 정기 회의로 만든다.
캘린더는 생산성의 묘지가 된다. 45분이나 걸리는 스탠드업. 다른 회의를 계획하기 위한 계획 회의. 아무것도 바뀌지 않는 회고.
엔지니어는 부분적으로는 무언가를 만드는 것을 사랑해서 이 직업을 선택한다. 불필요한 회의 하나하나는, 그들이 진짜 하고 싶은 일에서 시간을 훔쳐 간다.
연간 평가는 신뢰가 죽는 곳이다. 일 년 내내 회의에서만 간신히 보이던 매니저가 갑자기 당신의 “성장 영역”에 대한 의견을 갖는다. 너무 오래 걸렸던 PR 하나를 꺼내 든다(맥락은 무시한 채). 혹은 “더 눈에 띄어야 한다”고 말한다(눈에 띄는 일을 할 시간은 주지 않으면서).
피드백은 일반론뿐이고, HR 템플릿에서 복붙한 것이 분명하다. 혼자 힘으로 장애 세 건을 막았는데도 “기대치 충족”. 약속했던 승진은? “다음 사이클에나.” 연봉 인상은? “예산 제약.”
그 사이, 경험은 절반이지만 정치력은 두 배인 신입이 방금 Senior로 승진했다.
여기서 일이 복잡해진다. 나 역시 관리로 전향한 뒤, 나를 불편하게 만든 사실을 발견했다. 내가 예전에 불평하던 그 행동들을 (일부) 나도 하고 있었던 것이다.
관리는 외롭다. 불완전한 정보로 끊임없이 결정을 내려야 하고, 서로 충돌하는 우선순위를 저울질해야 하며, 그렇다 — 엔지니어들이 싫어하는 그 영혼을 갉아먹는 회의들에 똑같이 앉아 있어야 하는 직업이다.
대부분의 매니저가 사악한 건 아니다. 오히려 엔지니어만큼이나 좌절해 있는 경우가 많다. 요구가 많은 임원진과 번아웃된 팀 사이에 끼어 있기 때문이다. 직접 통제할 수 없는 지표로 평가받고, 더 적은 것으로 더 많은 것을 하라는 요구를 받으며, 사방에서 비판을 받는다.
엔지니어를 미치게 만드는 그 매니저들? 보통 그들도 허덕이고 있다. 그들은 계속 방해를 받기 때문에 방해한다. 어떤 결정이라도 내리라는 압박 때문에 나쁜 기술 결정을 내린다. 기업 게임에서 살아남는 방식으로 학습했기 때문에 공로를 가져간다.
이해한다고 해서 나쁜 관리를 정당화하진 못한다. 하지만 관점을 준다. 그리고 더 중요하게는, 좋은 관리가 실제로 어떤 모습인지로 우리를 이끈다.
내가 아는 최고의 엔지니어링 매니저들 — 엔지니어들이 실제로 좋아하는 사람들 — 은 몇 가지를 깨달았다:
진실은 이렇다. 엔지니어가 매니저를 싫어하는 게 아니라, 나쁜 관리를 싫어하는 것이다. 그리고 양쪽을 모두 겪어 본 사람으로서 말하자면, 엔지니어에서 매니저로의 전환은 대부분의 사람들이 생각하는 것보다 훨씬 어렵다. 본질적으로 완전히 새로운 일을 배우는 것인데, 주변은 곧바로 완벽하길 기대한다.
하지만 그렇다고 변명이 되진 않는다. 매니저로서 이 글을 읽고 “저거 내 얘긴데” 싶은 대목이 있다면, 이제 솔직한 성찰이 필요하다. 엔지니어로서 매니저에게 좌절하고 있다면, 그들도 익사 직전일 수 있다는 점을 고려해 보라 — 때로는 당신이 할 수 있는 최선이, 둘 다 성공하기 위해 무엇이 필요한지에 대해 솔직한 대화를 나누는 것이다.
내가 본 최고의 팀은 엔지니어와 매니저가 친구인 팀이 아니다(물론 그렇게 되면 좋을 때도 있다). 최고의 팀은 양쪽이 각자의 역할을 이해하고, 서로의 어려움을 존중하며, 공동의 목표를 향해 함께 일하는 팀이다.
그런 일이 일어날 때 — 엔지니어는 자신의 목소리가 들린다고 느끼고 매니저는 지지받는다고 느낄 때, 기술적 현실이 비즈니스 필요와 만나는 동시에 어느 한쪽도 짓누르지 않을 때 — 그때 팀은 믿기 어려운 것들을 출하한다. 해야 해서가 아니라, 하고 싶어서 한다.
