You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
관리자나 팀장과 원할한 관계를 구축하면 경력이나 스트레스 감소, 안정적인 소프트웨어 출시에도 도움이 된다.
관리자들이 하는 일
팀장들은 늘 회의 중인 것처럼 보이지만 정확히는 무슨 일을 하는지는 명확하지 않다. 엔지니어링 관리자인 팀장은 직원을 보살피고 제품과 절차도 관리하며, 팀을 구축하고 엔지니어를 코칭하고 성장을 도우며 원할한 대인관계를 유지할 수 있도록 관리한다.
또한, 제품 개발을 계획하고 조율하기도 한다. 제품 개발의 기술적 관점에 무게를 두기도 하지만 훌륭한 엔지니어링 관리자가 코드를 직접 작성하는 일은 거의 없다. 마지막으로 팀장은 팀이 효율적으로 일할 수 있도록 팀의 절차를 살핀다. 팀장은 더 높은 직급의 임원이나 디렉터, 다른 팀장 그리고 자신의 팀들과 협업을 통해 이 모든 것을 관리한다.
성공적인 업무 수행과 평가를 위한 절차를 마련하자
팀장들은 팀과 개인들이 원활하게 업무를 수행할 수 있는 절차를 만든다. 가장 보편적인 팀 위주 절차 프레임워크인 애자일 방법론은 앞서 12장에서 다뤘다.
일대일 회의
팀장은 매주 또는 격주로 팀원들과 일대일 회의를 계획할 것이다. 일대일 회의는 팀원과 팀장이 중요한 주제를 논의하고 큰 계획에 대한 우려사항을 해결하며 생산적이고 장기적인 관계를 구축하기 위한 시간이다. 일대일 회의는 이미 널리 알려진 기법이지만 그저 상태 점검이나 문제 해결 세션으로 전락하는 경우도 많다.
따라서 일대일 회의를 할 때는 안건을 정해두고 발언을 많이 해야 한다. 회의를 시작하기 전에 팀장에게 회의 안건을 간략하게 요약해 공유하자. 지난 회의의 안건과 대화 기록은 문서로 남기자. 팀장과 일대일 회의 전후에 이 문서를 공유하고 업데이트해야 한다.
즉, 일대일 회의의 안건은 팀장이 아닌 팀원이 정해야 하며, 일대일 회의는 단순한 업무 보고가 아니다. 이 두 가지를 지키는 것만으로 낭비되는 수많은 시간을 줄일 수 있다.
PPP 회의
PPP 회의는 업무 보고 형식으로 이뤄진다. 업무 보고란 그저 업무 시간을 추적하는 것이 아닌 팀장을 도와 문제점을 찾고 배경지식을 필요로 하는 부분을 파악하며, 팀원에게 적임자를 연결해줄 기회를 찾게 하기 위함이다. 업무 보고를 하다 보면 일대일 회의 주제가 드러나기도 하고 업무를 어떻게 해왔는지, 지금은 어떻게 하고 있는지, 방해물이 있느지를 파악하는데 도움이 된다.
이름에서 알 수 있듯이 PPP는 P로 시작하는 3가지 섹션(진척상황 progress, 계획Plan, 문제Problem)으로 구성된다. 각 섹션에는 35가지 요점이 있으며 각 요점은 13개 문장으로 간단하게 요약해야 한다.
공유해야 할 사항을 PPP로 정리하여 팀장을 통해 정제하고 팀원들에게 공유한다면 좋은 방법이 될 것 같다.
OKR
OKR프레임워크는 회사가 성공을 위한 목표를 정의하고 측정하는 방법이다. OKR 프레임워크는 회사, 팀, 개인이 모두 목표를 정의하고 각 목표에 대한 측정 지표를 추가한다. 각 목표에는 3~5가지 핵심 결과가 있으며 이것이 지표가 되어 목표를 완수하기 위한 진척 정도를 표현한다.
성과 평가
팀장들은 보통 1년에 한두 번, 정기적으로 공식적인 성과 평가를 수행한다. 직책과 보상의 조정 역시 평가 기간에 이뤄진다. 평가는 보통 다음과 같은 도구나 템플릿을 이용해 수행한다.
올해 수행한 업무는 무엇인가?
올해 잘한 일은 무엇인가?
올해 좀 더 개선할 수 있었던 부분이 있는가?
경력을 어떻게 개발하고 싶은가? 향후 3~5년 후 본인의 모습은 어떨 것이라고 생각하는가?
직원들이 스스로 평가하고 그 후에 팀장이 그에 대한 피드백을 제공한다.
팀장이나 상사도 여러분의 관리가 필요하다
관리자나 팀장들이 더 높은 임원이나 디렉터를 관리하는 것처럼 팀원도 팀장을 돕거나 팀장이 돕도록 관리해야 한다. 팀장에게 피드백을 제공함으로써 팀원들도 팀장을 도울 수 있다.
팀장의 피드백이 적을 경우 적극 요청하자
성과 평가와 다면평가는 종합적인 피드백을 제공해주지만 자주 수행하는 것도 아니어서 거기에만 의존할 수는 없다. 따라서 여러분의 업무 수행 능력을 신속하게 조정할 수 있는 정기적인 피드백이 필요하다.
팀장이 알아서 피드백을 항상 제공하진 않을 테므로 필요하다면 직접 요청해야 한다. 일대일 회의는 피드백을 받기 좋은 시간이다. 따라서 회의 전에 미리 질문을 보내 회의 때 구체적인 피드백을 받을 수 있도록 하자.
팀장도 여러분의 피드백을 원한다
좋은 팀장은 팀으로부터 피드백을 받길 원한다. 팀장은 어떤 부분이 잘 동작하고 어떤 부분이 잘 동작하지 않는지 알아야 한다. 팀의 모든 개개인은 각자의 관점을 가지고 있다. 피드백을 잘 제공한다면 사각지대를 없앨 수 있다.
피드백의 주제는 무엇이든 될 수 있다. 팀, 회사, 행동, 프로젝트, 기술적 계획, 심지어 인사 정책을 언급해도 된다. 문제를 제기하되 문제에만 집중하자. 긍정적인 피드백은 그 자체로도 가치가 있다. 팀장 입장에서는 어떤 변화가 긍정적인 효과를 가져왔는지 알기가 어려우며, 팀장의 업무는 단위 테스트로 확인할 수 있는 것이 아니기 때문이다.
여러분의 목표에 대해 팀장과 허심탄회하게 논의하자
여러분이 경력을 어떻게 개발해나가고 싶은지 팀장이 늘 알아줄 것이라는 기대는 하지 말자. 원하는 목표와 바람은 팀장에게 분명하게 표현하고 이를 달성할 수 있도록 도움을 요청하자. 이런 대화는 공식적인 리뷰시간에 하는 것이 좋다.
다 시도해봤는데도 안 된다면
모든 직원과 팀장 관계는 저마다 독특하므로 보편적인 조언을 주기란 어렵다. 각각의 상황은 회사, 팀, 관리자, 직원에 따라 모두 다르다. 우리가 확실하게 말해줄 수 있는 것은 일이 잘 풀리지 않는 것 같다는 생각이 들면 주도적으로 행동해야 한다는 점이다.
관계와 업무는 부침을 겪는다. 잠깐 상황이 어려워진다고 해서 뭔가 극단적인 조치를 취할 필요가 없다. 하지만 좌절감이나 불만, 스트레스가 지속된다면 목소리를 낼 필요가 있다.
결론
회사랑 다른 성격인 작은 프로젝트 팀이긴 하지만 팀장을 맡고 있어서 생각해볼만한, 적용해볼만한 거리가 많은 챕터인 것 같다. 마찬가지로 환경과 상황이 다 다르다보니 유연하게 적용해봐야 할 것 같다.
논의사항
여러분들은 팀 관리자가 반드시 잘 해야만 하는 일이 뭐라고 생각하시나요?
The text was updated successfully, but these errors were encountered:
13장 관리자, 팀장, 상사와 함께 일하기
관리자나 팀장과 원할한 관계를 구축하면 경력이나 스트레스 감소, 안정적인 소프트웨어 출시에도 도움이 된다.
관리자들이 하는 일
팀장들은 늘 회의 중인 것처럼 보이지만 정확히는 무슨 일을 하는지는 명확하지 않다. 엔지니어링 관리자인 팀장은 직원을 보살피고 제품과 절차도 관리하며, 팀을 구축하고 엔지니어를 코칭하고 성장을 도우며 원할한 대인관계를 유지할 수 있도록 관리한다.
또한, 제품 개발을 계획하고 조율하기도 한다. 제품 개발의 기술적 관점에 무게를 두기도 하지만 훌륭한 엔지니어링 관리자가 코드를 직접 작성하는 일은 거의 없다. 마지막으로 팀장은 팀이 효율적으로 일할 수 있도록 팀의 절차를 살핀다. 팀장은 더 높은 직급의 임원이나 디렉터, 다른 팀장 그리고 자신의 팀들과 협업을 통해 이 모든 것을 관리한다.
성공적인 업무 수행과 평가를 위한 절차를 마련하자
팀장들은 팀과 개인들이 원활하게 업무를 수행할 수 있는 절차를 만든다. 가장 보편적인 팀 위주 절차 프레임워크인 애자일 방법론은 앞서 12장에서 다뤘다.
일대일 회의
팀장은 매주 또는 격주로 팀원들과 일대일 회의를 계획할 것이다. 일대일 회의는 팀원과 팀장이 중요한 주제를 논의하고 큰 계획에 대한 우려사항을 해결하며 생산적이고 장기적인 관계를 구축하기 위한 시간이다. 일대일 회의는 이미 널리 알려진 기법이지만 그저 상태 점검이나 문제 해결 세션으로 전락하는 경우도 많다.
따라서 일대일 회의를 할 때는 안건을 정해두고 발언을 많이 해야 한다. 회의를 시작하기 전에 팀장에게 회의 안건을 간략하게 요약해 공유하자. 지난 회의의 안건과 대화 기록은 문서로 남기자. 팀장과 일대일 회의 전후에 이 문서를 공유하고 업데이트해야 한다.
즉, 일대일 회의의 안건은 팀장이 아닌 팀원이 정해야 하며, 일대일 회의는 단순한 업무 보고가 아니다. 이 두 가지를 지키는 것만으로 낭비되는 수많은 시간을 줄일 수 있다.
PPP 회의
PPP 회의는 업무 보고 형식으로 이뤄진다. 업무 보고란 그저 업무 시간을 추적하는 것이 아닌 팀장을 도와 문제점을 찾고 배경지식을 필요로 하는 부분을 파악하며, 팀원에게 적임자를 연결해줄 기회를 찾게 하기 위함이다. 업무 보고를 하다 보면 일대일 회의 주제가 드러나기도 하고 업무를 어떻게 해왔는지, 지금은 어떻게 하고 있는지, 방해물이 있느지를 파악하는데 도움이 된다.
이름에서 알 수 있듯이 PPP는 P로 시작하는 3가지 섹션(진척상황 progress, 계획Plan, 문제Problem)으로 구성된다. 각 섹션에는 3
5가지 요점이 있으며 각 요점은 13개 문장으로 간단하게 요약해야 한다.공유해야 할 사항을 PPP로 정리하여 팀장을 통해 정제하고 팀원들에게 공유한다면 좋은 방법이 될 것 같다.
OKR
OKR프레임워크는 회사가 성공을 위한 목표를 정의하고 측정하는 방법이다. OKR 프레임워크는 회사, 팀, 개인이 모두 목표를 정의하고 각 목표에 대한 측정 지표를 추가한다. 각 목표에는 3~5가지 핵심 결과가 있으며 이것이 지표가 되어 목표를 완수하기 위한 진척 정도를 표현한다.
성과 평가
팀장들은 보통 1년에 한두 번, 정기적으로 공식적인 성과 평가를 수행한다. 직책과 보상의 조정 역시 평가 기간에 이뤄진다. 평가는 보통 다음과 같은 도구나 템플릿을 이용해 수행한다.
직원들이 스스로 평가하고 그 후에 팀장이 그에 대한 피드백을 제공한다.
팀장이나 상사도 여러분의 관리가 필요하다
관리자나 팀장들이 더 높은 임원이나 디렉터를 관리하는 것처럼 팀원도 팀장을 돕거나 팀장이 돕도록 관리해야 한다. 팀장에게 피드백을 제공함으로써 팀원들도 팀장을 도울 수 있다.
팀장의 피드백이 적을 경우 적극 요청하자
성과 평가와 다면평가는 종합적인 피드백을 제공해주지만 자주 수행하는 것도 아니어서 거기에만 의존할 수는 없다. 따라서 여러분의 업무 수행 능력을 신속하게 조정할 수 있는 정기적인 피드백이 필요하다.
팀장이 알아서 피드백을 항상 제공하진 않을 테므로 필요하다면 직접 요청해야 한다. 일대일 회의는 피드백을 받기 좋은 시간이다. 따라서 회의 전에 미리 질문을 보내 회의 때 구체적인 피드백을 받을 수 있도록 하자.
팀장도 여러분의 피드백을 원한다
좋은 팀장은 팀으로부터 피드백을 받길 원한다. 팀장은 어떤 부분이 잘 동작하고 어떤 부분이 잘 동작하지 않는지 알아야 한다. 팀의 모든 개개인은 각자의 관점을 가지고 있다. 피드백을 잘 제공한다면 사각지대를 없앨 수 있다.
피드백의 주제는 무엇이든 될 수 있다. 팀, 회사, 행동, 프로젝트, 기술적 계획, 심지어 인사 정책을 언급해도 된다. 문제를 제기하되 문제에만 집중하자. 긍정적인 피드백은 그 자체로도 가치가 있다. 팀장 입장에서는 어떤 변화가 긍정적인 효과를 가져왔는지 알기가 어려우며, 팀장의 업무는 단위 테스트로 확인할 수 있는 것이 아니기 때문이다.
여러분의 목표에 대해 팀장과 허심탄회하게 논의하자
여러분이 경력을 어떻게 개발해나가고 싶은지 팀장이 늘 알아줄 것이라는 기대는 하지 말자. 원하는 목표와 바람은 팀장에게 분명하게 표현하고 이를 달성할 수 있도록 도움을 요청하자. 이런 대화는 공식적인 리뷰시간에 하는 것이 좋다.
다 시도해봤는데도 안 된다면
모든 직원과 팀장 관계는 저마다 독특하므로 보편적인 조언을 주기란 어렵다. 각각의 상황은 회사, 팀, 관리자, 직원에 따라 모두 다르다. 우리가 확실하게 말해줄 수 있는 것은 일이 잘 풀리지 않는 것 같다는 생각이 들면 주도적으로 행동해야 한다는 점이다.
관계와 업무는 부침을 겪는다. 잠깐 상황이 어려워진다고 해서 뭔가 극단적인 조치를 취할 필요가 없다. 하지만 좌절감이나 불만, 스트레스가 지속된다면 목소리를 낼 필요가 있다.
결론
회사랑 다른 성격인 작은 프로젝트 팀이긴 하지만 팀장을 맡고 있어서 생각해볼만한, 적용해볼만한 거리가 많은 챕터인 것 같다. 마찬가지로 환경과 상황이 다 다르다보니 유연하게 적용해봐야 할 것 같다.
논의사항
The text was updated successfully, but these errors were encountered: