|
엔지니어가 경력이 쌓이면서 어쩔수 없이 관리자가 되는 경우가 많다보니
관리라는 것을 제대로 하는 사람을 보기가 힘들다.
훌륭한 관리를 받아본 적도 없으니, 정작 자신이 관리자가 되었을 경우엔
지금까지의 몹쓸 관리자 역할을 답습하고 있는 자신을 발견하게 되기도 하고,
잘 해보려고 버둥거리다가 시행착오를 겪고 좌절하기도 한다.
이 책은 개발자에서 관리자가 된 초보 팀장들 혹은 여러 해 관리를 해오고 있지만
정작 자신의 역할이 무엇인지 아직도 해답을 찾지 못한 사람들이 읽으면 좋을 책이다.
무척 실용적이며, 개발자가 기술적인 역할을 버리고 관리직으로 옮겨가면서 느끼는
초조함이나 어려움을 잘 표현한 책이라 많은 공감을 했다.
항상 옆에 두고 참고하면 좋은 그런 책이다.
이 책의 원제목은 "Behind Closed Doors"다. 즉 위대한 관리는 닫힌 문 뒤에서 일어나는 일처럼 눈에 띄지 않는다는 뜻이다. 훌륭한 관리자는 상하관계를 떠나서 동료로서 정서적인 교감을 통해 팀원의 능력을 끌어낸다. 그러나 많은 관리자는 열린 문을 통해 권의의식을 드러낼 뿐, 닫힌 문 안에서 팀원에게 다가가려고 하지 않았다. 이 책은 이 점에 착안하여 훌륭한 관리자가 드러나지 않는 부분에서 팀원의 능력을 이끌어 내기 위하여 팀원에게 어떻게 다가서는지 보여준다.
...
결과와 일정만을 다루는 관리처럼 손쉬운 관리도 없다. 그러나 진정한 관리의 매력은 고객과 팀원과 섞여서 동료로서 대화하고 사람들이 가진 잠재능력을 이끌어 내어 좋은 결과로 마무리 될 때다. 결국 인간이란 천상천하유아독존이 아닌 이상 사람과 사람 사이에서 그 의미를 찾기 때문이다.
p.17 (옮긴이 서문 중에서)
관리자들 사이에 공통의 목표가 없을 때, 관리자 개개인은 종종 부서의 전체 목표를 희생하면서 자신의 목표만을 최적화하려는 경향이 있습니다. 공유하는 목표를 갖지 못한 관리자는 자신만의 영역을 위해 싸우고 서로 모순되는 각자의 목표에 따라 일합니다. 공통의 목표를 만드는 일은 관리자 그룹을 팀으로 행동하게 합니다. 그렇지 않으면 실패합니다.
p.97
＜시기 적절한 피드백 주기＞
-가능하다면 문제가 발생했을 때 피드백을 주세요.
-사적으로 피드백 주기.
: 곤란하거나 혼란스러운 정보를 들을 때 사람들은 사적인 대화를 원합니다.
-행동이나 결과를 이야기 하세요.
: 피드백을 줄 때는 잘못을 바로잡고 내용에 힘을 실어 줄 수 있도록 실질적인 것에 근거하여 상세하게 이야기하세요. 모호하고 증거도 없이 말하는 것은 불복만을 낳습니다. "코드를 전혀 테스트하지 않는군요." 라고 말하는 대신에, "마지막 변경 3개를 체크인 했을 때 매번 빌드가 깨지더군요."라고 말하세요.
-평가는 피드백과 다릅니다.
: "훌륭해요" 혹은 "진짜 나아졌어요"와 같은 이야기는 평가입니다. 관리자는 평가도 해야 하지만, 평가는 피드백과 다른 목적으로 쓰입니다.
-피드백을 받는 상대편 사람이 뭐라고 말하는지 귀 기울이세요.
: 데이터에 동의하는지 확인하세요. 입장을 바꿔서 그 사람의 위치에서 들은 내용을 이해해 보세요.
-피드백 대화 내용을 적어 두세요.
: 성과와 관련된 모든 대화를 비공식적으로 기록해 두세요.
＜피드백이 상황을 바로잡지 못할 때＞
-구두 경고부터 시작하세요.
-문서 경고를 주세요.
-개선 계획을 수행하세요.
: 개선 계획에 따라 피고용인은 짧은 기간(4~5주) 내에 자신이 기준 이상이라는 증거를 반드시 보여주어야 합니다.
-낮은 성과의 파급 효과를 과소 평가하지 마세요.
: 가끔은 누구나 안좋을 때가 있습니다. 그러나 오랜 기간 동안의 낮은 성과는 전체 팀의 결과 뿐만이 아니라 근로의욕에도 영향을 줍니다. 낮은 성과가 계속된다면 이러한 이슈를 해결하고 논의하세요.
p.102~105
격한 감정을 관리하는 프로세스는 다음과 같이 그려 볼 수 있다.
첫째, 명확한 사실과 해석에 대해서 물어 보자.
둘째, 긍정적인 결과는 어떤 모습일지 물어 보자.
마지막으로 부당한 표현, 선입견이나 감정적인 발산을 회사에 있는 다른 사람과 공유하는 것은 도움이 안 된다는 사실을 명확하게 하자.
감정 발산이 하나의 패턴이 될 때(원한을 품거나 어떤 사람이나 사건에 사로 잡혀 있다면), 이것은 다른 문제에 대한 신호다. 피드백을 제안하고 반복되는 감정 발산의 영향에 대해서 코칭하자.
p.123
멍청이라고 단정짓는 대신에, 다른 사람의 행동을 관대하게 해석하고 다음과 같이 자문해 보자.
"이 사람은 똑똑하고, 좋은 의도를 지녔으며, 합리적인 동기가 있다고 하자. 이런 식으로 말하고 행동하는데 무슨 이유가 있을까?"
그럴듯한 대안 세가지를 생각해 보자. 그리고 어떻게 비칠지 모르겠지만 때로 누군가 멍청이처럼 행동하고 말하더라도 어떤 사람이든 도움을 주려고 노력해 본다.
p.125
＜감당할만한 속도＞
관리자나 기술직에 있는 간부가 매일같이 스스로 일을 만드는 것을 본 적이 있을 것이다. 그들은 멍하니 컴퓨터 스크린을 응시하며, 커피가 가득한 큰 잔을 두고 하품을 한다. 이들은 성급하게 대응해서 어리석은 실수를 저지른다. 때때로 그들의 결정은 단지 의심스러운 정도가 아니라, 명백히 잘못된 것처럼 보인다.
그들은 멍청한 사람이 아니다. 그리고 나쁜 사람도 아니다. 그들은 탈진 증후군(burnout syndrome) 상태에 있는 사람들이다.
증상이 어떻든지 간에, 탈진 현상은 할 일이 너무나 많지만 일할 시간이 없으며, 어쨌든 그 사람이 모든 일을 처리하려고 할 때 나타난다. 특히 관리자의 일부에서 나타나는 탈진 현상은 전체 팀을 무너뜨릴 수 있다.
탈진 현상을 피하는 방법은 멀티태스킹을 제거하기 위해서 한번에 하나의 일을 감당할만한 속도로 하는 것이다.
대부분의 사람은 감당할만한 속도로써 일주일에 40~50시간 정도 일할 수 있다. 그렇다. 한 두 주 정도는 40시간 이상 일하는 것도 가능하다. 그러나 그 이상 일한다면 기력은 소모되고, 실수가 잦아지며, 낮은 생산성을 초래하게 된다.
이것은 새로운 이야기가 아니다. 1909년까지 거슬러 올라가서, 일주일에 40시간 이상을 일하는 사람은 생산성이 낮다는 사실을 연구자들이 알아냈다. 주당 40시간의 감당할만한 속도로 일하는 것은 나약한 것이 아니다. 현명한 비즈니스 결정이며, 결국 여러분의 일이 문제없이 잘 진행되도록 하는 것이다.
p.131~132
＜성가신 문제 파악하기: 한 사람의 관리자가 수정할 수 있는 것보다 문제가 더 큰 경우＞
-인위적인 제약 조건이 있는지 살펴 보세요.
-근본적인 문제를 알려주는 암시에 귀 기울이세요.
-실행할 수 있는 해결책을 찾아보세요.
-비난을 하기보다, 문제를 고치세요.
p.134
관리자는 관리 업무에 집중할 필요가 있습니다. 초보 수준의 관리자는 여전히 기술 업무를 하지만 그래도 주요 공정 상의 업무를 맡아서는 안됩니다. 기술 업무와 관리 업무를 더 이상 할 수 있을지 여부는 관리 책임의 크기와 기술 업무의 양에 달려 있습니다. 기술 업무는 만족과 능력이 뛰어나다는 감정에 연료를 공급하기 때문에 많은 엔지니어는 기술 업무를 포기하는 일이 어렵습니다.
＜관리 업무 시간의 예시＞ - 팀원이 4명인 경우
-회의시간: 일대일 회의, 팀회의, 여분의 준비시간을 포함함 (5시간)
-프로젝트 포트폴리오 관리하기 (1시간)
-상위 관리자와 보낸 시간 (1시간)
-조직 전체에 걸쳐서 동료관리자와 보낸 시간 (1시간)
-팀원과 함께 문제 해결하기 - 개인당 4시간 (16시간)
-조직적인 이슈 (예측할 수 없음)
-최적의 상태에서 최소한의 관리 시간은 주당 24시간
p.149~151
|