-
마이크로 매니저, 위임하는 매니저DEV 2024. 11. 20. 20:45
사진: Unsplash 의 Kelly Sikkema 마이크로매니지먼트에서 가장 어려운 점은 그렇게 할 때와 하지 않아야 할 때를 구분해야 한다는 점.
주니어 개발자는 구체적인 지시를 원한다. 가끔 세부 사항을 확인하고 지시해야 일을 더 잘한다. 하지만 습관처럼 또는 기본방식으로 마이크로 매니저를 사용하면 좋지 않은 결말을 맞게 될 수 있다.
신뢰할 것인가 통제할 것인가 는 마이크로매니저에게 중요한 문제다. 업무가 제대로 처리될 거라 믿지 못하거나 당신이 정한 기준으로 결과물을 엄격하게 통제하려 할 때 마이크로매니지먼트를 하게 된다. 이런 상황은 뛰어난 개발자가 특히, 기술적으로 자부심이 강한 개발자가 팀장이 될 때 자주 일어난다.
팀에서 당신의 가치가 당신이 잘하는 코딩에서 아직 잘 모르는 사람관리로 바뀌었다면, 팀원들을 자신의 분신처럼 다루고 싶을 수도 있다. 불가피하게 마감 기한을 맞추지 못하면 상황을 제대로 통제하지 못하는 것으로 보고 더 신경 쓰게 된다. 기대와 달리 프로젝트가 잘 진행되지 않는다 생각하게 되고 팀을 마이크로매니지먼트하는 것이 적절한 선택이라는 믿음을 갖게 된다.
자율성은 팀원이 자신의 업무 중 일부를 직접 통제할 수 있는지를 의미하며 동기 부여의 중요한 요소다. 마이크로매니지먼트로 팀을 잘 운영하기 어려운 이유는 바로 자율성 때문이다. 창의적이고 재능 있는 사람이 자율성을 빼앗기면 즉시 동기도 사라진다. 스스로 어떤 결정도 내릴 수 없고, 모든 업무를 매니저가 이중, 삼중으로 확인한다고 느끼게 하는 것만큼 최악은 없다.
반면, 위임은 포기가 아니다. 책임을 위임하더라도 프로젝트가 성공하도록 도와야 한다.
효율적으로 위임하기 위한 실질적인 조언
좋은 리더가 된다는 것은 위임을 잘한다는 것이다.
팀의 목표를 통해 어떤 세부 사항을 파악해야 하는지를 판단하라
마이크로매니지먼트를 하고 싶다면, 팀원에게 업무 성공을 어떻게 측정할 수 있는지, 그 결과를 어떻게 가시적으로 보여줄 수 있는지를 물어라. 그리곤 일단 손을 떼고 한두 주를 기다리며 팀원이 어떤 답을 가져오는지 지켜본다. 공유할 게 없다면 뭔가를 수정해야 하는 것이다. 아마 세부 사항을 파고들어야 할 것이다.
팀원을 만나기 전에 시스템에서 정보를 수집하라
최악의 마이크로매니저는 쉽게 얻을 수 있는 정보인데도 끊임없이 묻는 사람이다. 팀원에게 현재 진행 상황을 정리해 달라고 할 수도 있고, 모든 중요 정보를 정리하기 위해 팀원에게 요청하는 것도 괜찮지만, 가능하면 요청하지 않는 것이 좋다. 매니저가 쉽게 확인할 수 있는 정보를 수집하는 데 업무 시간의 절반을 쓰는 팀은 절대로 생산성이 높거나 행복할 수 없다. 기억해야 할 것은 이런 정보가 어떤 맥락의 일부일 뿐이고, 전체 그림이 아니며 앞서 논의한 목표가 없다면 아무 의미도 없다는 점이다.
프로젝트 단계에 따라 확인할 부분을 달리하라
프로젝트 시작과 설계 단계라면 좋은 프로젝트 목표나 좋은 시스템 설계안을 세우도록 더 많이 관여할 수 있다. 프로젝트 마감일이 가까워질수록 세부 사항은 더 중요해진다. 더 많은 결정을 내려야 하고, 세부 사항으로 더 많은 실행 가능한 정보를 전달하기 때문. 그러나 정상적인 작업 흐름일 때에는 어떤 부분이 잘 진행되고, 어떤 부분이 기대보다 오래 걸리는지를 파악하는 정도면 충분하다.
코드 및 시스템 표준을 설정하라
팀의 표준 업무 방식을 만들면 코드나 설계 리뷰에서 팀원 간 소통이 원활해지며 기술적 피드백을 주고받는 과정을 객관화할 수 있다. 예를 들어 코드를 변경할 때마다 어느 정도로 유닛 테스트를 할지, 기술적 결정 사항에 대해 어느 시점에서 팀원들이 리뷰할지 등을 의미한다. 목표를 설정하면 어떤 세부 사항을 진행해야 하는지 파악할 수 있는 것처럼 표준 업무 방식을 정하면 팀원이 기술 업무를 할 때 어떤 세부 사항을 중요하게 다루어야 하는지 이해하는데 도움이 된다.
좋은 정보든 나쁜 정보든 중립적 태도로 정보를 개방하기
프로젝트를 진행하면서 어려움을 겪고 있는 팀원이 문제에 관한 도움을 부탁하지 않았다면 이 상황에서 팀원이 자신의 상황을 알리지 않은 것을 두고 마이크로매니지먼트로 처벌하는 것이 아니다. 이렇게 하면 팀원이 자신의 업무에 챔임감을 갖지 않기 때문이다. 매니저로서 목표는 팀원에게 무엇을, 언제, 어떻게 소통해야 하는지를 이해시키는 것이다. 이때 주의할 점은 힘들어하는 개발자나 프로젝트에 대한 문제를 매니저로서 실패했다는 의미로 말한다면 당사자는 비난이나 비판을 받는 느낌을 받을 것이다. 그러면 자세한 정보를 공유하기보다는 비난을 피하기 위해서 어떻게 해볼 수 없을 때까지 문제를 숨기게 될 수 있다. 중요한 정보를 일부러 숨기는 것이 실패이며, 어려운 문제에 부딪히거나 실수하는 것이 바로 학습 기회가 된다는 것을 알려줘야 한다.
장기적으로 세부 사항을 위임하고, 팀을 신뢰할 수 있는 방법을 이해하지 못하면 팀장 개인으로서 힘들어질 수 있다.
개발 7년차 매니저 1일차 – Daum 검색
Daum 검색에서 개발 7년차 매니저 1일차에 대한 최신정보를 찾아보세요.
search.daum.net
728x90'DEV' 카테고리의 다른 글
Agentic RAG (2) 2024.11.22 프로젝트 일정 관리 방법 (1) 2024.11.21 프로젝트 관리에 도움 되는 가이드라인 (1) 2024.11.19 class에 단일 책임이 있는지 판단하는 방법 (0) 2024.11.18 AI agent frameworks (4) 2024.11.16