Manager or IC? The Fluidity of Choice in Career Path | 管理者和獨立貢獻者要選哪個 🤔？ 探索如何在這兩種角色間自由轉換
中文請往下
Choosing between a manager and an IC (individual contributor) is a dilemma many in tech grapple with 🤔. I faced the same struggle back in 2020. Consequently, I penned an article titled, The Next Step of Sr. PM — Don’t Be A Manager, in Chinese, which was published on 2021/1/2. This was the inaugural article I published on Medium, and it got featured on Taiwan Tech Orange 🍊. I wrote that piece as an answer to my personal career crossroads at the time.
Answer Updated 🔄
I’d like to revise my answer. Recently, during an online panel discussion about data career paths in Chinese, this topic surfaced once more. A PM, whom I mentor, also finds herself torn over applying for a manager. I believe my insights apply equally to both data and product career paths, especially since the data career ladder can seem more nebulous 🌫. For instance, the title Chief Data Officer came into existence after the Chief Product Officer. A manager or an IC selection remains an evergreen query 🌲.
Embracing a managerial role isn’t a commitment set in stone. It’s a two-way door decision 🚪🚪. So, relax 🍹. Don’t feel overwhelmed by the decision. It’s entirely possible to embrace a managerial position in your current job and revert to an IC role in your subsequent one. Many professionals have treaded this path. Remember, it’s not a lifelong commitment.
The crux lies in maintaining your adaptability and comprehending your fit in both capacities 🔄.
Keep The Flexibility 💪
I recommend Ken Norton’s It’s Time to Fight for a Dual Product Management Career Path. He elucidates these two paths. My take aligns with his:
- An IC dedicates more time to the product 🛠.
- A manager overseeing product managers invests more time in people management 👥.
As an IC, hone your leadership skills, mentor budding colleagues, support your superiors, and elevate your product perspectives (remember, data can be a product too). Granted, you might lack access to exclusive managerial information, and you might not be accountable for the entire team or its roadmap. Nonetheless, the aspects I highlighted are also essential for efficient execution.
When you’re a manager, stay attuned to the nuances of front-line work 👀. Familiarize yourself with daily operations to guide your team adeptly. Keep abreast of innovative technologies your team members employ. Often, you’re the one endorsing these advancements and advocating for resources. While you may not immerse yourself in every minutiae, understanding concepts is crucial.
It’s Not Micromanagement 🔍
By the way, grasping the specifics of tasks isn’t tantamount to micromanagement.
Micromanagement is characterized by excessive supervision and control over employees’ tasks and approaches, coupled with minimal task or decision delegation.
Probably the most often overlooked element to strong management is coaching. It is the single most important responsibility of every people manager to develop the skills of their people. This most definitely does not mean micromanaging them.
Quoted from SVPG
Comprehending work specifics as a manager is anchored in prior experience and conceptual knowledge, even when methodologies evolve due to technological advancements. It’s vital to understand the intricacies to guide your team effectively. Vague directions like “Be Agile” without concrete steps are inadequate 🥴. Engage with their day-to-day procedures to discern practices worth retaining and those necessitating change.
I will delve into specifics, such as their thought processes, interactions with other teams, and their planning strategies, to gain a comprehensive understanding of the context. These evidences are crucial for diagnosing the situation, enabling me to provide informed guidance and feedback.
📚 Highly recommend “Empowered.”
I often explain to companies that empowered product teams don’t require less management, they require better management. As I’ve written many times, empowerment does not mean just giving those people space to work.
Know Yourself Better 🧘
Embrace each role with the mindset that a switch is always viable 🆗. Self-reflect on your experiences. Gauge your sentiments when leading a team to triumph or when a member faces challenges. What aspects resonate with you? What facets do you aspire to enhance? Which experiences beckon you?
There’s no universal answer. Your path is yours to carve 🛤. Perhaps you desire to refine your technical prowess, leading you to choose the IC route. Alternatively, you might be inclined to enter leadership, prompting a managerial role.
Four months after post-publishing The Next Step of Sr. PM — Don’t Be A Manager, I transitioned to another firm as a manager. Even with the title of Principal Product Manager, I led a PM and two engineers for a brief period. The managerial role wasn’t my primary motive, but neither was it a deterrent. I explored the managerial realm to ascertain my affinity for it. Subsequently, due to business realignments and mergers, I reverted to an IC role. The managerial stint provided insights into broader organizational dynamics, facilitating interactions with VPs and enriching 1:1 sessions with team members. It broadened my horizons on various facets like finance, operations, and HR. However, there were aspects I found less appealing, such as overseeing check-ins and paperwork.
Misunderstanding of the Manager Role 🙅♀️
Managerial roles vary across organizations. For instance, my current company has a reduced paperwork demand. Comprehensive knowledge of both roles enables you to make informed career decisions.
A manager’s calendar brimming with meetings is a common perception. It’s both accurate and misleading. I’ve clocked 20+ meeting hours weekly 🤮 . However, I’ve actively sought remedies to combat inefficient meetings. I made a meeting template, shared with the company how to do meetings, said no to the meetings without preparation or an agenda, and asked to leave when the meeting was overrun. There are things you can do to change.
Contrary to popular belief, a manager isn’t always hands-off. While delegation is vital, staying informed and guiding the team remains paramount. I walked with each team member’s thoughts, proposals, and meeting notes with other teams. I have my own execution projects, too.
Incorporating insights from Paul Graham’s Maker’s Schedule vs. Manager’s Schedule, I’ve found a practical approach to balancing my tasks. Following his advice, I now block my focus time, scheduling meetings exclusively on the same two days or during specific half-day periods. This strategy allows me to dedicate at least a half day, or ideally a full day, to uninterrupted work. Implementing this has significantly improved my ability to manage both detailed tasks and broader managerial responsibilities.
Remember, various managerial styles exist, each with its unique strengths. Don’t be stereotyped. Using Monsters University as an analogy, Sully hacked into the scaring factory with every member to see how the scaring experts work, and asked: What are these scaring experts in common? The answer is NONE. The diversity among scarers is evident. Each has a distinct style, yet they all achieve their goal. So don’t limit yourself 🙌.
Outreach is appreciated 🤗
If you resonate with this dilemma, you are not alone. Welcome to leave comments or outreach 🤝.
🤩 I’m happy to hear how you do data or products. Feel free to reach out to me on LinkedIn Karen Hsieh or Twitter @ijac_wei.
🙋🙋♀️ Welcome to Ask Me Anything.
管理者和獨立貢獻者要選哪個 🤔？ 探索如何在這兩種角色間自由轉換
思考職涯成長時 🤔，可能會在要當主管還是當 IC (individual contributor) 糾結許久。我在 2020 年時，也在這題卡關滿久的。當時把糾結過程及自身回答寫成一篇文章 【PM總動員】資深產品經理的下一步？不當主管也不帶人可以嗎？ 在 2021/1/2 發表。是我第一次在 Medium 發文，獲得 Tech Orage 🍊轉載，意外發現糾結這題的人應該還不少~ 😆。
更新回答 🔄
我想更新 2021 年的回答。最近在一場線上活動，討論資料及職涯，又被問到這題：未來的職涯規劃一定要往對數據團隊主管走嗎？在 mentor 其他 PM 的時候，也發現他們容易卡關在這裡。我想更新的回答應該可以適用於資料及 PM 職涯，尤其資料職涯往上爬的路徑還不是太清楚 🌫，例如，Chief Data Officer 比 Chief Product Officer 還晚出現。我想選擇主管或 IC 應該一直都是長青議題 🌲。
成為主管不是一次定生死，其實是可以變換的，這是個 two-way door 決定 🚪🚪。所以，放輕鬆點 🍹。不用煩惱太久。你可以這次成為主管，下次想當 IC 的時候再當。滿多實際案例的，請放心，這不是一個無法轉圜的決定。
所以重點在於，你是否可以有當主管及 IC 的能力，並了解自己的選擇 🔄。
保持彈性 💪
推薦 Ken Norton 這篇 It’s Time to Fight for a Dual Product Management Career Path. 他在文中將這兩條職涯說明的很清楚，我的認知也類似：
- IC 更專注在產品 🛠
- 主管更專注在 PM, 因此會花更多時間在人身上 👥
身爲 IC, 一樣要有領導力、帶領同事、支持你的主管，持續提升你的產品視角 (資料工作者，別忘了資料也是一種產品唷。) 當然，你可能無法參加主管級會議，可能不會負責整個產品團隊或 Product Roadmap，但影響力等級可能沒有太大的差別，記得 PM 本來就不是靠職位高低來跟其他團隊合作的。
當你是一名主管，一樣要知道前線工作 👀，才能踏實的帶領你的團隊。也要對你的團隊成員採用或研究的新技術有一個程度的熟悉跟了解。甚至，你通常是帶進新技術的人。雖然你可能沒有時間整天的鑽研實務跟細節，但了解概念的程度可能不輸成員。
了解工作細節不是 Micromanagement 🔍
順帶談一下這題，想要了解工作細節不是 micromanagement.
Micromanagement is characterized by excessive supervision and control over employees’ tasks and approaches, coupled with minimal task or decision delegation.
Micromanagement 是對員工的工作過度的監控跟控制，並且很少將決定權交付給員工。
Probably the most often overlooked element to strong management is coaching. It is the single most important responsibility of every people manager to develop the skills of their people. This most definitely does not mean micromanaging them.
Quoted from SVPG
有效的管理中，容易被忽略的是 Coaching. 這是主管最重要的工作。但這絕對不是指 micromanaging 員工。
主管在理解工作細節的時候，可能有較多的先前經驗跟較廣的概念，但專業知識及技術與時俱進、市場變化快速，過去的經驗跟概念不可能一直都適用。一定要具體的了解團隊成員的工作細節，才能有效的協助他們，只有打高空的談概念很難有實際幫助。譬如說，只給一個 “Be Agile” 的指示，但沒有了解、觀察、對於實際執行方法的回饋，很難真的協助團隊成員落實 Agile 🥴. 老實說，不知道成員的對某產品的規劃細節及考量原因、背景等等，真的很難在不夠瞭解的情況下說什麼，我其實需要問到滿細節，夠了解了才能提供建議。需要參與成員每天日常工作、用實際內容，會議討論方式、對話、觀察到的問題、執行規劃等等，來舉例討論，才能真的聚焦在應用上。
主管用這些實際發生的事情討論，是為了讓成員更具體體會，且不同組織、狀況即便同一個 framework 也不一定能完全套用，有很多「看情況」的決定。主管並非要抓住所有決定權 (那才是 micomangement)，而是要理解、指導成員的決定。 當然主管也不會完全不參與決定，這又是「看情況」。
了解自己 🧘
先知道更換職涯跑道是有可能的 🆗。在這個前提下，反思你的經驗，了解自己想在哪個賽道。回想看看，當你帶領團隊完成挑戰或遇到困難時，你的情緒、心情如何？什麼狀況讓你感受最深？哪些經歷你希望不要再來一次，哪些事情吸引你？
沒有正確答案。你的職涯是你的 🛤。可能你想再增強你的技術能力、專業知識，那你可能想成為 IC 多花時間鑽研。或者，你可能想進入領導層，那你會往主管職發展。
在發表 資深產品經理的下一步？一文後的四個月，我成為主管開始帶人，雖然職稱還是 Principal Product Manager, 但帶了一個 PM 跟兩個工程師。帶不帶人不是我當時換工作的主要動機，但也不排斥。又幾個月後，因為公司調整，我又回去當 IC. 有機會參與主管會議、編排預算、處理人事問題等等，體驗到怎麼跟 VP 們開會、跟成員 1:1, 讓我知道原來主管職會碰到財務、庶務等。在這個過程中，反思自己當時接觸這些事情，發現我不喜歡文書作業，但還滿喜歡 1:1 的。試試看才會知道自己喜歡什麼呀 ~
對主管職的誤解 🙅♀️
每個組織的主管職務可能不同。例如我現在的公司，主管職就沒什麼文書作業要處理。理解或嘗試過 IC 跟主管職，可以讓你對這兩個職位知道更多，也對自己理解更多，有助於之後的職涯決定。
常見不想當主管的理由之一是怕會議佔掉很多時間。對也不對。我曾經常每週會有 20+ 小時以上的會議，佔掉一半的時間 🤮。因此學會如何有效率的開會，我有個會議範本分享給其他同事，會拒絕沒有議程或準備的會議，要求會議準時結束或先行離開。還是有些技巧可以改善。
另外一個常見理由是怕自己生鏽，對實務工作不熟悉。雖然當主管是需要放手讓成員發揮，但帶領團隊仍需要持續提升專業知識。我會跟每個成員討論他們的想法、看提案，也會看他們跟其他團隊討論的會議紀錄等等，需要了解狀況，也有自己要執行的專案。
綜合以上兩個理由，Paul Graham 給出很棒的解法 Maker’s Schedule vs. Manager’s Schedule. 依此法，我的會議會盡量集中，先放上專注行程避免被約，讓我至少可以擁有半天，或理想情況下一整天的不間斷工作時間。
每個主管有自己的風格，不要被刻板印象框住。再次用怪獸大學舉例，毛怪 Sully 曾經帶著怪獸們夜闖驚嚇工廠，問大家說：這些厲害的驚嚇專員有什麼相同點？答案是沒有。每個驚嚇專員都有自己的特色，但他們都能裝滿一桶又一桶的尖叫聲。不要為自己設限 🙌。
歡迎交流 🤗
如果你對這個議題苦惱或對此文感同深受，我也曾經如此。歡迎留言或跟我交流 🤝。
🤩 歡迎在 LinkedIn Karen Hsieh 或 Twitter @ijac_wei 上跟我交流有關資料或產品。
🙋🙋♀️ 也歡迎提問 Ask Me Anything.
