brunch

You can make anything
by writing

C.S.Lewis

by Sweet n Sour Mar 18. 2019

[Sweet N Sour]
매니저란?

뭐하는 사람인데?

나의 브런치 글들에서는 매니저 / 디렉터 / co-worker / 인턴 네 가지의 직책들이 등장할 것이다. 그중 단연 많이 등장하게 될 인물들이 바로 매니저들인데, 이야기를 하기 전에 매니저에 대해서 잠시 알아보고, 또 한 가지 일화를 share 하고 싶다.




매니저는 직급이 아닌 보직

한국에서 회사 생활을 많이 해보지 않아서 terminology에 대한 확신은 없지만 "매니저는 직급이 아닌 직책"이다. (물론 이건 어디까지나 내가 겪은 회사들에 한해서이다)


내가 여기서 말하는 '직급'이란, 예를 들어 Software Engineer I 으로 취직해서, 승진해서 Software Engineer II 가 되고, 그다음 III이 되고 IV가 되는, 직원들의 레벨을 매기는 시스템이다. 물론 숫자는 회사마다 다르고 정식 명칭도 조금씩 다르지만.


Manager라는 직책 (또는 보직)은 예를 들어 "나 레벨 4였는데 승진해서 매니저가 됐어"라고 할 수 있는 건 원래는 아니다. 내가 다녔던 Snap Inc라는 회사의 경우 Engineer 4 이상이면 매니저가 될 수 있는 자격이 있다. 따라서 내 매니저는 레벨 5이고 옆 팀 매니저는 레벨4 이고 그런 일도 비일비재하게 생길 수 있는 것이다. 그리고 내가 레벨4의 개발자였는데 승진 없이도 매니저가 될수도 있다.


그렇기 때문에 매니저는 하고 싶지 않고 엔지니어만 하고 싶은 사람들은 계속해서 엔지니어로서 레벨을 올려가면서 Staff Engineer라던지, Principal Engineer라던지가 되게 된다.


그렇다면, 한국의 불특정 대기업들처럼 매니저나 디렉터가 꼭 자기 팀의 엔지니어들보다 직급이 높은 건 아니라는 뜻인데, 매니저가 하는 일은 뭘까? - 자기 팀원들을 부려먹고 이거 해라 저거 해라 명령을 꼭 할 수 있는 직급체계가 아니라는 것이니까 -


나한테 시켜

물론 지금까지 함께 일한 사람들을 등수로 매길 수는 없지만, Snap에서 나와 함께 일했던 매니저는 내가 가장 좋아했던 매니저 중 한 명이다. 편의상 A라고 부르겠다. 내가 Tech Lead / manager role로 커리어를 쌓고 싶다고 했더니 A는 나에게 그런 기회가 있으면 조금씩 조금씩 배워보자 라고 했고 나는 2명 또는 3명의 팀을 리드하게 되는 기회가 조금씩 생기기 시작했다.


뭔가 그전에 내가 느꼈던 매니저라는 직책은 결정권자 이자, 조언자 이자, 스케쥴링도 해줘야 하고, 데드라인도 정하는 뭔가 authoritative 한 직책이어야 한다는 생각이 있었다. 물론 내 매니저가 그런 authoritative 한 사람이 아니었음에도 불구하고, 뭔가 어릴 때부터 한국 TV에서 보는 상사의 개념 때문인지 나도 어느샌가 내 팀원들의 모든 technical한 결정과 조언 등등을 해주려고 하고 있었다.


그러던 어느 날에 A가 나를 불렀고 이렇게 말했다.

A: 너랑 네 팀이 지금 하고 있는 두 개의 프로젝트 X와 Y가 있는데, 너는 X의 코드 implementation에 대해서 하루에 얼마나 많이 시간을 써서 생각해?

나: 글쎄.. 음 타임라인이나 전체적인 방향, 그리고 다른 팀들하고 협업 coordination 이런 것도 해야 하고 Y도 있으니까 한 30퍼센트 정도?

A: 그럼 너희 팀에 있는 X 담당 개발자는 하루에 얼마나 많이 생각할까?
나: 하루 종일 하겠지

A: 그럼 네가 알고 있는 지식으로 혼자 결정하는 것보다는 그 개발자의 의견을 거의 수렴한다는 마음으로 decision making을 해야 하지 않을까?

나: 그렇겠네


그러고 나서 A는 나에게 자기가 생각할 때 매니저란 직업은 자기 팀원들을 외부 팀으로부터 보호하고, 코딩을 하는데에 불편한 점이 없는지 확인하고, 자기 팀원들이 그들의 역량을 최대한으로 발휘할 수 있게 옆에서 보조를 하는 사람이라고 생각한다고 말해줬다. A도 개발자 생활을 오래 했었기 때문에 개발적인 부분에서 조언하는 건 자연스럽게 나오는데 팀원들 뒤치다꺼리하는 건 항상 자기 자신도 remind 한다고 했다.


그러면서 내가 A의 팀에 처음 들어갔을 때 했던 말을 다시 해줬다.


"꼭 너가 지금 하고 있는 일에 대한 것이 아니여도 힘든 점이나 불편한 점 같은게 있으면 나한테 말해도 되"


A가 팀을 운영하는 방식은 큰 micro-managing은 없었다. 그 팀에서 우리들은 개발자로서 각자 자기 일을 찾아서 하는 방식이였고 그에는 좋은점도 있었지만 나쁜점도 있었다. 팀원들이 각자 일을 찾아서 할동안 매니저는 팀 외적으로 우리팀의 visibility를 올린다거나 다른팀과의 정치 싸움에서 승리한다거나 다른팀이 우리팀 credit을 가져가려 하는걸 지켜준다거나 하는걸 참 잘해줬던것 같다.



매니저야, 저팀에 쟤가 나 필요한거 안 줘

시간이 지나면서 그 이후에 또 몇몇의 팀을 경험했고 그러면서 내가 매니저라는 직책에 느끼는 나만의 해석은, 우리 팀의 엄마 같은 존재인 것 같다. 다른 팀과 협업하는데 자꾸 답장 안 하고 비협조적이면 매니저한테 이르고, 내가 회사에서 너무 불편한 게 있어도 매니저한테 이르고, 나의 커리어적인 성장에 대해서도 매니저와 이야기하고, 내 performance review도 매니저와 함께하고.


지금 현재 우리팀 매니저가 치열한 discussion이 오가는 미팅이 끝날 때 쯔음 애들이 뭔가 결정해줘라는 눈빛으로 자기를 쳐다보면 하는 말이 있다.


"You guys are the engineers, this is an engineering decision. I'm just a manager. I'm no longer an engineer"

("너희가 엔지니어야. 지금 우리가 대화하는 문제는 엔지니어링 결정이고. 나는 매니저야 이제 나 개발자 아니야")


좋은 매니저는 꼭 강한 결정권자는 아니다.

브런치는 최신 브라우저에 최적화 되어있습니다. IE chrome safari