나는 현재 이직을 앞두고 있다. 이직할 회사에는 Technical Program Manager(이하 TPM으로 칭함) 라는 포지션으로 가게 된다. 처음에는 TW(테크니컬 라이터) 포지션으로 입사할 줄 알았는데 변경됐다. 몇 차례 인터뷰를 거친 후 뜻밖에도 TPM 포지션으로 일해볼 생각이 있냐는 제의를 받았다.
생소한 직무명에 망설였고, 정말 제가 잘 할 수 있을 것으로 본 거냐고 몇 번이고 되묻기도 했다. 그러다가 응하게 된 이유는, 어차피 이직 자체도 굉장한 도전을 하는 상황이니 기왕 도전하는 거 싹 다 도전해보자! 라는 생각이었다. 문제는 여전히 TPM이 어떤 직무인지 잘 모르겠다는 것. 뭘 알아야 죽을 쑤건 밥을 짓건 할텐데. 포지션 제안 받을 때에 대충 설명을 들었지만 충분치 않았다. 그래서 여가 시간을 활용해 조사를 좀 해봤고, 그 결과를 이 자릴 빌어 정리해보려고 한다.
구글에서 TPM을 검색하면 우리나라에서는 대표적으로 쿠팡 Coupang이 등장한다. 쿠팡 채용 페이지 뿐 아니라 다른 채용 사이트에 올라온 TPM 공고를 보면 세부 내용이 다소 제각각인 면이 있는데, 공통 분모를 뽑아보면 다음과 같다.
- 여러 프로그램, 여러 팀 혹은 여러 프로덕트에 걸친 기술적 이슈(요구사항, 디펜던시 포함)를 관리한다.
- 기술적 프로그램 혹은 프로세스 관리와 개선을 할 수 있어야 한다.
- 업무에 병목이 되는 이슈를 파악하고 리스크 관리를 할 수 있어야 한다. (2번 업무의 일부라고 볼 수 있다.)
- 개발팀과 기술 이슈에 대해 의사소통 가능한 수준의 기술적 지식을 갖춰야 한다.
- 프로젝트 관리 경험과 능력이 필요하다.
- 팀 간 협업 및 커뮤니케이션 능력이 필요하다.
- 비즈니스 문제를 해결하기 위해 어떻게 기술을 활용할지 알아야 한다.
이렇게 보면 PM 혹은 PO와의 큰 차이가 없어보인다. 다만 업무에서 기술 사이드에 보다 밀착된 느낌을 받을 뿐.
하지만 이는 내 착각이었음을 다른 글을 보고 알게 됐다. 그 글은 이제 곧 소개하겠다.
보다 자세한 내용을 알고자 영어로 검색을 했다. 다행히 꽤 괜찮은 검색 결과를 얻었다. What does a Technical Program Manager do? 라는, 내가 궁금한 것을 묻고 있는 인터뷰를 발견한 것! 2년 전의 인터뷰이므로 지금은 TPM의 RnR이 변경되었을 수 있지만 TPM이라는 직무가 세상에 나온지 얼마 안될 때의 시점으로 보여 개념을 잡기에는 충분해보였다. 나와 같은 사람들에게 도움이 될 수 있을까 싶어, 인터뷰 중 일부를 인용 및 번역해보았다.
질문의 경우 축약해서 번역하고 답변 번역에 치중했으며, 일부 의역이 있습니다. 또한 번역에 오류가 있을 수 있는 점을 양해 부탁드립니다.
Table of Contents
TPM의 역할은 무엇인가?
Patrick: You’re in this role, “Technical Program Manager”. How do you describe this role to other people?
Meysam: This role manages multiple areas at the same time and mostly focused on technical projects. This means the person playing the role should have a technical background but also have great project management skills to manage programs of work. This is a very complex role requiring many interdisciplinary skills. This role coordinates projects across many teams who all have stakes in a technical project. This person requires a technical background because they need to understand and traverse technical dependencies, work very closely with deeply technical people and at the same time manage the roadmap and often non-technical stakeholders to ensure teams are on track.
이 역할은 동시에 여러 영역을 관리하며 주로 기술 프로젝트에 중점을 둡니다. 이것은 즉, TPM의 경우 기술적인 배경 지식을 가져야할 필요가 있고, 뿐만 아니라 작업 프로그램을 관리할 수 있는 훌륭한 프로젝트 관리 스킬을 가져야만 한다는 걸 뜻합니다. 박학다식할 필요가 있는 복잡한 역할인 거죠. TPM은 여러 팀이 연관된 프로젝트들을 조정해야 하는데, 이 복수의 팀들은 기술 프로젝트에 이해관계가 있다는 특성이 있습니다. TPM을 하는 사람은 기술적인 배경지식을 요구합니다. 기술적인 디펜던시를 이해 및 고찰해야 하고, 기술 인력과 매우 밀접하게 일해야 하고, 동시에 팀들의 업무가 순조로이 진행되도록 로드맵 및 비기술 이해관계자를 관리해야 하기 때문입니다.
Product Manager와의 차이점
Patrick: If I understand it right, this is quite different from a typical product manager role because the nature of the initiative is often deeply technical. In the last example, migrating environments has business value but the topic is deeply technical, requiring a good understanding of infrastructure, configuration and technical dependencies. This is also classically different from a product manager who works with a single team because a change in environment touches almost all teams. Where a product manager may have zero external team dependencies or a few, these projects tend to touch many.
제가 이해한 게 맞다면, 이는 전형적인 프로덕트 매니저 역할과 꽤 다르군요. 업무 성격이 대부분 매우 기술적이예요. 마지막 예시의 마이그레이션 작업 같은 경우 사업적인 가치를 갖고 있지만 매우 기술적이예요. infrastructure, configuration 그리고 기술적인 디펜던시에 대해 잘 이해하고 있어야 하기 때문이죠. 이는 또한 단일 팀하고 일하는 고전적인 프로덕트 매니저와도 다르군요. 거의 모든 팀과 접촉한다는 점이 달라요. 프로덕트 매니저는 0개 혹은 기껏해야 소수의 팀과 의존적인 관계가 있지만 TPM이 하는 프로젝트들은 여러 팀과 관련이 있군요.
TPM에게 필요한 역량?
Patrick: What do you think is required to be a good TPM?
Meysam: I believe this is a relatively new role in the market. At least compared to both project and product management. Our industry seems to need this role because you need to have a very strong technical background to understand what you are managing. You need this deep understanding of technical topics, so you can dive into areas where there may be hidden assumptions or complexity to uncover. At the same time, you need someone who can also interpret or translate that complexity into an easy-to-understand format to help leaders and managers make better decisions.
It’s not enough to be a Product Manager or a Technical Product Manager because you need skills to manage multiple teams and stakeholders. At the same time, a Project Manager is not enough because you also need to have a deep understanding of the area you’re managing. I fell into this role because there are many companies with this need and they’re looking for people with this experience.
TPM은 시장에서 비교적 새로운 역할이라고 봅니다. 최소한 프로젝트 관리 및 프로덕트 관리와 비교해서 말이죠. 관리 대상을 이해하려면 매우 강력한 기술적 배경지식을 가져야 할 필요가 있기 때문에 업계에서는 이러한 역할이 필요하다고 생각해요. 어딘가에 감춰진 가설이나 복잡성을 발견하려면 이러한 기술적인 토픽의 깊은 이해가 필요합니다. 또한 리더 및 매니저들이 더 나은 결정을 할 수 있도록 저러한 복잡성을 이해하기 쉬운 포맷으로 해석 혹은 번역할 수 있는 누군가가 필요할 겁니다.
여러 개의 팀과 이해관계자를 관리할 스킬이 필요한 경우 프로덕트 매니저나 테크니컬 프로덕트 매니저에게 그러한 역량을 요구하기는 어렵습니다. 마찬가지로, 관리 대상에 대한 깊은 이해가 필요한 경우 이러한 니즈는 프로젝트 매니저로 충족시키기 어렵습니다. 많은 회사들이 이러한 경험을 가진 사람을 필요로 하고 또한 찾고 있기 때문에 저는 이 역할에 푹 빠졌습니다.
TPM의 차별화 포인트?
Patrick: How would you describe the main value add for this role? Why can’t a team, or existing roles take care of this?
Meysam: It’s a good question. I’m sure everyone can take care of some aspect. Let’s take a role of a Product Manager. That person is focused very much on a product area, or a piece of software they are delivering. They often don’t have time to manage technical integrations of that product. A TPM on the other hand doesn’t focus on a single area, but ensures a technical project moves forward. They use their technical background to ensure all dependencies and technical integrations move forward for the project, and not just a single product area. A TPM create a project roadmap based on this understanding and also communicates this to management to show milestones in a much easier to read way. A TPM is able to break down very complex technical projects, abstract technical complexity and can present this information to non-technical stakeholders who need to be informed and made aware of risks and trade-offs as a project progresses.
모든 사람은 일부 측면만 볼 수 있다고 생각합니다. 프로덕트 매니저를 볼까요? 그 사람은 프로덕트의 어떤 영역 혹은 출시하하는 소프트웨어의 일부에 매우 집중합니다. 그들은 대개 그 프로덕트의 기술적인 통합을 관리할 시간이 없죠. 반면 TPM은 단일 영역에 집중하지 않고 기술적인 프로젝트가 진행되게 하죠. 그들은 단지 하나의 프로덕트 영역이 아니라, 프로젝트에 대한 모든 디펜던시와 기술적인 통합이 진행되도록 하고자 그들의 기술적인 배경지식을 사용합니다. TPM은 이러한 이해를 바탕으로 프로젝트 로드맵을 만들고 또한 더 읽기 쉬운 방법으로 마일스톤을 보여주고자 매니지먼트와 로드맵에 대해 커뮤니케이션 합니다. TPM은 매우 복잡한 기술적인 프로젝트, 추상적인 기술적 복잡도를 분석할 수 있고, 프로젝트가 진행됨에 따라 위험과 절충안을 알고 있어야 하는 비기술적 이해관계자에게 이러한 정보를 제공할 수 있습니다.
테크 리더 및 엔지니어링 매니저와의 차이점?
Patrick: How would you describe the difference between a TPM and maybe a Tech Lead and Engineering Manager?
Meysam: Tech Leads are mostly focused on leading technical topics such as design and architectural decisions and enabling and aligning engineers within their team. Engineering Managers support the team, by creating the right environment for teams to deliver what they need and grow. A TPM does not focus on these two areas. Of course, a TPM can provide 1–1 feedback or give ideas on direction but that’s not their strong focus. Their role is really about connecting the dots. Particularly across teams where a technical initiative is not a team’s particular focus. A key responsibility of a TPM is to also drive the roadmap of that project, to see it delivered end-to-end.
Patrick: Let me try to summarise my understanding from you described. A tech lead is driving the technical solution with the team for a particular product area. The engineering manager is working with that team to help grow people, ensure they have the right capacity for planning and to optimise the flow of development. You are working across product teams to coordinate dependencies, keep track of the critical path, to expose risk to the overall roadmap and to drive decisions around priorities that come in conflict with a cross-team wide versus a product team centric set of priorities.
테크 리더는 설계 및 아키텍처에 대한 결정 및 팀 내에 있는 엔지니어들을 지원하고 조정하는 등의 대표적인 기술 토픽에 대개 초점을 둡니다. 엔지니어링 매니저들은 팀원들이 필요로 하는 것을 제공하고 성장하는 것을 돕기 위한 좋은 환경을 만들면서 팀을 지원하죠. TPM은 이러한 두 영역에 관심이 없습니다. 물론 TPM은 1대1 피드백을 제공하거나 방향성에 대한 아이디어를 줄 수 있지만 그게 TPM에게 있어 주요 관심사는 아닙니다. TPM의 역할은 사실상 점들을 연결하는 것입니다. 어떤 팀의 특별한 관심이 아닌, 기술적인 이니셔티브가 있는 팀들 사이가 특히 그렇죠. 또한 TPM의 핵심 책임은 end-to-end로 전달된 것을 볼 수 있도록 프로젝트의 로드맵을 주도하는 것입니다.
제가 이해한대로 당신의 말을 요약해보겠습니다. 테크 리더는 특정 프로덕트 영역에서 팀과 함께 기술적인 해결책을 주도합니다. 엔지니어링 매니저는 어떤 팀과 일하면서 그 팀원들이 성장하도록 돕고, 계획에 적합한 역량을 갖추고, 개발 흐름을 최적화하도록 합니다. TPM은 디펜던시를 조정하고, 중요한 경로를 추적하고, 전체적인 로드맵에 위험을 노출하고, 프로덕트 팀 중심의 우선 순위 집합에 비해 팀 간 전체와 충돌하는 우선 순위에 대한 결정을 내리기 위해 프로덕트 팀들을 아우르며 일합니다.
TPM에게 가장 필요한 세 가지 스킬을 꼽는다면?
Patrick: What do you think are the top three skills needed for the role?
Meysam: The first one is having the expertise in the technical domain. If you don’t understand the complexities of this, you cannot drive conversations, or you will be blind to certain types of risks. It’s very helpful to have a solid background in engineering and perhaps even the domain in which you’re managing the technical project. The second skill is strong communication skills, as we’ve just talked upon. The last one is really strong leadership skills. Remember that you don’t often have a team — you need to rely on others. So you need to use leadership skills to lead a topic, generate buy in from others and to move the topic forward. You need to lead people to own their own topics because the success of your projects is dependent on how well they implement it.
첫 번째는 기술적인 도메인에 대한 전문성을 갖고 있어야 한다는 것입니다. 만약 당신이 복잡성을 이해하지 못한다면 대화를 주도할 수 없거나 특정 유형의 위험성을 알 수 없을 것입니다. 엔지니어링 및 기술 프로젝트를 관리하고 있는 도메인에 대한 탄탄한 배경 지식이 있으면 매우 도움이 됩니다. 두 번째 기술은 방금 이야기 한대로 강력한 커뮤니케이션 스킬입니다. 마지막은 정말 강력한 리더십 기술입니다. 당신은 대개 팀이 없다는 걸 명심하세요. 다른 사람에게 의존해야 합니다. 따라서 리더십 기술을 사용하여 토픽을 주도하고, 다른 사람의 동의를 얻어 토픽을 진행할 수 있게끔 해야 합니다. 프로젝트의 성공은 프로젝트를 얼마나 잘 구현하느냐에 달려 있으므로 사람들로 하여금 토픽이 자신들의 일인 것을 인식하도록 이끌어야 합니다.
TPM 지망생에게 조언을 해준다면?
Patrick: What advice would you give to people considering the TPM role?
Meysam: Apart from requiring the skills mentioned above, people should prepare themselves for this being a very high traffic role. This means having many conversations, often tough conversations with many people across an organisation. It depends on the complexity of the program, the size of the company and structure but the role itself requires a lot of adaptability. My advice for dealing with this is ensuring you have a good work-life balance for coping with this.
위에서 언급한 스킬들 외에도 자신의 업무 트래픽이 매우 높을 수 있다는 점을 대비해야 합니다. 이는 조직 전체에서 많은 사람들과 많은 대화를 한다는 의미이고, 종종 힘든 대화를 나눠야 할 수 있습니다. 프로그램의 복잡성, 회사의 규모 및 구조에 따라 다르지만 역할 자체에는 많은 융통성이 필요합니다. 이 문제를 해결하기 위한 저의 조언은 일과 삶의 균형을 잘 유지하라는 것입니다.
이미 TPM을 하고 있는 사람에게 조언을 해준다면?
Patrick: If someone is already in this role, what advice would you give them?
Meysam: If you’re in this role, you’ll realise it requires a lot of context switching across people, teams and projects. You shouldn’t look at this role like you do as an engineer — with a binary perspective. It’s rare you have a day with a clear success or failure. You’re there to enable others to drive a topic forward on its milestones. Change your mindset from execution to enablement. Instead of doing, you will need to talk, communicate, lead and enable people from many different perspectives, teams and roles to lead a project to success.
이 역할을 맡고 있다면 사람, 팀 그리고 프로젝트 간에 많은 컨텍스트 스위칭이 필요하다는 것을 알겁니다. 엔지니어처럼 0 아니면 1과 같은 관점으로 이 역할을 바라보면 안됩니다. 성공과 실패가 분명한 하루를 보내는 경우는 드뭅니다. 다른 사람들이 마일스톤에 따라 토픽을 진행시킬 수 있도록 도와줍니다. 직접적인 실행이 아닌 다른 사람을 성공하게 하는 방향로 당신의 마음가짐을 변경하세요. 다양한 관점, 팀 및 역할을 가진 사람들이 프로젝트를 성공시킬 수 있도록 이야기하고, 커뮤니케이션 하고, 이끌고, 능력을 줘야 합니다.
요약하자면 결국 위에 적었던 공통 분모와 크게 다르지 않은 것 같다.
- 특정 팀과 하는 일이 아닌, 여러 팀에 걸쳐서 일을 한다. 따라서 큰 그림을 그릴 수 있어야 한다.
- 일이 잘 진행될 수 있게 돕는 역할이며, 진행을 방해할 수 있는 기술적 이슈를 발견하는 능력이 중요하다.
- 어떤 기술 이슈를 해결해야 할지 파악하고, 그 이슈가 일부 팀에는 당장 문제가 되지 않더라도 해결하도록 설득할 수 있어야 한다.
- 기술 직군이 아닌 사람에게 기술적 이슈를 잘 이해할 수 있도록 설명할 수 있어야 한다.
약간 앞날이 아득해지는 느낌이 온다. 새 회사 출근 전에 기술 서적이나 리더십 관련 책 등을 읽으며 공부를 좀 해야 겠다는 생각이 든다. ㅎㅎ
글을 마무리하며 마지막으로, TPM에 대해 조사하다가 추가로 찾은 자료가 있어 공유한다.
이건 한글이라 내가 굳이 별도로 정리할 필요는 없을 것 같고, 직접 찾아가서 읽는 걸 추천한다. 정리가 잘 되어있어 이해하기 쉽다. 직접적으로 TPM이라고 언급하진 않고 프로그램 매니저 라고 칭하는데, 위에서 정리한 TPM에 대한 내용과 크게 다르지 않은 듯 하다.
