팀에서는 구성원(Team members)과 관리자의 역할이 완전히 다르다. 팀의 구성원은 공통의 목적을 달성하기 위해 협력한다. 그들은 목적의 달성 여부에 따라 함께 평가 받는다. 관리자는 팀의 외부 조력자의 역할을 한다. 팀 내의 갈등을 중재하고, 프로젝트의 진행을 가로막는 장애물을 제거한다. 엄밀히 말해 관리자는 팀의 구성원이 아니다.
만약 관리자와 그밖의 구성원의 역할이 비슷하다면, 팀의 정체성을 재검토해봐야 한다. 특히 조직의 구성원 모두가 거의 동일한 조건하에서 성과제에 따른 급여를 받고 있다면, 이 조직은 팀이 아닌 워크그룹이다. 공통의 목적이 아닌 각자의 성과 달성에 집중하는 조직은 팀의 정체성을 잃어버린 것이다.
주의사항: 워크그룹을 팀으로 바꾸기 전에 반드시 그래야만 하는지부터 생각해봐야 한다. 무조건 팀이 좋다고 할 수는 없다. 업무의 성격에 따른 조직 구성이 필요하다.
P.S. 위의 견해는 나만의 독창적인 생각이 아니다. 소프트웨어 공학 분야의 명저서에서 수차례 언급된 사항이다. 대표적인 작품으로 피플웨어를 꼽을 수 있다. Extreme Programming Installed : XP 도입을 위한 실전 입문을 읽다가, 생각나는 내용을 메모해봤다.
Author Details
Kubernetes, DevSecOps, AWS, 클라우드 보안, 클라우드 비용관리, SaaS 의 활용과 내재화 등 소프트웨어 개발 전반에 도움이 필요하다면 도움을 요청하세요. 지인이라면 가볍게 도와드리겠습니다. 전문적인 도움이 필요하다면 저의 현업에 방해가 되지 않는 선에서 협의가능합니다.
포스트를 읽어보니 ‘조엘 온 소프트웨어’에서 관리자에 대한 글귀가 떠오릅니다. 저는 개인적으로 조엘이 말하는 관리자(급)의 조건에 대해 찬성 하지는 않습니다.
실질적으로 프로젝트에 최적화된 팀의 조건인지는 무엇인지는 모르겠습니다만, 워크그룹(개개인 성과에 따른 비교 우위)인 경우는 모두 열심히 하는데 함께 하지 못하며(서로 경쟁의식에 따른 적대화), 팀의 경우는 모두 열심히 하더라고 그 결과 또는 그 성과는 팀장 또는 관리자가 독자치 하는데 문제(윗선은 팀장의 노력만 평가 대상으로 삼고 있음)가 있다고 봅니다.
저는 ‘만약 관리자와 그밖의 구성원의 역할이 비슷’ 한 상황에 현재 놓여 있습니다. 물론 비중이 관리자 또는 구성원, 어느쪽 역할에 더 비슷하냐에 따라 상황이 다르기는 하지만, 실로 슈퍼스타급 팀(관리자와 개발자를 구분지을 수 있을 만큼)이 아닌 이상은 좀 더 잘 아는 팀원 위주로 분위기가 흐르기 마련이며, 대부분 그런 사람이 팀장 혹은 관리자가 되버립니다. 이런 상황을 반대하는 것은 아니지만, 팀장과 관리자는 다른데… 위에서는 같게 보는게 한숨이 나올 뿐입니다.
저라고 karkata님과 사정이 다르겠습니까. 위의 글은 현 상황에선 이상론임을 인정합니다. 각자의 역할과 성과를 객관적으로 평가할 평가방식이 우선 정립돼야, 팀에 활력을 불어넣을 수 있겠죠.
요즘은 아무 조직이나 팀이라고 부르는 것 같습니다. 사실은 워크그룹인데도 말이죠. 서로 협력보다는 경쟁을 하게 만들면서, 그리고 서로의 업무가 분리되어 있으면서 그런 조직을 팀이라고 칭하고 협력을 강조합니다. 이율배반적이라고 아니할 수 없네요. 상당수의 조직은 워크그룹일텐데, 이런 경우에는 그런 사실을 인정하고, 필요한 경우에 Task Force 팀을 꾸리는 방식이 낫다고 생각합니다. 아, 이것도 이상론입니다.