Jade the Zapper

관리자 엔지니어 전환

작가님의 허락을 받고 번역한 글입니다.(원문)

최근 트위터에서 몇 사람들에게 경력 상담을 하고 있습니다. 많은 사람들의 주된 고민은 아래와 같습니다.:

”저는 시니어 엔지니어입니다. 하지만 매니저가 되는 것을 생각하고 있습니다. 엔지니어링을 정말 좋아하지만, 매번 동일한 문제를 반복해서 푸는 것 같고, 진짜 문제는 인간문제인 것처럼 보입니다. 승진하기 위해 매니저가 되어야만 합니다. 제가 매니저로 전환했을 때 끔찍하지 않았으면 합니다. 굉장히 심각하다고 들었습니다.”

저는 이 글을 오래 전부터 쓰려고 했습니다. 상당히 내용이 많지만, 이 글귀와 함께 시작해봅시다. 매니저만 경력 발전이 있다는 아이디어는 개나 줘버리십시오. 그리고 "라인"을 잘 선택해서 그곳에서 오래 성장한다는 아이디어도 쓰잘데기 없습니다. 저는 이런 종류의 커리어를 거부합니다.

”당신의 조언은 최악이며, 당신은 그것을 느껴야만 합니다.”

공학의 최전선에서 최고의 활약을 펼치고 있는 전세계 공학 매니저들은 직접적인 풀타임 업무에서 멀어진지 2,3년이 채 되지 않은 사람들입니다. 그리고 최고의 개별 기여자는 관리직을 맡아본 사람들입니다.

전세계 최고의 테크리드들은 진자가 앞뒤로 움직이는 것처럼 종종 관리와 개발을 둘다 합니다.

저는 이제 이런 관리-개발 전환을 몇번이나 했습니다. 초기 인프라 엔지니어링으로 고용되어서 인프라를 구축하고, 팀을 만들고 팀을 관리하고, 떠나서 처음부터 다시 시작했습니다. 짜증이나고, 지쳤습니다. 그리고 나서야 제가 뭐하고 있는지 알기 시작한것 같습니다. (…. 감출 수 없는 신호는 무엇인가 잘못된 것입니다).

초기 회사를 좋아하거나 주의력 결핍 장애가 있는 경우, 이는 좋은 사이클이 될 수 있습니다. 하지만 커리어로써 이에 대해 이야기 하는 사람들을 보지는 못했던 것 같습니다. 따라서 제가 의도적이며 좋은 삶의 방향이 될 수 있는 새로운 커리어에 대해 이야기해보고자 합니다.

두 가지 모두를 잘 할 수 있는 사람들은 많이 있습니다. 다만 분명한 것은 그들을 동시에 하지는 않습니다.

— Sarah Mei (@sarahmei)

@sarahmei는 제가 이 글을 작성하고 있는 바로 동일한 시간에 이 트윗을 남겼습니다.

(기술 프로젝트에서) 매니저가 되는 것

관리자를 승진시키는 것은 날을 방금 만드는 사람에게 날 세우는 방법을 알려주는 것을 의미합니다. 이는 그들에게 신뢰성을 부여하는 동시에 다른 역할로써 익숙하지 않은 것을 성취해야 하는 상황을 부여합니다.

이것이 관리자+기술팀장의 하이브리드 형태의 임시적 영광을 성취할 수 있는 유일한 방법입니다. 이는 안정적인 조합은 아닙니다. 왜냐하면 여러분의 엔지니어링 기술과 감은 길게 하면 할 수록 더 무뎌져가기 때문입니다.

여러분은 엔지니어링과 관리 중에서 오직 한번에 하나만 성장시킬 수 있습니다. 하지만 여러분의 관리자라면, 여러분의 일은 관리를 더 잘하는 것입니다. 이전 영광에 매달리려고 하지 마십시오.

관리는 굉장히 이것저것 신경을 많이 써야하며, 외부 방해를 막는 것이 필요한 엄청난 공학입니다. 여러분은 이 두가지를 동시에 할 수 없습니다. 관리자로서, 항상 접근 가능하고, 팀원들로 부터 방해받아야하는 것이 여러분의 직업입니다. 또 여러분의 직업은 어떤 도전적인 과제에서 손을 뗄지 선택하는 것입니다. 이를 통해 여러분의 팀이 더 나은 엔지니어링을 할수 있도록 해야합니다.

5. 코드와 사람이 성장하는데 필요한 것은 집중적이며 지속적인 관심으로 동일합니다. 누구도 두가지를 모두 잘 할 수는 없습니다.

— Sarah Mei (@sarahmei) May 11, 2017

(사람들의) 기술팀장이 되는 것

대조적으로: 전세계 최고의 기술팀장들은 항상 관리자 경험이 있는 사람들입니다. 이는 그들이 매번 굉장한 프로그래머이거나 디버거여서 그런것이 아닙니다. 그들이 최고인 이유는 일을 끝내는 방법을 알고 있기 때문입니다. 이는 그들이 다른 사람들을 관리할줄 알고 소통하느 방법을 잘알기 때문입니다.

기술 팀장은 관리자가 되는 것입니다.….하지만 그들의 첫번째 우선순위는 손에 쥐어진 일을 성취하는 것이지, 일하는 사람들을 관리하는 것이 아닙니다.

기술팀장은 완전한 관리자 도구가 필요합니다. 또한 어떻게 사람이나 팀을 결집시키는지, 그들을 동기부여하는지, 모두가 망했다고 생각하여 멈춘 프로젝트를 다시 일으키는 방법이나, 어떻게 우선순위를 정해야하는지 알 필요가 있습니다. 기술 팀장은 사업의 목표와 기술적 목표 두 점을 연결하는 것이 필요합니다. 그리고 큰 목표를 작은 단위로 쪼갤 줄 알아야 합니다. 기술팀장은 주니어 개발자의 능력을 성장시키며, 의미있는 결과물을 만들어내고, 경계를 무너뜨리지 않는 선에서 지속적인 자극을 줘야 할 필요가 있습니다. 그러고나서 다른 팀원들에게도 동일한 것을 하시면 됩니다. 이는 관리 업무입니다. 무엇인가를 마치는 것을 살짝 변형한 것이지, 사람들을 다루는 법이 아닙니다.

따라서 기술 팀장은 보통 무엇인가를 만드는 것보다는 회의에 더 많은 시간을 보냅니다. 그리고 싫어하면서도 결국 할 것입니다. 왜냐하면 프로그래밍은 그들의 시간을 사용하는 최고의 방식이 아니기 때문입니다. 기술은 쉬운 부분이고 사람들을 이끄는 것이 더 어려운 부분입니다.

양쪽의 도구들을 모두 가지고 있는 시니어 개발자들은 조직이나 회사를 구축할 수 있는 기술팀장의 일종입니다. 이들은 뭔가르 만들어 낼 수 있으며 귀합니다.

이들 중 대부분은 관리에 수많은 시간을 사용한 사람들입니다.

진자 운동

주기적으로 변하는 엔지니어들의 엄청나게 큰 폭과 힘 에 대해 충분히 이야기 하지 않았습니다.

IC(idividual contributor)가 되는 것은 회사가 일하는 것을 약간 역공학 하는 것과 같습니다!

제일 끝단에서 보면 대부분의 것들은 이상하게보이거나 목적이 없어보이고, 비효율적인 것처럼 보일수 있습니다.

관리자가 되는 것은 사업이 일하는 방식을 가르쳐줍니다. 또한 사람들이 어떻게 일을 하는지 알려줄 것입니다. 불편한 대화를 하는 것을 배우게 될 것입니다. 짜증나있거나 불평이 많은 사람들, 여러분을 싫어하는 사람들과 좋은 일을 계속 하는 방법을 배우게 될것입니다. 충돌을 어떻게 해결해야하는지 배우게 되며, 실제로 여러분은 충돌을 희망하는 방법을 배우게 될 것입니다. 왜냐하면 직접적인 충돌을 보통 더 가장 나은 선택사항이기 때문입니다. 여러분은 매일 지쳐서 집에 가고 여러분이 무엇을 한 것인지 명확히 할수 없을 것입니다. 하지만 여러분은 뭔가를 했습니다.

뭔가를 수정하거나 고쳤을 때의 도파민을 몹시 그리워하게 될 것입니다.

관리에 대해서 마지막으로 하나가 있습니다. 사람들이 너무 힘들어서 관리직을 그만두게 만드는 미신입니다. 심지어 이 미신이 생기기 시작하면, 그 주위에 있는 모든 사람들이 비참해집니다. 이 미신은 관리직은 승진이라는 생각입니다.

관리직은 승진이 아닙니다.

1. 관리자가 되는 것은 승진이 아닙니다. - 말 그대로 동일선상에서 자리를 옮기는 것 뿐입니다. 많은 기술에 있어서 다시 주니어 레벨로 이동한 것입니다.

— Sarah Mei (@sarahmei) May 11, 2017

이 미신은 관리직이 싫고 전혀 관심이 없는데도 불구하고 많은 사람들을 관리직으로 이끌며, 또한 우리가 필요한 원로 및 좋은 멘토들의 시니어 개발자가 되기를 갈망합니다.

** 관리는 승진이 아닙니다. 전문분야의 변화일 뿐입니다.** 직종 전환 이후 꽤 오랜 기간 동안 여러분의 성과는 좋지 않을 것입니다. 여러분이 저성과가 아니라고 생각한다면, 여러분은 일을 하지 않은 것입니다.

여러분의 엔지니어가 정말로 코드를 작성하는 누군가에게 비참하고 화나는 피드백을 받을 수 있다면, 여러분의 자존심을 채우기 위해 관리하는 것은 훌륭한 방법입니다.

누군가를 관리직으로 강제로 옮기라는 지시 만큼 나쁜 것은 없습니다. 제발 사람들이 기술에 번아웃을 느끼는 이유 중 하나가 되지 마십시오.

관리직은 승진이 아닙니다. 따라서 포기해야하는 상황이 아닙니다. 관리직이 여러분을 행복하게 하고 여러분 주위 사람들을 행복하게 만드는 만큼 일을 하십시오. 그리고 다시 돌아가서 무엇인가를 만드십시오. 다시 힘들어질때까지 기다리세요.

그리고 나서 전부 다시 시작하세요. <3

이 글을 공유하기:

• 트위터
• 페이스북

엔지니어링 관리자를 하고 배운 것 44가지

작가님의 허락을 받고 번역한 글입니다.(원문)

엔지니어링 관리에 오신 것을 환영합니다. 지치지만, 재미있고, 보람된 일입니다. 하지만 무엇보다 새롭다는게 가장 중요합니다. 이전에 했던 일은 이제 하지 않을 것입니다. 새로운 능력을 함양해야 하고 과정 중에 나쁜 습관은 버려야 합니다. 이 글이 시작하는데 짧은 가이드가 되어 줄 것입니다.

해야하는 것

1. 인재를 유치, 육성, 코칭 및 보유해야 합니다. 엔지니어와 상의하여 문제를 조기에 파악한 후 가능하면 해결해야 합니다.
2. 모든 엔지니어에게 작업해야 할 가장 중요한 문제를 전달 해야 합니다.
3. 팀이 합의하지 못할 때 최종 결정을 해야 합니다.
4. 정보의 허브가 되어야 합니다. 모든 엔지니어가 어떤 작업을 하고 있는지 파악하고, 끊어진 점을 연결하는데 도움을 줘야 합니다.
5. 관리 지원을 제공 해야 합니다. 문제 해결을 스케줄 상에 넣고, 출시 일을 재 조정하며, 제대로 동작하는지 확실히 점검해야 합니다.
6. 행위 및 성능 표준을 시행 해야 합니다. 이로서 불량배들과 저 성과자들을 관리해야 합니다.

해선 안되는 것

7. 개인적으로 문제를 해결하거나 기능을 출시하면 안됩니다. 효과적인 최종 결정권자로서 코드를 짜야 합니다. 하지만 개발 책무는 여기서 멈춰야 합니다.
8. 사람의 업무에 대한 질과 양을 관리해야 합니다. 소프트웨어 엔지니어링은 부품 조립이 아닙니다. 너무 자주 관리, 감독 하게 되면, 좋은 사람을 잃거나 적절한 인센티브를 주지 않은 것입니다.

동기부여와 문화

9. 당신은 고용, 해고의 결정권을 가지고 있습니다. 여러분 팀에서 발생하는 모든 것은 여러분의 책임입니다.
10. 엔지니어링은 판매자의 시장입니다.: 사람들은 여러분을 믿기 때문에 여러분을 위해 일을 합니다. 그들의 능력을 접하는 것은 특권입니다.
11. 권위는 자유롭게 부여되는 것이 아닙니다. 시간이 지남에 따라 좋았던 의사 결정이 쌓이면서 비로소 얻게 되는 것입니다.
12. 꼭 해야 하는 게 아니면 결정을 내리면 안됩니다. 가능할 때마다, 팀이 아이디어를 탐색하고 그들 자신만의 결정을 내릴 수 있도록 허락해야 합니다.
13. 필요할 때 결정을 해야 합니다. 몇몇 요소는 멈춘 팀처럼 굉장히 사기를 꺾게 합니다.
14. 필요할 때까지 아이디어를 철저히 논파하면 안됩니다. 모든 사람이 그들의 아이디어를 공유하고 탐색하는데 안전함을 느낄 수 있는 환경을 만들어야 합니다. 코드를 작성하는 사람은 여러분이 가지고 있지 않은 엄청난 정보를 가지고 있습니다. 팀에 의지해야 더 나은 결정을 내릴 수 있을 것 입니다.
15. 좋은 의사 결정을 하는 직감을 기르고 팀과의 좋은 관계를 만드는 것은 목표의 95% 도달하게 만들 것입니다. 개념적 프레임워크 의 과함은 엔지니어링 팀을 조직함에 있어, 큰 차이를 만들지 못할 것입니다. 좋은 매니저와 나쁜 매니저는 종이 하나 차이 입니다.

감정과 사람

16. 관리는 우리 문화에서 명성있는 것처럼 보입니다. 하지만 다른 것들과 마찬가지로 단지 기술일 뿐입니다. 명성은 혼란입니다. - 변하기 쉬우며, 무작위적입니다. 당신이 누구보다도 낫다고 생각하지 않도록 조심해야 합니다. 빨리 위신을 회복할수록 일을 잘 하는 데 더 빨리 집중할 수 있습니다.
17. 관리직은 조롱의 대상이 될 수 있습니다. 무시해야합니다. - 매니저는 쓸모없다고 믿는 사람들은 성공적인 조직을 쌓는 것에 대한 역학을 이해하지 못하는 것입니다.
18. 뭔가 잘못된 것을 느꼈다면, 아마도 맞을 것입니다. 누군가 괴롭히면서 여러분의 감정을 무시하게 하면 안됩니다.
19. 만약 자신이 누군가를 비난하고 있는 것을 발견한다면, 아마도 여러분이 잘못된 것입니다. 나쁜 일을 하기 위해 노력하고 일어나는 사람은 아무도 없습니다. 95%의 경우, 사람들과 이야기함으로써 감정을 해소할 수 있습니다.
20. 대부분의 사람들은 쉽게 감정을 공유하지 않습니다. 잦은 정보성 대화를 갖고, 잘못되었을 수 있는 모든 것을 찾아내야합니다. 그리고 가능하다면 고쳐야 합니다.
21. 여러분의 팀은 여러분에게 리더십을 기대합니다. 모두가 진실이라고 알고 있지만 말하지 않는 것을 말할 수 있는 용기를 가져야 합니다.
22. 여러분은 팀에서 발견하지 못한 문화적 문제를 찾고 이를 수정하기 위해 돈을 받는 것입니다. 모든 사람이 알아야 하지만 그렇지 않는 것을 말할 용기를 가지셔야 합니다.
23. 좋은 사람을 고용해야 합니다. 그리고 완전히 신뢰해야 합니다. 한 달 혹은 분기 간격으로 성과 평가를 하고 해야만 할 때 해고해야 합니다. 사람들을 매일 평가하면 안됩니다. 이는 모든 사람을 미치게 만들 것입니다.
24. 대부분의 지적 논쟁들은 강한 감정적 흐름이 있습니다. 그것들이 무엇인지 배우게 된다면, 극적으로 효과적인 업무를 할 수 있게 될 것입니다.

최종 결정과 갈등

25. 지나치게 빨리 판단하면 안됩니다; 생각하는 것보다 여러분이 맞는 경우는 흔치 않습니다. 여러분이 맞다고 확신을 하더라도, 모든 사람의 의견을 듣기 전까지는 기다리십시오.
26. 모든 사람의 말을 다 들었다면, 모든 의견의 중점 사항을 요약해서 사람들이 "고마워요, 저도 그렇게 생각했으면 좋았을 텐데요"라고 말하도록 해야한다. 각 관점에서 일치되는 중점 사항을 나열하고 모든 사람으로부터 여러분이 배운 것을 말해야합니다. 그리고 나서 여러분의 결정을 내리십시오.
27. 결정을 내렸다면, 밀어붙이셔야 합니다. 팀이 강한 목소리를 달래기 위해 빙빙 돌며 시간을 낭비하게 해서는 안됩니다.
28. 의미 있는 정보가 새로 들어왔다면, 회의를 다시 시작해야합니다.
29. 의견 충돌이 개인적으로 변하거나 사람들이 합리적인 결정을 받아들이지 못할 때, 이는 갈등으로 변합니다.
30. 대부분의 갈등은 상대방이 자신의 말을 들으려고 하지 않을 때 발생합니다. 앉아서 각 사람에게 어떻게 느끼는지 물어보십시오. 잘 듣고 계속해서 물어보십시오. 그리고 나서 요약해서 그들에게 들었던 내용을 알려주십시오. 대부분의 경우 문제가 해결될 것입니다.
31. 갈등이 충분히 모든 사람의 말을 듣고 고쳐진 이후에도 지속된다면, 어려운 말을 할 때가 된 것입니다.

어려운 말

32. 어려운 말은 가능한한 빨리 하는게 좋습니다. 기다림은 안 좋은 상황을 더 좋지 않게 만들 뿐입니다.
33. 절대 가정하거나 결론으로 건너 뛰지 말아야 합니다. 절대 여러분 마음 속에 사람을 악마처럼 만들면 안됩니다. 절대 비난하고 소리지르거나 헐뜯으면 안됩니다.
34. 비폭력 의사소통)을 해야합니다. 제가 아는 한 사람들의 행동을 불쾌하게 하지 않고 비판할 수 있는 가장 좋은 방법입니다. 경영계의 유행 같은 냄새가 나지만, 정말 효과가 있습니다.
35. 여러분이 어떻게 느끼는지 그리고 무엇이 필요한지 말할 수 있는 용기를 가져야 합니다. 서로의 단점에 빠진 사람들은 자기 자신을 싫어하게 됩니다. 취약점은 약점이 아닙니다.
36. 사람들이 당신에게 같은 예의를 베풀기를 기대해야 합니다. 만약 누군가 여러분이 필요한 것과 감정을 드러내는 것에 나쁜 감정을 느끼게 한다면, 그것은 여러분 자신에 대해보다 그들에 대해 더 많이 알려줍니다.

매운 맛

37. 사람들은 여러분의 한계에 밀어붙이거나 재촉할 것입니다. 언제 물러 서야하고, 단호해져야하는지 아는 것은 전쟁의 절반입니다.
38. 때때로 누군가 너무 지나치게 밀어붙일 수 있습니다. 그들이 그렇게 한다면, 매운 맛을 보여줘야하거나 여러분의 팀에게 권위를 잃게 될 것입니다.
39. 단호한 "난 그게 좋지 않아보입니다"면 보통 충분합니다.
40. 웃어 넘기고 싶지 않다면, 웃어 넘기면 안됩니다. 여러분의 진실된 감정을 보여주기 위해 용기를 가지십시오.
41. 만약 여러분이 강하게 "난 그게 좋지 않아보입니다"를 같은 사람에게 여러번 말해야하는 상황이 온다면, 여러분의 직업은 그들을 해고하는 것입니다.
42. 여러분이 소시오패스가 아닌이상, 사람들을 해고하는 것은 정말 힘들어서 해고하지 않을 핑계를 찾게 될 것입니다. 만약 여러분이 지속적으로 누군가 적합한지 지나치게 오래 고민하게 된다면, 여러분이 아는 것을 실행할 용기를 가지는 것이 맞습니다.
43. 사람들이 여러분에게 여러분이 믿지도 않는 결정을 하도록 강요하지 않게 해야합니다. 그들은 나중에 그들이 맞았다며 _여러분_에게 책임을 물을 것입니다. 결정은 여러분의 책임입니다.
44. 여러분 자신을 믿어야 합니다. 말을 탄 모습이 우스꽝스럽다고 생각되면 기병대를 지휘할 수 없습니다.

이 포스팅을 리뷰해주신 Michael Glukhovsky, Michael Lucy, 그리고 Alex Taussig에게 감사를 표합니다.

• spakhm
• Subscribe via RSS

프로그래머들이 프로그래밍을 못하는 이유

작가님의 허락을 받고 번역한 글입니다.(원문)

Reginald Braithwaite의 글을 읽었을 때 믿을 수 없었습니다.

이 작가는 저와 같이, 200명 중 199명의 개발자 지원자들이 코딩을 전혀 못한다는 사실에 문제를 겪고 있었습니다. 다시 한번 말합니다.: 그들은 어떤 코드든지 작성할 수 없습니다.

이 작가가 언급하고 있는 사람은 간단한 프로그램 조차 작성할 수 없는 수 많은 프로그래머들을 돌려보낸 Imran입니다.:

몇 번의 시행 착오 이후에, 코드를 작성하려고 노력하는 사람들은 큰 문제에는 시도하지 않는 것을 발견했습니다. 심지어 링크드리스트의 구현하라는 작은 문제에서도 노력조차 하지 않았습니다. 그들은 아주 작은 문제인 경우에만 노력합니다.

그래서 저는 이런 종류의 개발자를 확인할 수 있는 개발 질문을 준비하고, FizzBuzz 질문이라고 불리는 질문들을 생각해봤습니다. Fizz-Buzz 질문은 다음과 같습니다.:

1부터 100까지 출력하는 프로그램을 작성합니다. 하지만 3의 배수의 경우 숫자 대신 "Fizz" 문자열을 출력하고, 5의 배수의 경우 Buzz를 출력합니다. 3과 5의 공배수의 경우 FizzBuzz를 출력합니다.

대부분의 좋은 프로그래머들은 몇분이면 해당 프로그램을 종이에 작성할 수 있습니다. 무서운 사실을 알려드리자면, 대부분의 comp sci 졸업생들은 할 수 없습니다. 자칭 시니어 프로그램조차도 10-15분 정도 걸리기도 했습니다.

Dan Kegel도 엔트리 레벨 프로그래머들을 고용하는데 비슷한 경험을 했다고 합니다.:

지원자들의 대다수는 컴퓨터공학에서 석사 혹은 박사 학위를 소유하고 있었습니다. 하지만 놀랍게도 기본적인 프로그래밍 작업을 요청하는 인터뷰에서 실패했습니다. 예를 들면, 1부터 10까지 출력하는 루프를 작성하라고 했는데 작성을 못한다거나, 16진수에서 f 다음에 오는 숫자는 무엇이냐고 물었을 때 답하지 못한 지원자도 있었습니다. 또 회귀를 활용하여 실제 문제를 풀지 못하는 지원자들도 적지 않았습니다. 이것들은 기본적인 능력입니다. 이런 것들에 부족하다면 프로그래밍 능력이 충분히 준비되지 않은 것입니다.

예비 신입사원 면접을 봐야 하는 소프트웨어 엔지니어들을 대표해서 말하는자면, 배운 것 이외의 것들은 프로그래밍할 수 없는 지원자들과 대화하는 데 지쳤다고 해도 과언이 아닙니다. 1에서 10까지 출력하는 루프를 모든 언어로 작성할 수 있고, 계산기 없이 간단한 산수를 할 수 있고, 문제를 푸는데 회귀를 사용할 수 있다면, 이미 그들보다 앞서고 있는 것입니다.

Reginald, Dan, and Imran 사이에서 걱정이 되기 시작했습니다. 저는 소프트웨어 개발자들이 일을 처음 시작할 때 쉽게 풀어주지 않을 것 입니다. 누구든지 시작은 합니다. 그러나 소위 프로그래머라 불리는 사람이 가장 간단한 프로그램도 작성하지 못한 채 입사 지원을 한다는 것은 불안하고 섬뜩합니다.

프로그래밍할 수 있는 사람과 그렇지 않은 사람 사이의 큰 차이는 잘 알려져있습니다. 저의 경우, 누구나 프로그래머로 지원하는 사람들은 이미 이 기준을 넘었다고 가정합니다. 명백히 이것은 해서는 안되는 비 합리적인 가정이 아닙니다. 명백히, FizzBuzz 스타일의 스크리닝은 면접관들이 프로그램을 할 수 없는 지원자들을 평가하는데 사용하는 불필요한 시간 낭비를 방지하는데 필요합니다

FizzBuzz 테스트가 의도적으로 너무나 맹목적으로 쉽다고 생각하지 않도록, Imran의 글에 댓글을 작성한 사람이 있었습니다.:

저는 면접관들이 "FizzBuzz" 시험을 너무 쉽다고 무시하는 것을 싫어합니다. 제 경험상 굉장히 많은 지원자들이 가장 간단한 프로그래밍 작업을 할 능력이 없었는데 이는 정말 놀라울 정도 입니다.

아마도 프로그래머 인터뷰를 시작할 때 그들의 코드를 먼저 보지 않는다면 가장 멍청한 것일 겁니다. Vertigo에서는 폰 인터뷰 단계를 시행하기 전에 코드 샘플을 요구합니다. 그리고 대면 면접때는 작은 코딩 문제를 포함합니다. 어려운 건 아니고, 한 시간 정도 안에 동작하는 작은 애플리케이션을 만드는 기본적인 연습입니다. 비록 한 두번의 실패는 있었지만, 대부분의 경우 이 전략은 성공적이었습니다. 이것은 지루한 퍼즐 문제에 의지하지 않고실제 소프트웨어 엔지니어링에 집중하게 해줍니다.

실제로 _프로그램_할 수 있는 프로그래머들을 인터뷰하는 호화로운 시간을 가지려면 그렇게 많은 사전 심사를 해야 한다는 것은 부끄러운 일입니다. 저는 자격증의 팬은 아닙니다, 그러나 Steve McConnell이 진정한 소프트웨어 엔지니어링 전문직 창출에 대해 이야기한 것과 오해하지는 않으셨으면 합니다.

관리자의 책임과 권리 명세서

작가님의 허락을 받고 번역한 글입니다.(원문)

1년 반 전쯤, 저는 Honeycomb의 엔지니어로 인해 권한과 책임이라는 포스팅을 작성했습니다.
당시 저희는 급성장 중이었고, 몇 명의 엔지니어를 새로 고용하여, 일상적인 엔지니어링 관리를 Emily에게 넘기는 과정에 있었습니다. 이 때, 관리자의 권한과 책임에 대한 글을 쓰는 것은 실제로 제가 무엇에 신경 써야 하는지 알게 해주었습니다. 또한 조직의 성장에 있어 우리의 원칙을 지킬 수 있도록 도와주었습니다.

포스트의 끝에 고정시킨 것은 매니저 책임에 관한 목록이었습니다. 거의 대다수는 글을 작성한 후에 따로 생각난 것을 덧붙인 것입니다. 이로 인해 많은 사람들로부터 매니저들은 책임만 있고 권한은 없냐는 항의를 받곤 했습니다.

항상 나중에 매니저의 책임과 권한에 대한 후속 포스팅을 작성하려고 했습니다. 하지만 최근까지 작성할 수 없었습니다. 저희가 또 다른 사람들을 고용하는데 힘을 쓰고 있고, 관리 수준을 확장 중에 있었기 때문입니다. 그리고 드디어 지금 글을 작성할 시기가 왔습니다.

"때가 왔다. 때가 되었다." marvin k mooney가 말했습니다. 권한 명세서를 더하고, 책임 리스트를 확장 수정하였습니다. 저와 함께 글을 작성해준, Emily Nakashima에게 감사드립니다.

매니저의 권한 목록

1. 매니저는 동료나 리더의 보고서에 있는 자기 자신, 자신의 팀에 대한 피드백을 정직하고, 용기있게 받을 수 있어야 한다.
2. 관리는 개개인의 업무와 같이 동일한 존경과, 중요성을 존중받는다.
3. 매니저는 고용, 해고, 팀 준 평가에 대해 최종 결정권이 있다. 동료나 팀으로부터 피드백을 요청하고, 가능한 선에서 합의를 하도록 유도해야 한다. 하지만 최종 결정은 매니저의 몫입니다.
4. 관리는 잘할 수 있을 것 같은 장소에서조차도 어려운 작업이며, 소모적이다. 다른 매니저 동료로부터 전략적, 감정적 지원을 받을 수 있다.
5. 매니저가 자기 자신을 관리할 수 없다면 다른 사람들을 관리할 수 없다. 차라리 휴가를 가는게 나을 것이다.
6. 개인 개발, 경력 개발, 전문 지원에 대한 권한이 있다.
7. 원하지 않다면, 꼭 매니저가 되지 않아도 된다. 누구도 전혀 강요하지 않는다.

매니저의 책임 목록

• 팀을 모집하고, 고용하며, 훈련시켜야 한다. 연대감, 팀 그리고 실제 감정적으로 안전한 분위기를 조성해야 한다.

• 포용적인 문화를 만들고, 기회를 재분배해야한다. 인맥은 개나 줘라.

• 팀원을 관리해야한다. 커리어 계획, 개인적 목표, 워라밸, 팀내외 갈등에 대해 지원할 필요가 있다.

• 팀원에게 필요한 지원을 하지 않는 누군가를 지속적으로 지켜봐야한다. 그리고 동료 매니저와 함께 상황을 고치려고 노력해야한다.

  

• 피드백을 일찍 그리고 자주 해야한다. 또한 피드백을 감사히 받아야 한다. 항상 어려운 것을 말하면서 그들에게 사랑을 담아 말해야한다.

• 혼란에 빠지거나 목표 달성에 기여하지 않는 것에 경계해야한다. 가차 없이 앞으로 전진하면서, 치명적인 부분에 대한 중복성, 범위를 확실히 짚고 넘어가야한다.

• 팀에 대한 자체적인 계획을 소유해야한다. 팀의 직접적인 관리자가 설정한 측정 가능한 목표를 정하고, 의사소통 우선순위를 고려 함으로써 자원을 할당해야한다. 집중해야 하는 일이나, 긴급한 일이 필요한 곳을 꼭 고려해야 한다.

• 매니저만의 시간을 가져야한다. 다른 사람들이 당신에게 편하게 접근할 수 있도록 하고, 자신의 달력을 적극적으로 관리해야한다. 감정을 조절하여, 다른 모든 사람들의 문제로 만들면 안된다. (이 경우, 선배 혹은 동료의 지원에 기대는 편이 좋다.)

• 자신의 개인 성장과 자기 개발 우선순위를 만들어야 한다. 직원들이 본받고자 하는 가치와 특성을 모델링해야한다.

• 약점을 인정해야한다.

(말했던 것보다 쉽지 않습니까?)

메이커의 일정 그리고 매니저의 일정

작가님의 허락을 받고 번역한 글입니다.(원문)

"... 가끔은 약속을 의식하는 것 만으로도 하루 종일 걱정될 때가 있다." by Charles Dickens

프로그래머들이 회의를 싫어하는 이유 중 하나는 그들은 다른 사람들과 다른 종류의 스케줄을 소화하기 때문입니다. 회의는 그 이상의 비용이 듭니다.

스케줄에는 두 종류가 있습니다. 하나는 매니저의 스케줄이고, 하나는 메이커의 스케줄입니다. 매니저의 스케줄은 보스들을 위한 것입니다. 이것은 하루를 한 시간 간격으로 쪼개 놓은 구체적인 전통적인 스케줄입니다. 필요하다면, 하나의 일을 처리하기 위해 몇 시간을 한꺼번에 지정할 수 있습니다. 하지만 기본적으로 매 시간 할 일이 바뀝니다.

시간을 이런 방식으로 사용하게 되면, 누군가를 만나는 것은 문제가 아닙니다. 스케줄에서 빈 시간을 찾아 기록하면 끝입니다.

대부분의 강력한 사람들은 매니저의 스케줄을 따르고 있습니다. 이런 상황은 스케줄이 명령을 내린다고도 볼 수 있습니다. 하지만 작가나 프로그래머와 같이 무엇인가를 만드는 사람들 사이에서 공통적인 시간 사용 방법이 있습니다. 이들이 선호하는 방식은 보통 하루의 절반을 기준으로 삼는 것입니다. 프로그램이나 글쓰기는 한 시간 단위로는 잘 될 수 없습니다. 한 시간은 작업에 필요한 세팅 정도만 겨우 할 수 있는 정도입니다.

메이커의 스케줄로 활동할 때, 회의는 재앙입니다. 하나의 회의는 전체 오후를 날려버릴 수 있습니다. 이렇게 되면 그렇지 않아도 어려운 일을 하루의 절반만 사용해서 처리하게 되는 것입니다. 게다가 회의 참석 약속을 기억 해야 합니다. 매니저 스케줄을 따르는 사람에게는 큰 문제가 아닙니다. 항상 무엇인가 다음 시간에 할 게 있기 때문에 무엇을 할 것 인지만 기억하면 됩니다. 하지만 메이커 스케줄을 따르는 사람들은 그렇지 않기 때문에 계속해서 그 회의에 대해 생각하고 기억하고 있어야 합니다.

메이커 스케줄을 따르는 누군가에게는 회의를 갖는 것이 예외를 던지는 것과 같습니다. 이 것은 일을 마치고 다른 일로 전환하는 것을 어렵게 합니다. 즉, 일하는 방식을 바꾸는 것입니다.

어떤 회의는 하루 전체에 영향을 주는 경우도 있습니다. 회의는 보통 하루의 절반을 날리게 됩니다. 게다가 종종 캐스케이드 효과(갑자기 일이 몰아치는 것)를 불러일으키는 경우도 있습니다. 만약 제가 오후가 날라갈 것을 알게 된다면, 아침에는 야심 찬 무언가를 시작하는데 고민이 될 것입니다. 이게 굉장히 억지라고 생각할 수 있다는 거 압니다. 하지만 여러분이 메이커가 된다면, 생각이 바뀌실 겁니다. 하루 종일 약속도 없이 자유롭게 일할 수 있다는 생각에 기분 좋지 않습니까? 이 말은 여러분의 영혼은 메이커의 스케줄을 따르지 않으면 우울해진다는 뜻입니다. 그리고 야심찬 프로젝트는 말 그대로 능력 한계에 도달하게 될 것입니다. 사기가 조금만 감소되더라도 능력을 모두 죽일 수 있습니다.

각 스케줄 타입은 그 자체만으로 잘 동작합니다. 문제는 그 두가지가 서로 충돌할 때입니다. 대부분의 높은 사람들은 매니저의 스케줄에 따르고, 모든 사람들이 자신과 서로 합을 맞춰야하는 위치에 있습니다.하지만 만약 높은 사람들이 자신들을 위해 일해주는 사람들이 일하는데 긴 시간이 필요하다는 것을 알았다면, 똑똑한 사람들은 이것들을 억제할 것 입니다.

우리의 케이스는 일반적이지 않습니다. 거의 대다수의 투자자들, VC들은 매니저 스케줄을 따릅니다. 하지만 Y Combinator는 메이커 스케줄에 따릅니다.

만약 우리 회사와 같아지기 시작하는 회사가 있다면 놀랍지 않을 것입니다. 저는 설립자들은 매니저가 되는 것에 더욱 더 저항하거나 최소한 연기할지도 모른다고 생각합니다.

어떻게 해야 많은 스타트업들이 메이커의 스케줄에 따르라고 조언할 수 있겠습니까? 메이커들이 일할 때 매니저 스케줄을 사용해보는 작은 모의 실험을 사용함으로써 가능합니다. 일주일에 몇 번 정도는 투자한 회사의 설립자들을 만나기 위해 따로 시간을 남겨둡니다. 이런 시간 덩어리는 일하는 날의 마지막 쯤에 있습니다. 그리고 근무 시간에 주어진 모든 약속들을 마지막에 위치하도록 했습니다. 왜냐하면 이런 회의가 하루 중 마지막에 오는 것은 전혀 제 일을 중단시키지 않기 때문입니다. 퇴근 시간이 동일하지 않다면 그들을 방해할 수 있지만 그들이 약속했기 때문에 그들에게는 충분히 가치있을 것입니다. 바쁜 시기에는 근무 시간이 종종 길어지기도 하지만 절대 방해하지 않습니다.

스타트업에서 일할 때, 저는 하루를 나누는 방법을 발전시켰습니다. 저는 저녁에서 새벽 3시까지 매일 프로그램을 작성하곤 했습니다. 밤에는 방해받지 않을 수 있었기 때문입니다. 그리고 나서 11시까지 잠을 잤습니다. 그리고는 저녁까지 비즈니스 관련된 일을 했습니다. 저는 이런 형태의 스케줄을 무엇이라고 부를지 적절한 용어를 생각할 수 없었습니다. 하지만 하루에 2 영업일을 가질 수 있었습니다. 즉, 매니저의 스케줄에 있으면서 메이커의 스케줄을 따랐습니다.

매니저의 스케줄을 따를 때, 여러분은 메이커의 스케줄을 따르는 것처럼 활동할 수 없습니다. 단지 회의만 참여할 수 있을 뿐입니다. 만약 스케줄에 빈 슬롯이 있다면, 여러분은 사람을 만날 수 있습니다. 스케줄에 빈 슬롯이 있으면 안될 거 뭐가 있겠습니까? 어떤 방법으로 누군가를 도와줄 수 있다는 것이 밝혀질 것입니다.

실리콘밸리 경영인들은 곰곰히 생각하는 회의를 항상 합니다. 그들은 매니저 스케줄에 있다고 하더라도 효과적으로 자유롭습니다. 그들은 너무 흔해서, 그들에게 제안하는 명확한 언어가 있습니다. 예를 들면 "커피 마실래요?"

매니저 스케줄을 따른다 하더라도, 깊은 생각은 요하는 회의들은 굉장히 비용이 큽니다. 이런 회의는 우리를 묶이게 만드는 것들입니다. 많은 사람들은 우리가 매니저 스케줄을 따른다고 생각합니다. 그래서 그들은 우리를 만나야만 하는 사람 혹은 커피 마시자는 이메일을 보내야하는 사람으로 소개하곤 합니다. 이 점에서 우리는 두 가지를 선택할 수 있습니다. 그들을 만나, 하루의 절반을 버리거나, 그들을 만나지 않고, 불쾌하게 구는 것입니다.

최근까지 이런 문제에 대해서 명확히 하지 못했습니다. 우리는 우리의 일정을 망치거나 사람들을 불쾌하게 해야 하는 것을 당연하게 여겼을 뿐입니다. 하지만 지금은 무엇을 해야하는지 깨달았습니다. 아마도 세번째 옵션인, 두 형태의 스케줄을 설명하는 것입니다. 결과적으로 매니저 스케줄과 메이커 스케줄 사이의 충돌이 더 널리 이해되기 시작하면 큰 문제가 되지는 않을 것입니다.

메이커 스케줄에 따르는 우리들은 기꺼이 협의할 것입니다. 우리는 몇번의 회의는 해야만 하는 것을 알고 있습니다. 매니저 스케줄에서 우리가 요청하는 모든 것은 비용입니다.

Sam Altman, Trevor Blackwell, Paul Buchheit, Jessica Livingston, 그리고 초안을 읽어준 Robert Morris에게 감사 를 표합니다.