원문

번역

No, I don’t want to manage people (at least not right now). But I also don’t want to stunt my career growth. Can we stop conflating management with career progression?

아니요, 적어도 지금은 사람들을 관리하고 싶지 않습니다. 하지만 제 커리어 성장을 방해하고 싶지도 않아요. 관리와 커리어 발전을 혼동하지 않을 수 있을까요?

“How big’s your company now? How big’s your team?”

"지금 회사 규모가 얼마나 되나요? 팀 규모는 얼마나 되나요?"

Often, professional success is weighed by the size of the team one manages.Thankfully, in the tech industry, it’s increasingly common for companies to define two separate career tracks: Individual Contributor (IC) & Manager/Leadership (e.g. Google, Facebook, Square, etc.). These distinct paths are most commonly seen in the context of engineering levels, where engineers have the option to choose a track based on their interests and skills. Keeping separate/parallel tracks helps to dispel the perception of people-management as the only path to success. The two track system formally acknowledges that one need not manage a team of people or build an empire in order to advance in one’s career. As an IC, or Individual Contributor, one can climb the same number of rungs…but on a parallel and no less important ladder.

종종 커리어의 성공 여부는 자신이 관리하는 팀의 규모에 따라 결정되는 경우가 많습니다. 다행히도 기술 업계에서는 두 가지 커리어 트랙을 정의하는 회사가 점점 더 많아지고 있습니다: 개인 기여자(IC)와 관리자/리더십(예: Google, Facebook, Square 등). 이러한 구분된 경로는 엔지니어가 자신의 관심사와 기술에 따라 트랙을 선택할 수 있는 엔지니어링 레벨에서 가장 흔히 볼 수 있습니다. 분리/병렬 트랙을 유지하면 인력 관리만이 성공의 유일한 길이라는 인식을 불식시키는 데 도움이 됩니다. 두 가지 트랙 시스템은 커리어를 발전시키기 위해 팀을 관리하거나 제국을 건설할 필요가 없음을 공식적으로 인정합니다. IC(개인 기여자)로서 같은 수의 사다리를 오를 수 있지만, 그보다 더 중요한 사다리를 오를 수 있습니다.

As a Product Manager, I’ve worked closely with many well-respected, senior IC engineers who led by influence, through their technical expertise and who worked on challenging projects with significant scopes and immense complexity. I have seen some senior IC engineers report to junior Engineering Managers (EMs) with far fewer years of work experience. Because the Engineering IC track is well established, people understand that IC and EM are different types of roles, neither one inherently better. Reporting relationships are largely independent of the seniority of IC engineers or engineering managers.

제품 관리자로서 저는 기술 전문성을 바탕으로 영향력을 발휘하고 상당한 범위와 엄청난 복잡성을 가진 도전적인 프로젝트를 수행한 존경받는 많은 선배 IC 엔지니어들과 긴밀히 협력해 왔습니다. 저는 몇몇 시니어 IC 엔지니어가 경력이 훨씬 적은 주니어 엔지니어링 매니저(EM)에게 보고하는 것을 본 적이 있습니다. 엔지니어링 IC 트랙이 잘 확립되어 있기 때문에 사람들은 IC와 EM이 서로 다른 유형의 역할이며, 어느 쪽이 본질적으로 더 낫지 않다는 것을 이해합니다. 보고 관계는 IC 엔지니어나 엔지니어링 관리자의 연차와는 거의 무관합니다.

I love the two-track system because it expects that managers deliberately choose to manage. How many of you have colleagues and friends who’ve suffered from bad managers? Have you suffered from a bad manager? Maybe you’ve even been a bad manager. And yes, the adage is often true: people leave managers, not companies. When a manager is assigned exclusively because the person has performed well as an IC or worse, because the person has been at the company for a long time, the team is going to have a bad time.

저는 관리자가 의도적으로 관리직을 선택할 것으로 기대하기 때문에 투트랙 시스템을 좋아합니다. 여러분 중 나쁜 관리자로 인해 고통받은 동료와 친구가 몇 명이나 있나요? 여러분도 나쁜 관리자로 인해 고통받은 적이 있나요? 어쩌면 여러분도 나쁜 관리자가 되어 보셨을지도 모릅니다. 사람은 회사를 떠나는 것이 아니라 매니저를 떠난다는 격언은 종종 사실입니다. 단순히 IC로서의 성과가 좋았다는 이유만으로, 또는 회사에 오래 근무했다는 이유만으로 관리자가 선임되면 팀은 힘든 시간을 보내게 됩니다.

Many take the responsibility of people management for granted, not fully realizing the necessary skills and commitment required of such a role. Sometimes, even when that gravity is recognized, some are simply not (yet?) cut out to lead even if they wish to be. Finally, some may not desire to be managers even if they have natural talent for it.

많은 사람들이 인사 관리의 책임을 당연한 것으로 여기고, 그러한 역할에 필요한 기술과 헌신을 충분히 깨닫지 못합니다. 때로는 그 중요성을 인식하더라도 리더가 되고 싶어도 아직은 리더가 될 준비가 되지 않은 경우도 있습니다. 마지막으로, 타고난 재능이 있어도 관리자가 되고 싶지 않은 사람도 있을 수 있습니다.

By making the decision deliberate, only those who choose to be managers are granted the responsibility. Engineers are expected to perform research to decide which path they want to take — they seek to understand the roles deeply, ensuring that they’re seeking challenges that are aligned to their capabilities and aspirations. Ideally, if they decide to pursue management, they are similarly expected to develop skills necessary to be thoughtful and effective people managers. Managers should be evaluated with criteria that measures and optimizes for behaviors that build and maintain successful teams.

신중하게 결정함으로써 관리자가 되기로 선택한 사람에게만 책임이 부여됩니다. 엔지니어는 자신이 가고자 하는 길을 결정하기 위해 조사를 수행해야 하며, 역할을 깊이 이해하고 자신의 역량과 열망에 부합하는 도전을 추구해야 합니다. 이상적으로는 관리직으로 진로를 결정한 경우에도 마찬가지로 사려 깊고 효과적인 인사 관리자가 되기 위해 필요한 기술을 개발할 것으로 기대됩니다. 관리자는 성공적인 팀을 구성하고 유지하는 행동을 측정하고 최적화하는 기준으로 평가받아야 합니다.

Does the two track system work for Product Managers?

투 트랙 시스템이 제품 관리자에게도 적용되나요?

Theoretically, this two-track system can also apply to product management. My understanding is that some larger companies do indeed have very senior IC Product Managers (PMs). However, the path to becoming a senior level “IC” Product Manager seems not to be as well established for the PM discipline. I have not personally witnessed a case where a senior PM maintained his/her IC status without hitting the proverbial glass ceiling. In almost all cases of which I’m aware, senior PMs were eventually made to manage a team of Product Managers — sometimes by choice though more often, by not-so-subtle coaxing.

이론적으로 투 트랙 시스템은 제품 관리에도 적용될 수 있습니다. 제가 알기로는 일부 대기업에는 실제로 매우 고위급 IC 제품 관리자(PM)가 있는 것으로 알고 있습니다. 그러나 고위급 "IC" 제품 관리자가 되기 위한 경로는 PM 분야에서는 잘 정립되어 있지 않은 것 같습니다. 저는 개인적으로 시니어 PM이 유리 천장에 부딪히지 않고 IC 지위를 유지한 사례를 본 적이 없습니다. 제가 아는 거의 모든 사례에서 선임 PM은 결국 제품 관리자 팀을 관리하게 되었으며, 때로는 자의에 의한 경우도 있지만 그보다는 은근한 회유에 의한 경우가 더 많았습니다.

Up until recently I was the most senior IC Product manager at Square. To get there, I fought a long and arduous battle. Every year, leadership would ask me if I would manage others. People often assumed that the more junior PMs that I worked with and mentored were my direct reports. When I would dispel that assumption, people would look at me sideways and ask, “How are you so senior and have no direct reports?” Even when I interviewed for new PM roles, the interviewers would ask me why I hadn’t yet managed a team of Product Managers. “Grrr..” I would think, “No senior IC engineer would be asked to defend being an IC!”

저는 최근까지 Square에서 가장 고위급 IC 제품 관리자였습니다. 그 자리에 오르기까지 저는 길고 힘든 싸움을 벌였습니다. 매년 경영진은 저에게 다른 사람들을 관리할 수 있는지 물어보곤 했습니다. 사람들은 종종 제가 함께 일하고 멘토링한 후배 PM들이 제 직속 상사라고 생각했습니다. 제가 그런 가정을 깨뜨리면 사람들은 저를 옆으로 쳐다보며 "어떻게 그렇게 선배인데 직속 부하가 없죠?"라고 묻곤 했습니다. 새로운 PM 역할을 맡기 위해 면접을 볼 때도 면접관들은 왜 아직 제품 관리자 팀을 관리하지 않았는지 물어보곤 했습니다. "으으..." 저는 "선임 IC 엔지니어가 IC라고 변명할 사람은 없겠지!"라고 생각하곤 했습니다.

So….really, why don’t you want to manage a team?

그래서...... 정말 팀을 관리하고 싶지 않은 이유는 무엇인가요?

I have never been a 100% dedicated people manager, but for several years I did manage a team of four. I split my time between being a manager and being an IC, which required significant cognitive switching costs. I found that when I worked on products that required my full attention, it was tough to give my best to the products and to simultaneously take good care of my people. I didn’t like choosing between apples and oranges or sacrificing my personal life and sleep in order to do a good job. I told myself that I would only manage a team if the conditions allowed me to be an accessible and available manager who could dedicate ample time to my direct reports (btw this view is corroborated by Google’s Project Oxygen results). And to be honest, even that idealistic scenario never sounded especially appealing compared to the type of products I was product managing at the time, an observation which felt to me like a sound reason NOT to aspire to management at the same time.

저는 100% 전담 인력 관리자가 된 적은 없지만 몇 년 동안 4명으로 구성된 팀을 관리한 적이 있습니다. 관리자와 IC로 시간을 나눠서 일했는데, 인지적 전환에 상당한 비용이 들었습니다. 전적으로 집중해야 하는 제품을 다룰 때는 제품에 최선을 다하는 동시에 직원들을 잘 돌보는 것이 힘들다는 것을 알았습니다. 저는 일을 잘하기 위해 사과와 오렌지 중 하나를 선택하거나 개인 생활과 수면을 희생하는 것을 좋아하지 않았습니다. 저는 제 직속 상사에게 충분한 시간을 할애할 수 있는 접근성과 가용성을 갖춘 관리자가 될 수 있는 조건이 갖춰진 경우에만 팀을 관리하겠다고 스스로에게 다짐했습니다(이 생각은 Google의 Project Oxygen 결과를 통해 입증되었습니다). 솔직히 말해서, 당시 제가 관리하던 제품 유형에 비하면 이상주의적인 시나리오조차도 그다지 매력적으로 들리지 않았고, 이 점이 제가 관리직에 도전하지 말아야 할 타당한 이유처럼 느껴지기도 했죠.

What was clear was that I really enjoyed being at the grassroots and in the weeds of projects, working directly with engineers, designers, and cross-functional partners. I thrived when working on new, complex, and increasingly broadly-scoped products that challenged me and allowed me to develop into a stronger product manager. For me, management was not the clearest path to achieving these things.

분명한 것은 엔지니어, 디자이너, 여러 부서의 파트너와 직접 협력하면서 프로젝트의 풀뿌리와 잡초 속에서 일하는 것이 정말 즐거웠다는 점입니다. 새롭고 복잡하며 범위가 점점 더 넓어지는 제품을 작업할 때 제게 도전이 되었고 더 강력한 제품 관리자로 성장할 수 있었습니다. 저에게 관리직은 이러한 목표를 달성하는 가장 확실한 길은 아니었습니다.

While not managing (formally), one of my favorite experiences was mentoring several PMs and aspiring PMs when they sought my guidance. I believe that this relationship allowed me to be more genuine and honest, without the complexity of reporting lines. Ironically perhaps, I was in those situations, better positioned than most of the managers to share relevant experiences, best practices, guides/templates, and general career advice with other PMs. Not only having been in their shoes before, but being currently in their shoes seemed to lend my perspective significant credibility.

공식적인 관리직은 아니었지만, 제가 가장 좋아했던 경험 중 하나는 여러 PM과 PM 지망생들이 제 지도를 요청할 때 멘토링을 해준 것이었습니다. 이러한 관계를 통해 복잡한 보고 라인 없이도 더 진솔하고 정직할 수 있었다고 생각합니다. 아이러니하게도 저는 그런 상황에 처해 있었기 때문에 대부분의 관리자보다 관련 경험, 모범 사례, 가이드/템플릿, 일반적인 커리어 조언을 다른 PM들과 공유할 수 있는 더 나은 위치에 있었을지도 모릅니다. 이전에 그들의 입장이 되어본 적이 있을 뿐만 아니라 현재 그들의 입장이 되어 있기 때문에 제 관점에 상당한 신뢰성이 부여되는 것 같았습니다.

As a PM, I’ve especially enjoyed working on purpose-organized product teams, where several PMs would come together for a specified duration to work on a large and complex product. Not only did I have a meaty set of goals to run towards, I could also tap into my nurturing side. I wanted to ensure that people could grow and learn while achieving objective success. Being a team player without undue hierarchy allowed me to connect with others on a personal level, and to avoid the politics of career advancement.