지휘자에게 배우는 팀 리딩

 

프로젝트를 이끄는 일을 맡게 되면서 리더십이 무엇일까 자주 생각하게 됐어요.
책에 나오는 이야기는 머리로는 이해가 되는데 막상 팀 앞에서는 잘 떠오르지 않더라고요.
그러던 중 오케스트라 공연 영상을 보다가 지휘자가 하는 일이 프로젝트 매니저와 닮았다는 생각이 들었습니다.
오늘은 그 비유를 따라가며 제 나름의 팀 리딩 메모를 남겨 둡니다.
음악을 전문적으로 아는 사람은 아니라서 어디까지나 비유로 읽어 주세요.

 

지휘자는 악기를 연주하지 않습니다.
무대 위에서 가장 눈에 띄는 자리에 서 있지만 정작 자기 손으로는 소리를 한 번도 내지 않아요.
처음에는 이상하다고 느꼈는데, 곰곰이 보니 이것이 핵심이었습니다.
각 연주자가 자기 소리에 집중하는 동안 전체가 어떻게 들리는지를 책임지는 사람이 지휘자입니다.

PM도 비슷하다고 생각해요.
기획서를 쓰고 화면을 그리는 일은 팀원들이 합니다.
PM이 모든 걸 직접 하려 들면 전체의 균형을 볼 사람이 없어지더라고요.
내가 직접 소리를 내는 일을 줄이고, 합이 맞는지 듣는 시간을 늘려야 한다는 생각이 들었어요.

여기서 오해하기 쉬운 점이 있어요.
손을 놓는다는 것이 관심을 놓는다는 뜻은 아니라는 점입니다.
지휘자는 악보를 누구보다 깊이 읽고, 각 파트가 어디서 들어오는지 모두 알고 있어야 해요.
PM도 직접 하지는 않더라도 팀이 하는 일의 내용을 이해하고 있어야 적절한 순간에 신호를 줄 수 있습니다.
저는 이해는 깊게, 개입은 최소로 하는 쪽을 목표로 삼고 있어요.

 

지휘자의 가장 기본 동작은 박자를 보여 주는 일입니다.
연주가 시작되기 전에 속도와 분위기를 손짓으로 알려 줘요.
프로젝트에서 이 역할은 일정과 우선순위를 분명히 하는 일에 해당한다고 봅니다.

가정해서 하나 떠올려 볼게요.
네 명이 두 주 동안 새 가입 화면을 만드는 프로젝트가 있다고 합시다.
디자이너는 완성도를 높이고 싶어 하고, 개발자는 일정을 걱정하고, 기획자는 기능을 더 넣고 싶어 합니다.
이때 이번 주 목표는 가입을 끝까지 마칠 수 있는 최소 흐름이라고 한 문장으로 정해 주면 모두가 같은 박자로 움직일 수 있어요.
박자가 없으면 각자 실력이 좋아도 소리가 겹쳐서 어수선해집니다.

박자를 정하는 방식에도 요령이 있어요.
일정표만 공유하기보다 이 일이 왜 이 속도로 가야 하는지 이유를 함께 말해 주면 팀이 스스로 속도를 맞춥니다.
이유 없이 서두르라고만 하면 서두르는 척만 하게 되더라고요.
반대로 여유가 있는 구간에서는 여유가 있다고 분명히 말해 주는 것도 박자의 일부라고 생각해요.

 

오케스트라에는 현악기, 관악기, 타악기처럼 성격이 다른 파트가 있고 지휘자는 파트마다 다른 방식으로 신호를 줍니다.
같은 지시라도 받아들이는 방식이 다르기 때문이에요.
팀에서도 마찬가지로 기획, 디자인, 개발은 쓰는 말이 달라요.
같은 요청이라도 디자이너에게는 사용자가 느낄 인상으로, 개발자에게는 처리해야 할 조건으로 전달하는 편이 잘 통하더라고요.
상대의 언어로 바꿔 말하는 일이 리더의 중요한 번역 작업이라고 생각합니다.

가정해서 예를 들어 볼게요.
주문 상태 알림을 바꿔 달라는 요청이 들어왔다고 합시다.
디자이너에게는 고객이 알림을 받고 어떤 기분일지, 어떤 문구가 안심을 줄지를 이야기합니다.
개발자에게는 상태가 바뀌는 시점이 언제인지, 전송이 실패했을 때 몇 번까지 다시 시도할지를 정리해서 건넵니다.
같은 일을 두고도 두 사람에게 필요한 정보가 다르기 때문이에요.

 

지휘자는 한 악기의 소리가 튀면 그 악기를 탓하기보다 전체에서 어떤 균형이 깨졌는지를 먼저 듣습니다.
프로젝트에서도 한 사람의 속도가 느릴 때 그 사람의 문제로 보지 않으려고 해요.
앞 단계에서 넘겨받은 정보가 부족했거나 요구가 중간에 바뀌었을 가능성을 먼저 살펴봅니다.
문제를 사람이 아니라 흐름으로 보면 대화가 훨씬 부드러워져요.

가정 장면을 하나 더 그려 볼게요.
마감 사흘 전에 개발자가 화면이 아직 안 나왔다고 말한다고 해 봅시다.
이때 왜 이렇게 늦었냐고 묻기 전에 어떤 정보를 기다리고 있는지 먼저 물어봅니다.
알고 보니 디자인 파일의 한 화면이 확정되지 않아서 막혀 있었다면, 풀어야 할 사람은 개발자가 아니라 조율을 맡은 저예요.
이런 식으로 듣다 보면 책임을 묻는 자리가 아니라 길을 찾는 자리로 바뀝니다.

 

악보에는 소리를 내지 않는 쉼표가 있고, 쉼표를 정확히 지키는 것도 합주의 일부입니다.
팀도 항상 최대 속도로 달릴 수는 없습니다.
바쁜 시기 뒤에 의도적으로 가볍게 가는 주간을 두는 것이 다음 도약을 위해 필요하다고 느껴요.
모든 칸에 일을 채우는 것이 성실한 계획은 아니라는 점을 저에게도 계속 상기시키고 있습니다.

가정해서 큰 출시를 마친 다음 주를 떠올려 봅시다.
바로 다음 과제를 던지면 팀은 숨 돌릴 틈이 없어요.
대신 첫 이틀은 밀린 문서 정리와 돌아보기에 쓰고, 그다음에 새 과제를 여는 식으로 쉼표를 넣어 둡니다.
쉬는 시간이 아깝다는 걱정이 들 때도 있지만, 쉼 없이 달린 팀은 실수가 늘어서 결국 더 오래 걸리더라고요.

 

정리하면 지휘자에게서 배운 것은 세 가지입니다.
소리를 직접 내지 않고 합을 만드는 것, 박자를 먼저 정하는 것, 전체를 듣고 쉼을 설계하는 것입니다.
아직 서툴러서 말처럼 되지 않는 날도 많아요.
제가 손을 놓아도 팀이 굴러가는 순간이 오면 그때가 잘 이끈 것일까요.

아니면 필요한 순간에 개입하는 감각이 더 중요할까요.
이 질문은 다음 프로젝트에서 더 천천히 확인해 보려고 합니다.