AMA: GitHub Senior Director of Product Management, Julian Dunn on Developing Your Product Management Career

A few of things: * Know what, when and how to delegate. Delegation has such a negative connotation in industry (being seen as letting garbage flow downhill) but I believe this is because so many managers are poor at the mechanics of delegation. As a PM director, you have to learn how to delegate problems to be solved and not orders to be fulfilled (a/k/a solutions) and be comfortable with the ultimate solutions even if they weren't what you would have built as an IC in the shoes of the delegate. You must also learn to see delegation as the manner in which you are granting autonomy and growth opportunities to your direct reports and not as the way to hand off dirty work that you would rather not do to "underlings". * Frequent contemplation of organizational design and areas of responsibility. Every week I am thinking about organizational design and at least quarterly I am having discussions with my peer leadership team in engineering and design to talk about whether we are a) staffed appropriately in the areas we need to be; b) whether we have the right skillsets and mix of seniority on our teams; c) whether we are optimizing for the strengths of PMs/eng leads/design leads while also giving them opportunities to stretch and grow in their current roles. * Employing a variety of communication styles with a wider range of stakeholders. We all have our default, natural communication styles (for example, my management style with my direct reports defaults to Socratic) but a director has to know when to switch styles based on the recipient of the message, their level of seniority, their personality, etc. -- and be able to intuit this very quickly in the course of delivery. I have had to force myself to be more direct ("Crucial Conversations"-style) when a softer message isn't making it through, for example. A corollary here, particularly when dealing with senior stakeholders: knowing what to spend one's political capital on, and when to pull back.

There are a couple of factors to consider here: * Are you learning anything new in your current role? If not, would staying with the company, even if it is in a different role, or a more senior role (be that IC or management), satisfy your learning? * Do you enjoy the domain, vertical, and business model of the company that you work for? * What are the company's growth prospects (or if a startup, prospect for success -- however you define success?) Be very honest and don't just take company management's word for it. * Are you excited and passionate about the product that you're currently working on? * Do you enjoy the people that you work with? (your manager, your peers in engineering/design, your peers in product management, etc.) If not, is it likely to change over the next 6-12 months or whatever is your window of tolerance? * Are you and your ideas respected and given a fair shake? How much autonomy do you have versus how much do you want? * Does the company's appetite for risk match your appetive for risk? (e.g. are you working on a horizon 1 product when in reality you would rather be working on a horizon 3 product) There is no right or wrong answer to these questions but I hope they will spur an honest assessment about what is tolerable (and also if currently intolerable, is it likely to change to tolerable within period of time) versus what is a hard red line for you.

It can definitely be a steep learning curve, because at Staff+ PM level you are expected to have strengths in one or more areas of product management that aren't often exercised at lower levels. Some examples: * Having a much wider aperture and being able to develop and sell portfolio-level (not just product or feature-level) product strategy that can touch other areas of the company * Assessing and making build vs. borrow vs. buy recommendations & understanding how to work with a channel/partner/business development team * Coaching and mentoring other PMs and reviewing their work * Portfolio-level goal setting and roadmap management * Organizational design (how to do it, when to change it, influencing your engineering & design peers to restructure their org structure as the product evolves) * Preparation of executive-level communications (how to convey only the most important information in the most concise manner possible) The good thing is that you are not expected to be excellent in each of these areas right out of the gate. But it helps to do a couple of things if you are aiming for Staff+ IC in your career: * Pick one of these areas and figure out how you can proactively pick up opportunities to learn and improve now. If you plan to stay at your current company, it helps to pick something that is a gap/weakness in the organization to make yourself more valuable. * Focus your reading / learning / professional development / networking in the PM community towards that topic, so you gain some outside perspective on it. * Be transparent with your manager about your career aspirations and what you are doing to level up in at least one of these competencies -- and hopefully align that growth with something that your manager needs in the group. I will mention one exception to all of the above. It is possible at some companies to become Staff+ PM simply by having more historical and domain knowledge than anyone else such that you become the "product oracle" for that area. In these situations, a breadth of skills outside of that domain knowledge is less necessary. Just remember that there can only be one oracle; once you choose that path, it is hard to get a Staff+ PM job elsewhere unless that company specifically needs the same wealth of knowledge.

My answer to this depends a lot on whether the "director" title includes people management or not. Personally, I believe that it should, and that the IC (individual contributor) track should only use the titles PM 1-3, Senior PM, Staff PM, Principal PM, Distinguished PM, etc. But I don't make the rules for the industry :-) and I recognize a lot of organizations use "director" to mean IC as well. I am going to answer the question assuming you mean that it includes people management. Accordingly, the top skill you want to have is a) knowing that you want to manage (a/k/a model, coach/mentor, care) other humans and that you don't just want to be an IC with more influence, and b) learning how to do that, or at least walking into it having some kind of a philosophy about management. I don't believe it's necessary to have prior experience as a people manager before becoming one (otherwise it's a chicken & egg situation and there would never be any people managers!) but demonstrating coaching / mentoring / feedback behaviors with your peers is a great way to gain these skills before you manage other people. I can't emphasize the foregoing enough because if you do not truly care about understanding human beings in general, what motivates the specific humans on your team, and how you can coach them to being better PMs, then you are going to view the "process" of managing people (HR reviews, hiring / separation duties, compensation management, 1:1s, etc.) as drudgery rather than tools to build an amazing team. I would say that the other two skills that are critical are: * Being able to drive change through your team, representing both their plans and their achievements to senior management and advocating for them, and * Executive presence and gravitas, including the ability to remain level-headed and confident no matter the obstacles in front of you, to give both your team and your management the confidence in you as a leader.

I've definitely been there! As you correctly intuit, your first order of business is to buy yourself some time to develop a strategic point of view and a roadmap that supports that it. Obviously that means you're going to need to spend time meeting with customers, prospects and customer-facing teams inside your organization, synthesize the learnings, and develop that roadmap & strategy. In a startup, you have to do this at a much higher tempo than at a more established company, but it's essential that you convince your direct (and indirect) management that investing in these things is going to pay off down the road in time saved / lower risk for the startup / more satisfied customers / whatever rather than just continuing down the feature factory path. What's important when you have that conversation is to be explicit about the things you are going to drop or do less of, like literally saying, "I am going to do less tactical project management, status reporting, etc." Invariably, some of your peers who have expected PM to do these things are going to be disappointed at the lower level of "service" which is why you need your management to buy in on your shift towards becoming more of a strategist rather than a tactician. This may need to be a shift that happens over a couple of iterations particularly if the organization is not used to strategic product management (you can't "big bang" stop doing project management if the company doesn't trust you to deliver high-quality strategy yet). You don't mention the reasons behind why the startup has become less sales-led and more product-led. Whatever those reasons are (e.g. we are good at bookings but our churn is really high when customers find out our product falls short of the promises), you want to be clear-eyed in understanding them and tying any communication around your shift in focus to those issues. Also, there will obviously be one or more individuals at the company driving that change from sales-led to product-led. Ally yourself closely with those individuals, get them on board with your plans, have them amplify your strategic work products, and (particularly if they are more senior to you) use them to deflect the noise from folks who wish you would just spend more time doing project management.

This is a tough question to answer because it is so situational. For example - I have seen organizations where PM is so immature that it is essentially a project management function. Melissa Perri even uses such an example in her excellent book Escaping the Build Trap! While in Perri's fictional organization, she was able to develop the PMPs into PMs in the end, many companies would opt to try and hire a few true PMs first. Another dimension is mix of seniority which is critical on any team (just like in engineering). If you have a team of all very junior-to-intermediate PMs, you may find that you cannot develop any PMs fast enough into being sufficiently senior & that you need to hire outside. A great Staff+ PM is worth their weight in gold because not only do they generate great results themselves, but they act as an accelerant to the rest of the organization: engineers and designers become both more productive and happier. You also asked about switching folks from other roles in a company into PM (e.g. engineering, sales engineering, customer success, professional services, support, etc.). In my experience, this can work, but moreso at junior to intermediate levels on the PM career ladder. This is because there are a lot of skills that a PM needs to employ that are sometimes not exercised in these other roles. Many such transferees need to be disabused of the notion that PM is just about having a huge wealth of domain knowledge and employing that to "tell people what to do". Even if you can overcome such a barrier and the candidate truly wants to do PM, the compensation gap from where they are coming (particularly if coming from a revenue-oriented role) and perceived demotion may be unsurmountable & you may need to hire from outside.