AMA: Meta Director, Technical Program Management, Vasanth Arunachalam on Building a Technical Product Management Team

Building with intent is key. As a first PM or TPM, you are often running a one-person show. You wear multiple hats and you tend to be scrappy, flexing to what the business needs you to do. That approach works wonders up to a certain scale but soon exposes its flaws. When you think about scaling out from there, here are a few things to consider - * Understand your business (replace with org or product team) needs deeply, ideally the 1 to 2 year trajectory of where it is going. That’ll tell you what type of product person you need to hire next. Someone with augmenting skills (Growth PM to scale out in new markets) or complimentary skills (a Technical PM to build better platforms)? * Hire strong leaders in advance. Some take the approach of waiting until the teams grow to a certain size, before they hire leads/managers. I’d suggest the opposite, for a few reasons - * Strong Product leads think big picture and know how to design orgs for the future * Coming in early gives them the opportunity to grow product expertise better. They get to be a part of the evolution of the product which is critical * They are good at hiring too * As much as I advocate for hiring strong leaders early on, promoting talent from within is equally important. Look into your cross functional teams to see if anyone might be a great fit for product roles on your team. One of the best Technical PMs on my team was a Data Scientist 4 years ago. * As your Technical PM org grows, there will be overhead in terms of decision making, co-ordination, communication etc. Optimizing your org design to minimize such overheard to the best extent possible is useful. * Aligning with your business structure and locations is an obvious one. * Ensure diversity. This is often an area where orgs struggle. Hiring more of you is not a great recipe for success. Finally be open to updating your org/team design as business and people grow.

Expanding the team from 1 to multiple people comes with a set of pitfalls that I’ve learned the hard way. And many other factors such as Org culture, line of business, product lifecycle etc, have a telling effect on the type of pitfalls you’ll encounter, so take this with a grain of salt. Here are a few things worth considering - * N degrees of separation: The larger your org grows, more layered your teams are (typically). Ensuring that you and everyone on the team feel connected to each other in a meaningful way is super critical. Here are a few tactical things you could do - * Regular team meetings for sharing broader context * Async modes of information dissemination (via ‘Top of mind’ type notes, ‘bite sized’ videos etc) * Skip level 1:1s at a certain cadence to get a pulse on the ground (and also to get feedback about you) * Curating culture: I recently read somewhere that team culture is nothing but ‘Behaviors you reward and behaviors you punish’. As your team grows you’d want to ensure that the culture or identity of your team is well understood and reinforced regularly. Coaching your managers/leads on that front should be top priority because they ultimately play a key role in sustaining that culture. * Delegating decision making: When you manage a small team, typically a lot of the decision making (and tie breaking in terms of conflicts) comes to you. As your team grows there might be a tendency to follow the same approach which you should discourage. Empower your sub-teams and sub-team leads to take ownership. Have a clear sense of when you want to get involved. Here is the framework I use: * Just inform me as FYI for X set of topics * Seek opinion from me for Y set of topics. * I’d like to be the approver/decision maker for Z set of topics (ideally this is a very narrow list) * Goal mapping: As the org/team grows ensuring everyone’s work ladders up the org level goals is of paramount importance. In our roadmap templates we have a way to ‘map’ each team's goals to the org level goals. The teams articulate how their deliverable move the needle on the org level top line goals.

Prioritization is key. I don’t believe in dividing ‘all’ available work across my team. I believe in ensuring my team focuses on the top business priorities and are having the most impact. I typically encourage my team to do a few things but do those really well and not ‘peanut butter’ themselves across many different areas. A Technical PM on my team might be taking on multiple product areas (typically not more than 2), but they set clear expectations in terms of what their roles will be and how they’ll spend their time across those. A few things to pay attention to - * Understand what areas absolutely need a PM/Technical PM and prioritize those. This could be for various reasons - 1) Getting to product market fit; 2) Expanding to new markets or a new customer segment; 3) Defining requirements for an ambiguous product feature; or 4) Driving alignment across key stakeholders on goals * Sometimes you know you’ll have to staff a PM soon in a product area (or a product feature). It might be worthwhile to have an existing PM spend a small % of their time understanding and scoping the landscape which might inform what type of PM you want to hire and when. * If a PM is not able to focus 100% of their time in a product area, identify responsibilities that could be delegated to other functional leads (Engineering, Design, Data Science etc). The last thing you want to do is burn out your most valuable PM because they are so good at it.

For the first part of the question - * I stared my career as an Individual contributor IC) and as you know that is all about specific product/platform strategy and top notch execution. I talked about the day to day of an IC in my previous AMA. * When I transitioned to a manager role with a small sized team, it was all about scaling myself through my team. I was still accountable for a specific product area (M&A, Backend services for an OTT platform, Business Integrity Enforcement etc) but it included a bunch of products/services that required me to expand my expertise into. I still acted as a subject matter expert, providing guidance to my team on a day to day basis. Ensuring tighter alignment of my team’s goals was relatively easy and I had greater visibility into the progress my team made. Every day we’d be laser focused on solving our customer problems, there was lot of room to gets hands on. * When I grew into an org leader with a team size of 35 to 40 people, my role gradually changed. I became the functional lead representing Technical PMs in my org’s leadership circle. My role spans 5 to 6 major product areas with ~1000 people cross functional teams. I need to be able to get a perspective on all aspects of the business (some areas where my team might not be staffed) and often rely on my own team leads to provide all the context. I spend most of my day today on the following (among many other things) - * Setting and articulating the org level goals & priorities. Ensuring our teams understood how their work fit into the bigger puzzle * Ensuring those goals (and any dependencies) are well understood by other cross functional teams (Eng, Design, Data Science etc) so that we can build strong relationships and collaborate well to achieve desired business outcomes * Regular product/platform reviews with the teams to keep myself and the rest of the leadership informed on progress and ensuring alignment with org level goals * Solving for any blockers on behalf of my team and the org * Supporting my team well to ensure people’s skills are matched with the right opportunities (and priorities) * Hiring and ensuring the new people on the team are set up for success For the second part of the question, I’ll respond from an org/team lead perspective and focus on one trait that makes such programs successful. Since I work in Integrity (a.k.a Trust & Safety) there is a constant need to reprioritize my team’s resources to tackle new challenges and emerging risks that come our way. I ensure such trade offs are well understood by everyone. And often those challenges require us to set up large scale programs with significant east-west collaboration. When dealing with new or unknown problems, I’ve seen that strong Technical PMs typically get up to speed in a new or unknown area pretty quickly. While managing a program in such a problem area, my teams spends a lot of time communicating, with extreme clarity (context, problem, goals, solution, timeline, risks etc). That is the single most important aspect of managing such technical programs IMO.

I’ll try to answer this question to the best extent possible because I havent worked at a company that had formal SCRUM master roles. My understanding is that the SCRUM master focuses on ensuring the team and the individual team members are set up for success (via daily stand ups, educating on best practices, conflict resolution, project tracking etc). In today’s world, I believe these are skills that everyone should possess (PM, Technical PM, Engineering Lead et al). That’s how Meta operates and any of the aforementioned functional leaders could play that role. This could be a controversial thing to say, IMHO the SCRUM master role could be antiquated soon if not already, especially in fast paced tech companies and start ups.

“Change is the only constant” is a cliched phrase in the industry but the reality is not far off in many lines of businesses. At Meta we often get to work with the best available information in hand and not afraid of pivoting when that information changes. That comes with a degree of ambiguity, churn and sometimes loss of motivation for the teams involved. As a leader, my role is to ensure the teams have a strong understanding of the ‘why’ and when priorities change, again communicating the ‘why’ with full transparency. I then empower the teams to drive towards subsequent outcomes which could be any of the following - * Pivot and rework the plan with a new set of strategies, goals and timelines. * Stop the press and shut it down. In either of those scenarios my team communicates clearly to all the stakeholders. You might see a pattern here with my emphasis on ‘ strong communications’. On the motivational front, if you build a culture of rewarding people for stopping the press, you’ll see teams surfacing problems and recommending pivots sooner.

I talked a lot about evaluating the success of a program, measuring the success of a Technical PM etc in my last AMA on the topic of "Technical Product Management". https://sharebird.com/h/product-management/ama/meta-head-of-technical-program-management-vasanth-arunachalam-on-technical-product-management

I love this question. Typically one does not boot strap their career as a Technical PM, at least not until recently (Some companies including Meta are hiring Technical PM interns now who start their career as a TPMs which is great). So the most common TPM career progression stems from Engineering, Data Science, Product Operations, Partner Solutions Engineering etc. I’ve seen so many people from those backgrounds be immensely successful as a Technical PM. And there are people with many more backgrounds who could be equally successful too. I never look at job titles. You might even be surprised to hear that I never look at an interviewee’s resume. I do a lot of Solutions design (which is all about hypothetical problem solving anyway), partnership and leadership focused interviews, so what’s on the resume hardly matters in terms of the signals I want to gather during the interview. I focus on behaviors such as Strategic influence, Collaboration, Conflict resolution, Motivation, Product Intuition, Program Management etc. and I want to see examples rooted in tech as much as possible. In technical deep dive interviews is where past work matters (therefore resume) and I want to see candidates demonstrating strong E2E technical understanding, and the ability to deep dive into a few areas of their past work.