Vasanth Arunachalam

Vasanth ArunachalamShare

Director, Technical Program Management, Meta
Content
Vasanth Arunachalam
Vasanth Arunachalam
Director, Technical Program Management, Meta | Formerly MicrosoftAugust 10

I’m assuming the question is about setting a ‘team’ vision/mission and one doesn’t exist yet. The mission statement is the “What” and the vision statement is an ambitious future state of what the world might look like when you accomplish your mission.

A crisp vision/mission statement serves as a strong identity for your team and guides them during critical moments of decision making, gaining alignment, prioritizing resources etc. Here is a framework that I’ve leveraged in the past to arrive at a vision/mission statement for my teams, collaborating with our cross-functional partners. Have each person in the working group articulate the following in once sentence.

  • Understand our role
    • Why do we exist?
    • What is our purpose?
    • What principles drive our product building?
  • Understand our customers
    • What does research tell us?
    • What problems do they have?
    • How are we helping them?
  • Understand how the future looks like
    • What’ll happen if we didn’t exist?
    • What does success look like?

Next, create the vision and mission statements based on common themes and ensure it aligns with the company’s vision & mission. These statements should typically be short, start with a verb, strive to be aspirational and endure the test of time. Once the working group of cross functional partners align, socialize with key stakeholders and the broader org. You might want to consider doing a branding splash (new logo, ordering swags) to get people excited about the new vision & mission.

Vasanth Arunachalam
Vasanth Arunachalam
Director, Technical Program Management, Meta | Formerly MicrosoftAugust 10

“Rushing to prove value” is one of the common pitfalls of starting in a new role. Having said that, you want to make steady and incremental progress in delivering value. See my response to the question "What's your best product management 30-60-90 day plan to make a big impact at a new company?" for the framework you can adopt for a 30-60-90 day ramp up plan. Here I’ll outline some quick wins you can aim for but I can’t stress enough on not coming across as ‘rushed’.

  • Relationship building with your team. Get to know them better as individuals, take the lead on setting up that recurring team lunch or happy hour, take the lead on driving that team stand up.
  • Owning an in-progress project and taking it over the finish line (driving a product launch, leading a SEV).
  • Sharing your perspective on product/customer pain points and what we could do to get better.
  • Unblocking teams where necessary on a day to day basis.
  • Documenting product flows, platform architecture or other business critical information as you ramp up. Often times when I wanted to ramp up, the lack of proper documentation is why it takes time. You could fix that for future team members.
Vasanth Arunachalam
Vasanth Arunachalam
Director, Technical Program Management, Meta | Formerly MicrosoftAugust 10

The listening tour is what I love most while taking on a new role. I’m a social person and I love meeting people. What better than getting to know the people you are going to work closely with? I typically have a ledger that I carry with me into these 1:1 conversations with my cross functional team members and take notes diligently. This also helps me to organize those into themes. Towards the end of my 30-60-90 day ramp up, I do a share out of my perspective on what works, what doesnt and where we could do better.

Here is how my 1:1 conversations during the listening tour are structured -

  • Introducing myself and getting to know them as an individual - How long have been here at the company? Where did they work prior? If they are comfortable, getting to know where they live, their family and what they enjoy doing in their personal life etc
  • What is working well (product, team)?
  • What is not working well (product, team)?
  • Where can I and my team help the most?
  • What is the best way to partner with your function and vice versa?
Vasanth Arunachalam
Vasanth Arunachalam
Director, Technical Program Management, Meta | Formerly MicrosoftAugust 10

I’ll apply the framework outlined above to this question and talk about setting up a Technical PM function for the first time.

30 days of LEARNING: I’ll start with a listening tour, meeting with all cross-functional leaders (Engineering, Data Science, Design, Marketing, Operations etc) and trying to understand where the Technical PMs can add value. I usually get a list of all the areas where help is needed. I ensure that the expectations from the team aligns with the Technical PM job profile and career expectations defined for that job profile. Next I get a deeper understanding of the following - 1) Overall org growth plans (hiring, site strategy etc) 2) Long term strategy for the Product/Platform along with current priorities

30 to 60 days of ALIGNING: Once I have consumed all the information, I typically create a plan to build the Technical PM function and scale out for the next 1 to 2 years. I’ll prioritize roles I’m going to fill based on where the Technical PMs can have the most impact in relation to the org priorities. I’ll ensure I have alignment with the cross functional leaders on that plan. I advocate for hiring strong leaders in advance and not waiting for the team to grow to a certain size. This is because - 1) Strong Product leads think big picture and know how to design orgs for the future 2) 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 3)They are good at hiring too.

60 to 90 days of EXECUTING: The next order of business is to partner with recruiting and kickoff hiring. I’d also recommend getting hands on as a leader, by taking ownership of a critical product or platform area before you staff your team. This provides the opportunity to understand the space and the challenges your team might face in their roles. Now is the time to also build some of the key processes to help your incoming team be successful. I’ve addressed some of these in my previous AMA

Vasanth Arunachalam
Vasanth Arunachalam
Director, Technical Program Management, Meta | Formerly MicrosoftAugust 10

I worked at Microsoft for about a decade and then moved to Meta to take on a new role, a few years back. That was the most unsettling period of my professional life. I’ve gotten accustomed to a certain culture, way of work life, people, tools & processes etc at one company and the thought of having to do it all over again was intimidating. I decided to build a 30-60-90-day plan in my new role at Meta to provide clarity to my team (and to my manager, myself) about how I’m going to ramp up.

Deborah Liu, currently CEO at Ancestry, who was at Meta at that time, pioneered a template that is widely used at Meta. She also wrote a blog post about it linking to the template which I highly encourage you all to read and leverage. Her framing resonated well with me and I’ll share my personal take on it.


First 30 days of LEARNING: One of the common pitfalls that n00bs (aka new employees) do is rushing to prove their value. I took the time to understand the new company’s culture, vision, mission, top priorities. I took the time to know the people (teams, stakeholders, partners) and began to build trust. Understanding how you and your team fit into the bigger puzzle is important. The listening tour, sitting in customer feedback sessions or taking a bootcamp class (if your company offers one for your role) are great avenues of learning during this time. Have a clear understanding of what is expected of your role and publish the 30-60-90 day plan to provide transparency into how you’ll ramp up. 


30 to 60 days of ALIGNING: Having an opinion is important for any strong leader. Based on my 30 days of learning, I began to form opinions about what is working well and what isn’t and validated my POVs. Aligned with key stakeholders on what a forward looking plan for your product or team might look like. You are also getting comfortable by getting hands on (if you are an IC) or making small decisions (if you are a leader), continuing to build trust.

60 to 90 days of EXECUTING: This is when the rubber hits the road and the time when you are about to lose your ‘n00b card’ (or honeymoon period). I clearly articulated the execution plan for the updated vision, roadmap and began to lead the team down that path. At this point, I’ve gained my team’s trust and I am one with the team. This is also the time I wrote my own performance goals for the next quarter or half and shared it out. Getting feedback continuously allowed me to adjust quickly. Taking on a challenging product feature or solving for a crisis situation has always allowed me to ramp up and gain expertise quickly. I recall Sheryl Sandberg saying once “Never waste a good crisis”.

Vasanth Arunachalam
Vasanth Arunachalam
Director, Technical Program Management, Meta | Formerly MicrosoftMay 3

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.
Vasanth Arunachalam
Vasanth Arunachalam
Director, Technical Program Management, Meta | Formerly MicrosoftMay 2

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.
Vasanth Arunachalam
Vasanth Arunachalam
Director, Technical Program Management, Meta | Formerly MicrosoftMay 2

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

Vasanth Arunachalam
Vasanth Arunachalam
Director, Technical Program Management, Meta | Formerly MicrosoftMay 2

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.

Vasanth Arunachalam
Vasanth Arunachalam
Director, Technical Program Management, Meta | Formerly MicrosoftMay 2

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.

Credentials & Highlights
Director, Technical Program Management at Meta
Formerly Microsoft
Top 10 Product Management Contributor
Lives In San Jose, CA