등장인물 :
A : program manager (보통 맘좋고 느긋한 백인여자던가 성격 더러운 동양여자)
B : 다른팀 project manager
C : manager1 (백인이 아무래도 많겠죠?)
D : 다른팀 manager2
E : engineer1(백인)
F : engineer2(얍살한 인도)
G : engineer3(일잘하는 한국인)
H : test engineer(열심히 시키는 대루 한다 꾀는 안부린다)

email이 날라옵니다…

From : A
To : B
Cc : C D E F G
======================
클낫다 핫이슈다.. 뭐가 고장낫데..이거 coustomer한테 임팩 클거다…(정작 일이 얼마나 큰건지 중요한지 아닌지 뭔지 개념 무다)

From : B
To : A
Cc : C D E F G
======================
알았다.. 뭔가 개념없는 어려운 약자 써가며 잘해보자 으쌰으쌔 ..메니져야  엔지니어 누구 없냐?  우리한번 회의를 제대로 함 해보자! 이거 critical show-stopper  blocker 핫 슈퍼 이슈다… (이게 일이에여?  물론 PM들 메니져들 힘들다는거 알고 있습ㄴ다만,,, 쩝 이건 좀)

From : C 
To : E F G
Cc : A B D
======================
아무개야  이거 can you take a look at 어쩌구 이슈? (달랑 한줄 ,,, 그리구 먼 이슌지 관심 무..)
 
From : E 
To : C F G
Cc : A B D
======================
(나 백인이다) (나 굉장히 잘하는 엔지니어지만) 지금 막 집에 갈려구 그랬다.. 낼 보도록 하겠다..

From : F 
To : C E G
Cc : A B D
======================
먼가 어렵게 길게 쓴다…이론하구 졸라 멋있는 영어 쓰구 혼자 북치구 장구치구 다한다…so what?

From : G 
To : C E F
Cc : A B D
======================
바로 일얘기부터 한다..변명이구 머구 다 싹 빼구 핵심만 쓴다

그러니깐  문제가 머구  register 값을 3을 넣구 어쩌구저쩌구 넣었더니 고쳐졋다..unit test 까지 다 내가 verify했다…테스트 엔지니어야 다시 한번 확인해줄래?
(그러니깐  내가 다 재현해보고 다 분석하고 고치구 보드 tweak하고 코드 고치고 컴파일해보고 빌드하고 test까지 다해봣다  엄청 쪼는 관계로 열심히 밤새서 다 해서 …….나 혼자 일한다……..크리티컬이라 해놓고  아무도 관심없다 …)

Best Regards,

아무개

From : H
To : C E G F
Cc : A B D
======================
내가 확인했다  잘된다..

연봉은 G엔지니어가 가장 작다…  정말 눈물나게 UNFAIR한 세상이다….

ABCDEF는 정말  저럭식의 핑퐁 이멜은 안썼으면 좋겠다……..행정적인 일
로 메일쓰다가  G엔지니어의 메일 하나가 섞여있다…..regiseter ;이런 메일 

여러분은 누구한테 돈 젤 마니 줘야 한다구 생각합니까? 물론 테스터들  메니져들  스트레스 많이 받는다 들었다………근데…이건 쫌       아니다 싶은데…  우리회사만 그러냐?

> 여러분은 누구한테 돈 젤 마니 줘야 한다구 생각합니까?

–> D

딱 추이를 보고 있으면서 문제를 해결하는 프로. 함부로 안뛰어들고, 자신 편하고 자기 팀원 리소스 아끼고, 막아주고. 훌륭한 매니저로서의 필수 자질임

정답 : A

다들 아전인수격으로 생각들 하죠….

엔지니어는 자기가 하는일이 가장 critical 하다고 생각하고, 또 테스터는 테스터 나름대로 자기 하는일이 중요하다고 생각하고…. 매니저들도 마찬가지이죠.

허나 닭이 먼저냐 계란이 먼저냐의 문제를 한번 생각해 보시면….. 일단 위쪽의 시니어 매니저들이 커스토머하고 relationship을 잘 쌓아서 프로젝트 수주를 따오지 못하면 아예 프로젝트 자체가 존재를 안하고, 밑의 엔지니어는 할일도 없어서 아예 이런 밤샘작업할 기회조차 만들어지지도 않죠.

넓게 보면 이것은 엔지니어 쪽에만 국한된 것이 아니고, 다른 인더스트리에도 적용이 됩니다. 예를 들어 금융계 Investment Banking이나 법률 로펌등에서도 날밤 새면서 일하는 사람들은 밑의 말단 직원들이고, 위의 시니어 매니저들은 주로 커스토머 relationship 쌓고 하는일들을 하죠.

위의 댓글처럼 A가 돈을 젤 많이 받겠죠. 근데 H는 이멜 한번도 안받았는데 마지막에 이슈가 뭔지도 모르면서 확인했고 잘된다고 하나요? 원래도 테스트 안하고 무조건 된다고 하는건가. ㅡ_ㅡ

From : H
To : C E G F
Cc : A B D
======================
내가 확인했다 잘된다..

ㅋㅋㅋ 맞네요…

위의 댓글분 아주 예리하게 잘 보시네요.

H는 결국 한번도 이메일을 못받았네요….. 혹시 ‘BCC’ 로 몰래 받은것은 아닌지요????

저도 하나 찾았는데, 글쓰신 분 제목에는 “unfair unfair” 하면서 “일 잘하는 한국인 (engineer3)”인 척 하시면서 실제로는 “얍살한 인도인 (engineer2)”이셨네요. 정말 얍살하시네요. ㅎㅎㅎ.

여기까지는 농담이었고, 여기서부터도 의견이니까 너무 진지하게 듣지 마세요.

제 생각에도 위 상황만으로는 G가 appeal할 것이 그다지 없을 것 같습니다. (그냥 직책대로 높은 사람이 많이 받아야지요.) 문제가 발생했으면 관련 멤버들이 회의해서 어떠한 해결책들이 있는지 리스트 만들고 각 해결책의 장단점 분석/비교해서 회사에 제일 유리한 대로 우선 순위 정하고, 장기 단기 대책 세워서 내부에서 할지 외부에서 할지 정해서 수행해야 하는데 G는 그냥 이런 순서 다 무시하고 혼자 정해서 했버렸으니까요. Manager쪽에서 봤을 때는 각 순서의 evidence 없이 그냥 해 버리면 회사에 싸이는 것도 없고, 제안책의 정당성을 다시 확인해 봐야 하니까 일을 거꾸로 한다는 생각도 들 겁니다.

E, F가 아무 것도 안하는 것처럼 보여도 다 이러한 순서가 있으니까 내일 나와서 보자고 했을 수 있습니다.

그렇지만 정말 좋은 해결책이었다면 보너스나 연봉 협의할 때 한 마디 올릴 수는 있을 것 같습니다. 그렇지만 기본은 다 같이 협의한 후에 해결하는 것을 추천하고 싶네요. G의 기술력은 다른 사람들도 충분히 인정하고 있을 테니 이제부터는 G도 다른 사람들하고 협의할 줄 안다는 것을 appeal해야 하지 않을까 싶네요. (맘 안 맞는 사람들하고 일하면 쌓이니까 혼자 하고 싶은 것이 솔직한 심정이겠지만 적어도 회사에서 평가받는 방법은 아닙니다. 좀 시간 걸리더라도 같이 하든지 동의는 받고 혼자 하세요.)

가만이 있으려다가…

일단 G –

1. 전체 이멜로 이런쪽에 문제가 있을것 같다라던지 모 그런 이야기좀 쓰고 본인이 해결하겠다고 쓴담에…

2. 대략 밤늦게 혹은 새벽쯤에 해서 또 이멜쓰면서 이러저래 고쳤다 정도? 테스터 확인해보고 오케이면 낼 아침에 Production으로 옮기겠다..하고 자는거죠.

그리고 일이라는건 정해진 시간내에하라고 있는것이니만큼.. 그렇게 overtime을 해야되는 경우라면 당당히 이야기하세요.. 나…너가 시킨 1,2,3일하고 지금 발생한 4하고 같이 못하는데.. 4부터 먼저하면 1,2,3 Delay생길것 같다고.. 그리고 나서 매니저한테 시간 확보 받아놓고 일해도 되구요..

글구 매니저 입장에서 볼때.. 정작 발생한 4의 문제라는게…팀의 실제 일이 아닐수도 있고, 별로 빛나지 않는 일일수도 있거든요. 그런거에 엄청 시간투자해서 달성해봐야 별로 팀에 빛이 안되는 일이라면 매니저가 그 일을 완성한 님에게 그만큼 많은 Credit을 주는것도 알 수 없구요.

님이 생각하실땐 문제해결자체가 중요한것 같지만..어떻게 그걸 해결했는가도 상당히 중요합니다. 그리고..어떻게 진행해 나가실지 모르겠지만.. 아예 분야를 정하세요…어느쪽을 담당하시려는지..본인이 E / F와 틀린게.. 빠른 응답인지..특정 모듈인지 특정 분야인지..그래서 추후에는 그냥 G한테 이멜이갈 수 있도록..

재미난 주제네요. 저의 회사의 경우를 예로 들어봅니다. 대부분의 회사들이 어떤 형태로든 Bug Tracking System을 활용하리라 생각되는데, 제가 다니는 회사는 이렇게 합니다.

1. Technical Support 에서 고객의 문제점이 들어오면, Bug Tracking System 에 케이스를 만들고, 이 일 해결에 가장 적합하다 생각되는 팀의 매니저 앞으로 Assign.

2. 매니저는 일의 중요도나 우선순위를 참작해서 짧은 코멘트와 함께 이 일을 가장 적합하다 싶은 싶은 엔지니어에게 Assign.

3. Assign 받은 엔지니어는 현재하고 있는 일, 현재 자기 앞에 쌓여 있는 일등을 고려하여 나름대로 일의 우선순위를 정하고, 그냥 일정에 맞게 진행함. (절대로 새로 주어진 일 때문에 늦게까지 일하거나 , 밤새거나 하지 않음.)

만일 일의 중요도가 높으면 매니져와 어떤일을 먼저 했으면 좋겠냐 상의한 후 진행. (매니저는 항상 누가 지금 무슨 일을 하고 있는지 파악.)

4. 원인이 밝혀지면, 해결책을 제시한다든지 Patch를 만들어 QA 한테 Assign.
(경우에 따라 Technical Support에 Assign 하기도 함.)

5. QA는 테스트하고 나서 이상이 없으면 케이스를 종료.

6. Technical Support 는 고객에게 해결책을 제시하고, 문제해결. 그래도 문제 해결이 되지 않으면 Case를 Reopen 하고 엔지니어에게 Reassign.

이렇게 케이스를 다른 사람에게 Assign 할 때, 관련된 사람에게 CC 해서 지금 일이 어떻게 진행되고 있는지 알도록 합니다.

Salary는 별개의 문제라 생각됩니다. 직급에 따라 주는 것이지요. 문제를 많이 해결했다면 연봉협상을 통해 직급이나 연봉을 올려야 하고, 만일 이 회사에서 자신의 실력을 잘 인정해 주지 않는다면 더 좋은 회사로 옯기는 수 밖에요.

한국이랑 많이 다른 것 같아요. 한국에서 일할 때는, 위에서는 아래 직원들이 야근이나 밤새서라도 문제를 빨리 해결해 주었으면 바라고, 아래에서도 당연히 그렇게 생각하고…

이러한 생각의 차이가 엔지니어의 지위를 차이나게 만드는 것 같아요.

>여러분은 누구한테 돈 젤 마니 줘야 한다구 생각합니까?
>물론 테스터들 메니져들 스트레스 많이 받는다 들었다………
>근데…이건 쫌 아니다 싶은데… 우리회사만 그러냐?

완전히 role이 다른 사람들을 놓고 누구에게 돈을 많이 줘야 하냐고 물으면 곤란하죠. 저 위에 나온 것이 그들이 하는 모든 일도 아닌데 말이죠. 엔지니어들 E, F, G 중에도 role이 다르다면 쉽게 말할 수가 없습니다. 만약에 E가 리드인데, 그 역할을 못하면 일 잘하는 G보다 월급을 적게 받는게 아니라 짤리거나, G가 그 위치로 가고 그에 맞는 봉급을 받게 되는 것이죠.

지금 대우가 unfair하다고 생각되면 그 출중한 능력으로 advance하도록 하시던가, 그게 여의치 않다면 회사를 바꾸는겁니다.

다들 메니져나 높은 지위에 계신거 같으네요… 그리구 심사숙고 후에 일 시키는 훌륭한 메니져…

글쓰니는 말이 그렇다는 얘기죠… 그러구 혼자 해결하고 혼자 일하는게 아니구 그냥 다 대락 중략… 열심히 전화 돌리구 가끔 메니져한테 전화도 돌리고 메일도 뿌리고 그거 다 중략이져…

좋은대학나오고 머리가 좋기 때문에 해결사가 없다는 얘기죠… 그리구 메니져나 누구든 참 관심이 있게 좀 했으면 좋은데 관심이 없다는…

일의 과정 결과 원인분석 다 적습니다..다 적는데 아무 누구도 관심이 없다는 얘기죠…. 그냥 돼 안돼! 이게 중요합니다..

그리구 초를 다투는 일들 하시는 분들 많은걸루 알고 있습니다… 문제 생김 바로 반나절내지 하루만에 해결 봐야 합니다… 블라커 크리티컬 이란 이슈는 그렇답니다…

매니저A가 한국엔지니어G와 같은 경력을 차근히 쌓아오면서 매니저가 되었다면,
누가 일을 가장 많이 하고 해결사 노릇을 하는지 잘 알것이며
엔지니어 G가 Unfair라는 불평불만을 가지기도 전에 잘 매니지를 해올것이지만

백이나 낙하산으로 들어온 사람이라면, 그룹 조직내 많은 트러블을 만들어내는 장본인이 될것입니다. 이것은 매니저 A가 설사 프로젝트르를 많이 수주해오는 영업전문 매니저라도 마찬가지 입니다. 일만 잘 수주해왔는데, 그 일들이 어떻게 처리되어야 양질을 납품 프로젝트로 출하되는 것인지, 도무지 알길이 없다면, 결국 엔지니어 G나 얍삽한 인도 엔지니어같은 이들이 결국 조직내에서 제2의 권력자로 부상할 가능성이 높습니다.

결국 권력투쟁(월급, 보너스, 입김등등)으로 그 조직은 보스가 일을 많이 따오는 그룹임에도 불구하고 깨지기가 쉽습니다.

가장 이상적인 연봉금액은, 일거리를 가장 많이 따오는 사람하고, 그 일거리를 양질을 납품으로 제대로 일처리 마무리를 해내는 엔지니어가 공히 비슷하게 많이 받아야 할것이며, 매니저 A같은이가 매니저 되기전에 일도 잘했던 사람이고, 현재 일거리 수주도 잘하는 매니저라면, 당근 매니저A가 최고의 연봉을 받아야 겠지요.

단, 실제상황은 대다수 정치력이 뛰어난 자들이 가장 높은 연봉을 받고 있습니다. 그리고, 그 정치력은 영업력과 기술력에 별로 비례하지 않다는 것이고요…. 이러한 현실이기에 직장내에는 항상 갈등과 투쟁이 존재하지요….

결론은, 기술력이 좋으신 분덜은 정치력을 길러야 하고, 정치력이 좋으신 분들은 기본 기술력을 습득하시면 그 정치력에 날개를 달개 된다는 아주 진부한 이야기입니다.

미국직장 한국인분들중에, 영어의 장벽으로 정치력 부재를 합리화 시키시는데,,,
막말로 이런분들 한국직장 다니신다고 해도, 별로 주목받지 못하는 정치력 약하신 분들 대다수라는 개인적 경험 입니다.

우리모두 힘냅시다.

간만에 재미있는 원글이었습니다.

사실 정치력이라는게 알고보면 다 아부 같은 건데..
어차피 같은 인종이 아니라면 사실 페널티 먹고 가는게 사실입니다.

제 경험에 비추어 말씀드리자면.

원글에서 G는 그런식으로 일을 처리하면 안되는 겁니다.
즉, 막판까지 아무도 해결못하고 다들 전전긍긍할때 그때 해결책과 프로그램을 번쩍이는
속도로 제시해야만 모든 매니저들에게 인식을 주게 되는 겁니다.

물론 자주 그러면 동료 E,F의 견제를 받게 되므로 자주하면 역효과가 납니다.

따라서 아주 결정적인 것을 쿼터당 1번정도 또는 반년에 한번정도 해결해주면 좋은 처세라고
생각합니다.

아이디어 또는 제안역시 마찬가지 입니다. 가지고 있다가 결정적일때 한번 제출하는 겁니다.

기술자의 정치력은 이런식으로 키우는 것이 더 나은게 아닐까 하는 제 짧은 생각이었습니다.

원글님이 일 혼자 다하신다잖아요,,, 왜 이렇게 까칠한지.

누군가는 반드시 해야 하지만 메니져는 관심없다고 하잖아요…

>한국이랑 많이 다른 것 같아요. 한국에서 일할 때는, 위에서는 아래 직원들이 야근이나 밤새서라도 문제를 빨리 해결해 주었으면 바라고, 아래에서도 당연히 그렇게 생각하고…

이런 아래 생각이 직원들이 이공계 기피를 하게되고 밤새고 회식 한번 시켜주면 좋아라 하게 만드는거 같아여… 왜 엔지니어는 노조를 만들수 없게 법으로 해놨는지 모르겠습니다