특정 리더에게 오랜 시간 보고하거나 명확한 목표를 가진 조직에서 일해온 관리자들에게는 자신도 모르게 기술 격차가 생기기 쉽습니다. 이는 보통 그 기술들이 자신이 성장한 환경에서 특별히 중요하지 않았기 때문입니다. 기존 기술에 대해 매우 자신감을 갖고 새로운 조직에 들어갔을 때, 다른 역량이 요구되면 곧바로 어려움을 겪을 수 있습니다. 

이러한 상황은 여러 가지로 나타날 수 있지만, 여기서 논의하고 싶은 것은 상명하달식 계획(“조율 중심 역할”)으로 운영되는 조직에서 성장한 관리자가 충분히 고위직에 오르거나, 상향식 조직에서 리더십을 발휘해야 하는 상황에 처했을 때입니다(“리더십 중심 역할”).

조율(Orchestration) VS 리더십

문제를 해결하는 구성 요소를 여러 가지 방식으로 나눌 수 있으며, 이것이 완벽한 방법이라고 말하는 것은 아니지만, 팀의 작업을 지시하는 데 중요한 여섯 가지 요소는 다음과 같습니다.

1. 문제 발견: 해결할 문제 식별
2. 문제 선택: 이해관계자와 식별된 문제에 대한 합의
3. 해결책 발견: 선택된 문제에 대한 잠재적 해결책 식별
4. 해결책 선택: 선택한 접근 방식에 대한 이해관계자와의 합의
5. 실행: 선택된 해결책 구현
6. 지속적인 수정: 계획을 발전시키면서 팀과 이해관계자 간의 일치 유지

조율 중심의 관리 역할에서는 이러한 단계의 후반부에만 집중할 수 있습니다. 리더십 중심의 관리 역할에서는 모든 여섯 단계를 수행합니다. 조율 중심 역할만 경험한 사람들은 이러한 모든 작업을 수행해야 한다는 것을 전혀 모를 수 있습니다. 따라서, 작업을 수행하는 데 기술 격차가 있을 수 있지만, 더 중요한 것은 실제로 해야 할 작업이 있다는 인식 격차입니다.

현재 리더십 중심의 상황을 충분히 이해하지 못하는 조율 중심 관리자를 식별하는 몇 가지 방법은 다음과 같습니다.

• 우선순위를 "첫 번째 해결책"으로 여긴다. 문제나 접근 방식을 변경할 수 없을 때, 우선순위 설정은 가장 유용한 도구 중 하나가 됩니다.
• 제시된 문제와 해결책을 그대로 수용한다. 이해관계자가 무언가를 요청하면, 우선순위에 대한 질문이 주를 이루며, 프로젝트가 실제로 실행할 가치가 있는지, 대안적인 접근 방식 제안에 대한 질문은 없습니다. 요청이 타당한지에 대한 질문 습관이 없으며, 이는 이해관계자나 더 고위의 기능적 리더십에 맡겨집니다.
• 스프린트 계획 및 프로세스에 집중한다. 문제와 접근 방식이 고정된 상태에서 팀을 방해로부터 보호하는 것이 가장 가치 있는 도구 중 하나입니다. 스프린트 주기에 엄격하게 운영하는 것(각 스프린트 시작 시에만 계획 변경)은 강력한 기법입니다.

이러한 것들은 리더십 중심 역할에서도 여전히 가치가 있지만, 반드시 가장 가치 있는 것은 아닙니다.

리더십 중심 역할 수행

리더십 중심 역할에 있는 관리자는 더 확장된 역할이기 때문에 학습 곡선이 가파릅니다. 그러나 오직 오케스트레이션 에만 집중하는 고위 엔지니어링 리더십 역할은 없다는 것을 인식하는 것이 중요합니다. 이 리더십 스타일을 배우지 않으면 중간 수준의 역할에 머물게 됩니다 (조율 중심의 조직에서도 마찬가지입니다).

더욱이, 기술 산업은 일반적으로 2010년대에 조율 중심 역할에 과도하게 투자했다고 믿습니다. 결과적으로, 많은 회사들이 이러한 역할을 없애고 다음 세대의 회사에서 유사한 역할이 생성되는 것을 방지하고 있습니다. 이 변화는 LLMs에 의해 가져온 생산성 증가에 기인한다는 이야기가 널리 퍼져 있지만, 저는 그 관계에 대해 회의적입니다. 이 변화는 LLMs가 두드러지기 전부터 이미 진행 중이었습니다.

리더십 중심 역할의 학습 곡선을 겪고 있는 사람들에게 드리는 조언은 다음과 같습니다.

1.당신의 직무 핵심 루프를 네 단계로 생각하세요.

1. 팀이 작업해야 할 문제를 식별합니다
2. 그 문제를 해결할 목적지를 결정합니다
3. 팀, 이해관계자, 경영진에게 팀이 그 목적지에 도달하기 위해 따를 경로를 설명합니다
4. 그 경로를 성공적으로 걷고 있다는 증거를 제공하는 데이터와 이야기를 전달합니다

이 네 가지를 수행하지 않으면, 당신은 자신의 역할을 완전히 수행하고 있지 않은 것입니다. 사람들이 당신이 일부를 잘한다고 말하더라도 말입니다. 마찬가지로, 승진하거나 더 많은 인원을 확보하고 싶다면, 이 네 단계가 그 길입니다 (이전에 How to get more headcount에서 이에 대해 다루었습니다).

2. 팀에게 우선순위와 해결할 문제를 요청하세요. 하향식 프로젝트를 발굴하는 것은 당신의 역할에서 중요한 부분입니다. 상향식 및 측면 우선순위만 기다리면, 핵심 루프의 첫 번째 단계를 수행하지 않는 것입니다.

이 기대를 놓치기 쉽습니다. 당신에게는 보이지 않지만, 다른 사람들에게는 명백하기 때문에 말할 필요가 없다고 생각합니다. 확신이 서지 않으면 물어보세요.

3. 리더십 체인이 팀의 핵심 루프를 운영하고 있다면, 그것은 당신이 스스로 운영할 수 있는 증거가 부족하기 때문입니다. 이는 나쁜 신호입니다. 조율 중심 역할에서 "일상적인 업무"가 리더십 중심 역할에서는 고군분투하는 관리자를 나타냅니다.

4. 핵심 루프를 따라 프로젝트의 우선순위를 정하세요. 팀에 주요 문제가 있고 그 문제가 왜 해결되지 않는지 궁금하다면, 그것은 당신의 책임입니다. 리더십 중심 역할에서는 팀의 작업을 어떻게 구성할지 다른 사람이 알려주지 않습니다. 당신이 일을 잘못한다고 생각하지 않는 한 말입니다.

5. 적절한 문제와 해결책을 선택하는 것이 가장 높은 레버리지 작업입니다. 아니요, 이것은 제품 관리자나 기술 리드의 일만이 아닙니다. 이것은 당신의 일입니다. 이것은 또한 그들의 일이지만, 리더십은 이것을 올바르게 하는 것이 매우 가치 있기 때문에 겹칩니다.

일반적으로, 이제 당신의 초점은 팀 작업의 효율성이 아니라 효과성입니다. 잘못된 문제에 빠르게 움직이는 것은 가치가 없습니다.

6. 자신의 도메인과 기술을 자세히 이해하세요. 모든 소프트웨어를 작성할 필요는 없지만, 코드베이스를 이해할 수 있음을 검증하기 위해 간단한 풀 리퀘스트를 작성해야 합니다. 모든 제품 요구사항이나 아키텍처 제안을 작성할 필요는 없지만, 작업을 이해하고 있음을 증명하기 위해 가끔 작성해야 합니다.

그렇게 할 수 없다고 느낀다면 괜찮습니다. 그러나 그 격차를 메우기 위해 취할 조치를 긴급히 작성하고 그 계획을 팀과 관리자와 공유해야 합니다. 현재 그들은 당신이 기대에 미치지 못한다고 보고 있으며, 당신이 어떻게 기대를 충족시킬 것인지 알고 싶어합니다.

그 격차를 메울 수 없다고 생각하거나 그것을 메우는 것이 비합리적이라고 생각한다면, 당신은 자신의 역할을 오해하고 있는 것입니다. 일부 조직은 당신이 역할을 오해하는 것을 오랫동안 허용할 수 있지만, 그 역할의 일부를 잘 수행한다면 승진시키지 않으며, 대부분은 고위 리더에게 그것을 용납하지 않습니다.

7. 팀과 교차 기능 이해관계자와의 일치를 경영진과의 일치만큼 중요하게 생각하세요. 경영진이 틀렸고 당신이 그들을 따랐다면, 팀과 이해관계자가 화가 난 것은 당신의 잘못입니다. 당신의 일의 일부는 경영진의 생각을 바꾸는 것입니다.

네. 모든 것을 경영진의 탓으로 돌리는 유형이라면 불공평하게 느낄 수 있습니다. 그러나 여전히 사실입니다: 경영진이 모든 것을 올바르게 하기를 기대하는 것은 많은 것을 이루지 않고 우월감을 느끼는 확실한 방법입니다.

이제 제 관점을 공유했으니, 저는 일부러 약간 극단적으로 접근하고 있음을 인정합니다. 이것을 파악하지 못한 사람들은 논쟁의 여지가 없을 때까지 그 타당성을 강하게 반박하는 경향이 있습니다. 미묘한 차이가 있을 수 있지만, 제 요점이 완전히 무효라고 생각한다면, 관리자와 팀과 직접 대화하여 그들의 기대와 당신이 그것을 충족시키고 있는지에 대해 논의해 보시길 권장합니다.

원문 : Moving from an orchestration-heavy to leadership-heavy management role.