작가님의 허락을 받고 번역한 글입니다.(원문)
엔지니어링 관리에 오신 것을 환영합니다. 지치지만, 재미있고, 보람된 일입니다. 하지만 무엇보다 새롭다는게 가장 중요합니다. 이전에 했던 일은 이제 하지 않을 것입니다. 새로운 능력을 함양해야 하고 과정 중에 나쁜 습관은 버려야 합니다. 이 글이 시작하는데 짧은 가이드가 되어 줄 것입니다.
해야하는 것
- 인재를 유치, 육성, 코칭 및 보유해야 합니다. 엔지니어와 상의하여 문제를 조기에 파악한 후 가능하면 해결해야 합니다.
- 모든 엔지니어에게 작업해야 할 가장 중요한 문제를 전달 해야 합니다.
- 팀이 합의하지 못할 때 최종 결정을 해야 합니다.
- 정보의 허브가 되어야 합니다. 모든 엔지니어가 어떤 작업을 하고 있는지 파악하고, 끊어진 점을 연결하는데 도움을 줘야 합니다.
- 관리 지원을 제공 해야 합니다. 문제 해결을 스케줄 상에 넣고, 출시 일을 재 조정하며, 제대로 동작하는지 확실히 점검해야 합니다.
- 행위 및 성능 표준을 시행 해야 합니다. 이로서 불량배들과 저 성과자들을 관리해야 합니다.
해선 안되는 것
- 개인적으로 문제를 해결하거나 기능을 출시하면 안됩니다. 효과적인 최종 결정권자로서 코드를 짜야 합니다. 하지만 개발 책무는 여기서 멈춰야 합니다.
- 사람의 업무에 대한 질과 양을 관리해야 합니다. 소프트웨어 엔지니어링은 부품 조립이 아닙니다. 너무 자주 관리, 감독 하게 되면, 좋은 사람을 잃거나 적절한 인센티브를 주지 않은 것입니다.
동기부여와 문화
- 당신은 고용, 해고의 결정권을 가지고 있습니다. 여러분 팀에서 발생하는 모든 것은 여러분의 책임입니다.
- 엔지니어링은 판매자의 시장입니다.: 사람들은 여러분을 믿기 때문에 여러분을 위해 일을 합니다. 그들의 능력을 접하는 것은 특권입니다.
- 권위는 자유롭게 부여되는 것이 아닙니다. 시간이 지남에 따라 좋았던 의사 결정이 쌓이면서 비로소 얻게 되는 것입니다.
- 꼭 해야 하는 게 아니면 결정을 내리면 안됩니다. 가능할 때마다, 팀이 아이디어를 탐색하고 그들 자신만의 결정을 내릴 수 있도록 허락해야 합니다.
- 필요할 때 결정을 해야 합니다. 몇몇 요소는 멈춘 팀처럼 굉장히 사기를 꺾게 합니다.
- 필요할 때까지 아이디어를 철저히 논파하면 안됩니다. 모든 사람이 그들의 아이디어를 공유하고 탐색하는데 안전함을 느낄 수 있는 환경을 만들어야 합니다. 코드를 작성하는 사람은 여러분이 가지고 있지 않은 엄청난 정보를 가지고 있습니다. 팀에 의지해야 더 나은 결정을 내릴 수 있을 것 입니다.
- 좋은 의사 결정을 하는 직감을 기르고 팀과의 좋은 관계를 만드는 것은 목표의 95% 도달하게 만들 것입니다. 개념적 프레임워크 의 과함은 엔지니어링 팀을 조직함에 있어, 큰 차이를 만들지 못할 것입니다. 좋은 매니저와 나쁜 매니저는 종이 하나 차이 입니다.
감정과 사람
- 관리는 우리 문화에서 명성있는 것처럼 보입니다. 하지만 다른 것들과 마찬가지로 단지 기술일 뿐입니다. 명성은 혼란입니다. - 변하기 쉬우며, 무작위적입니다. 당신이 누구보다도 낫다고 생각하지 않도록 조심해야 합니다. 빨리 위신을 회복할수록 일을 잘 하는 데 더 빨리 집중할 수 있습니다.
- 관리직은 조롱의 대상이 될 수 있습니다. 무시해야합니다. - 매니저는 쓸모없다고 믿는 사람들은 성공적인 조직을 쌓는 것에 대한 역학을 이해하지 못하는 것입니다.
- 뭔가 잘못된 것을 느꼈다면, 아마도 맞을 것입니다. 누군가 괴롭히면서 여러분의 감정을 무시하게 하면 안됩니다.
- 만약 자신이 누군가를 비난하고 있는 것을 발견한다면, 아마도 여러분이 잘못된 것입니다. 나쁜 일을 하기 위해 노력하고 일어나는 사람은 아무도 없습니다. 95%의 경우, 사람들과 이야기함으로써 감정을 해소할 수 있습니다.
- 대부분의 사람들은 쉽게 감정을 공유하지 않습니다. 잦은 정보성 대화를 갖고, 잘못되었을 수 있는 모든 것을 찾아내야합니다. 그리고 가능하다면 고쳐야 합니다.
- 여러분의 팀은 여러분에게 리더십을 기대합니다. 모두가 진실이라고 알고 있지만 말하지 않는 것을 말할 수 있는 용기를 가져야 합니다.
- 여러분은 팀에서 발견하지 못한 문화적 문제를 찾고 이를 수정하기 위해 돈을 받는 것입니다. 모든 사람이 알아야 하지만 그렇지 않는 것을 말할 용기를 가지셔야 합니다.
- 좋은 사람을 고용해야 합니다. 그리고 완전히 신뢰해야 합니다. 한 달 혹은 분기 간격으로 성과 평가를 하고 해야만 할 때 해고해야 합니다. 사람들을 매일 평가하면 안됩니다. 이는 모든 사람을 미치게 만들 것입니다.
- 대부분의 지적 논쟁들은 강한 감정적 흐름이 있습니다. 그것들이 무엇인지 배우게 된다면, 극적으로 효과적인 업무를 할 수 있게 될 것입니다.
최종 결정과 갈등
- 지나치게 빨리 판단하면 안됩니다; 생각하는 것보다 여러분이 맞는 경우는 흔치 않습니다. 여러분이 맞다고 확신을 하더라도, 모든 사람의 의견을 듣기 전까지는 기다리십시오.
- 모든 사람의 말을 다 들었다면, 모든 의견의 중점 사항을 요약해서 사람들이 "고마워요, 저도 그렇게 생각했으면 좋았을 텐데요"라고 말하도록 해야한다. 각 관점에서 일치되는 중점 사항을 나열하고 모든 사람으로부터 여러분이 배운 것을 말해야합니다. 그리고 나서 여러분의 결정을 내리십시오.
- 결정을 내렸다면, 밀어붙이셔야 합니다. 팀이 강한 목소리를 달래기 위해 빙빙 돌며 시간을 낭비하게 해서는 안됩니다.
- 의미 있는 정보가 새로 들어왔다면, 회의를 다시 시작해야합니다.
- 의견 충돌이 개인적으로 변하거나 사람들이 합리적인 결정을 받아들이지 못할 때, 이는 갈등으로 변합니다.
- 대부분의 갈등은 상대방이 자신의 말을 들으려고 하지 않을 때 발생합니다. 앉아서 각 사람에게 어떻게 느끼는지 물어보십시오. 잘 듣고 계속해서 물어보십시오. 그리고 나서 요약해서 그들에게 들었던 내용을 알려주십시오. 대부분의 경우 문제가 해결될 것입니다.
- 갈등이 충분히 모든 사람의 말을 듣고 고쳐진 이후에도 지속된다면, 어려운 말을 할 때가 된 것입니다.
어려운 말
- 어려운 말은 가능한한 빨리 하는게 좋습니다. 기다림은 안 좋은 상황을 더 좋지 않게 만들 뿐입니다.
- 절대 가정하거나 결론으로 건너 뛰지 말아야 합니다. 절대 여러분 마음 속에 사람을 악마처럼 만들면 안됩니다. 절대 비난하고 소리지르거나 헐뜯으면 안됩니다.
- 비폭력 의사소통)을 해야합니다. 제가 아는 한 사람들의 행동을 불쾌하게 하지 않고 비판할 수 있는 가장 좋은 방법입니다. 경영계의 유행 같은 냄새가 나지만, 정말 효과가 있습니다.
- 여러분이 어떻게 느끼는지 그리고 무엇이 필요한지 말할 수 있는 용기를 가져야 합니다. 서로의 단점에 빠진 사람들은 자기 자신을 싫어하게 됩니다. 취약점은 약점이 아닙니다.
- 사람들이 당신에게 같은 예의를 베풀기를 기대해야 합니다. 만약 누군가 여러분이 필요한 것과 감정을 드러내는 것에 나쁜 감정을 느끼게 한다면, 그것은 여러분 자신에 대해보다 그들에 대해 더 많이 알려줍니다.
매운 맛
- 사람들은 여러분의 한계에 밀어붙이거나 재촉할 것입니다. 언제 물러 서야하고, 단호해져야하는지 아는 것은 전쟁의 절반입니다.
- 때때로 누군가 너무 지나치게 밀어붙일 수 있습니다. 그들이 그렇게 한다면, 매운 맛을 보여줘야하거나 여러분의 팀에게 권위를 잃게 될 것입니다.
- 단호한 "난 그게 좋지 않아보입니다"면 보통 충분합니다.
- 웃어 넘기고 싶지 않다면, 웃어 넘기면 안됩니다. 여러분의 진실된 감정을 보여주기 위해 용기를 가지십시오.
- 만약 여러분이 강하게 "난 그게 좋지 않아보입니다"를 같은 사람에게 여러번 말해야하는 상황이 온다면, 여러분의 직업은 그들을 해고하는 것입니다.
- 여러분이 소시오패스가 아닌이상, 사람들을 해고하는 것은 정말 힘들어서 해고하지 않을 핑계를 찾게 될 것입니다. 만약 여러분이 지속적으로 누군가 적합한지 지나치게 오래 고민하게 된다면, 여러분이 아는 것을 실행할 용기를 가지는 것이 맞습니다.
- 사람들이 여러분에게 여러분이 믿지도 않는 결정을 하도록 강요하지 않게 해야합니다. 그들은 나중에 그들이 맞았다며 _여러분_에게 책임을 물을 것입니다. 결정은 여러분의 책임입니다.
- 여러분 자신을 믿어야 합니다. 말을 탄 모습이 우스꽝스럽다고 생각되면 기병대를 지휘할 수 없습니다.
이 포스팅을 리뷰해주신 Michael Glukhovsky, Michael Lucy, 그리고 Alex Taussig에게 감사를 표합니다.
Comments