Making Big Bets Happen

As companies continues to scale across all dimensions, there is an increasing need for us to take on big bets that cuts across organizational boundaries to make some of the industry leading transformations happen on our products, platform and infrastructure. This is where Technical Program Managers play a critical role in driving such transformative bets.

In this post, I'd like to share some best practices to make that happen from my experience driving such initiatives and would love to hear from fellow PMs/TPMs across the industry on frameworks or approaches they have taken on, that has worked well for their initiatives / big bets.

The How

I am breaking down the best practices to follow to execute on such initiatives into 4 parts:

1. Building a Shared Understanding
2. Building Trust, Alignment and Commitment across Org Boundaries
3. Structuring the Program for Success
4. Operational Excellence & Communication

1. Building a Shared Understanding

Building shared context on the initiative is of utmost importance to bring clarity to all parties involved. If not done right, this might result in different folks walking away with different interpretations, resulting in a lot of fires that may need to be put out later on. We need to ensure that everyone is on the same page and address these common questions:

• WHAT are we trying to accomplish (what pain points are we solving? what does success look like? how does this ladder up to the long term vision?)
• WHY are we doing this? (What's the driving force/motivation? why wasn’t this done before?)
• WHEN does it need to happen? (what’s driving the urgency? what happens if it slips or if we don’t do this?)
• WHOM are we solving it for (who is the leadership sponsor? do we have a clear RACI matrix with accountability on decisions & escalation paths? who are the customers & personas, do we understand their jobs to be done and how this will benefit them & their top line metrics, even for internal customers or product teams?)
• HOW are we planning to do this? (how did we decide on this path? do we have experience doing something similar in the past? what’s the cost? how are we going to minimize that? What can we automate? what kind of pushbacks do we anticipate? Do we have supporting answers? Do we have an FAQ ready? do we have an execution plan and operating rhythm?)

These questions are bound to come up once we begin execution. The better prepared we are for these questions, the easier it would be to influence cross-org roadmaps and get their commitments to execute on these initiatives. While these questions may seem obvious, you will be surprised on how often we don't do a good job with building a shared understanding, resulting in surprises down the road.

2. Building Trust, Alignment and Commitment across Org Boundaries

Once we’ve identified the need to kick off one of these cross-org initiatives, we need to identify the different teams involved to make this happen. There is usually a central team that’s driving the initiative with a large number of “decentralized” teams that needs to adopt / migrate / do something to meet the goals asked of them. (Centralized vs Decentralized was a term we used at Uber for similar large scale initiatives driven out of it's Infra org.) It’s really important for us to treat each of those “decentralized” teams or orgs that we need to work with as our partners & customers in this, to build trust & credibility. A few things to think about as you navigate this:

• Pain points: What are the key challenges or pain points the decentralized teams are facing that you can help address?
• ROI: How are you measuring success/ROI for the product/decentralized teams? And how does that ladder up to their own business goals?
• Principles/Strategy: What are the set of guiding principles through which we will make decisions? Have we aligned on those with product teams (esp. if there are competing investments)? What is our execution / adoption strategy and how do we decide on the teams/orgs to go after first?
• Product Readiness: How ready is our solution to declare General availability? Are there gaps that still need to be addressed? How are we planning to build confidence in the solution? (Do we have prototypes, early validation through representative use cases?)
• Migration Readiness: For migration kind of efforts, what kind of tooling/automation is available to reduce load on teams to migrate? How does the new solution compare in terms of performance & efficiency? Who is bringing the capacity needed for migrations? Is it already allocated? When do we plan to get close to 100% adoption? Is that an acceptable timeframe?
• Influencers: Who are the key influencers within each org (Tech leads for eg.) that you need to engage and build trust with, in addition to the org leaders?
• Propensity/Alignment: What is the propensity for the teams to work with us? What are their priorities and where does this effort stack rank against that? Can we work with their leaders in coming up with a plan for a plan?

There is usually a lot of inertia in product teams (for the right reasons) to take on goals that's not aligned with their business priorities. Thinking about the questions above, would help ensure we have done the due diligence in laddering up the ROI to their business goals & solving their pain points and making it easier for them to do what's expected through investments in tooling & automation. That goes a long way in building trust and getting alignment/commitment from the teams that we need to work with.

3. Structuring the Project for Success

Typically, these initiatives are driven by a combination of several TPMs, PMs, EMs, TLs, DS, leaders etc. as it takes a village to make such large scale initiatives happen. The key to making it successful is to have clear swim lanes and a project structure to translate a large audacious goal into actionable work that needs to happen with clear goals per swim lane and clear lines of accountability.

For example, (just hypothesizing) “Save X MW of Power by the end of 2023” could be an audacious goal driven by a central Capacity team which might need work that has to happen across all layers of the stack - Software, Hardware, Operations, Network, Data Center etc. And within each of those layers, there might be 10s of projects that need to be executed across teams and organizations. Hence, it’s important to come up with the clear structure of execution with POCs responsible for each swim lane, with a clear decision making & escalation process laid out. This will ensure we are minimizing the risk/volatility of a large scale initiative.

It's critical to ensure the goals of those swim lanes ladders up to the top level goals of the Priority / Initiative. This is especially trickier and important in programs like Platform consolidation where driving adoption across different components of the stack does not mean our customers are going to be happier. Adoption is just a means to the end. Their happiness stems from their e2e experience ACROSS all layers of the stack - This means there needs to be a dedicated focus on the E2E Developer Experience that spans across team/org boundaries.

One way to achieve that is by defining clear ROI metrics for consolidation that maps to the business goals/outcomes our customers are trying to achieve (thereby, they are incentivized to work with us on this) and ensuring the work happening within each work stream, also ladders up to these top level metrics.

4. Operational Excellence & Communication

The last step is about Operationalizing everything and keeping all stakeholders aligned, informed and on the same page about the progress. Some Best Practices on how to do this:

• A Dashboard that serves as the single source of truth: We need this to reflect the state of where we are at any given point, kept up to date with any new findings / changes in metrics. There needs to be a single threaded owner for this dashboard & key top level metrics here and an ongoing review process to root cause and fix any discrepancies. This dashboard can be manually curated in spreadsheets as a stop-gap solution until we have instrumentation/tooling in place, but ideally should capture the key metrics that we want to measure and move the needle on, half over half.
• An Operational Cadence document / Comms Plan: Once the teams have aligned on the goals, we need an operational cadence doc that should outline the set of all reviews, collaboration groups, meetings and communication related to the project - Monthly Executive summaries, Weekly or Bi-weekly Status updates etc. This helps ensure all stakeholders are aware of all channels where information is being shared and can be in the loop. A program that’s too volatile or has ambiguous goals might need more attention early-on to de-risk it, compared to a program that’s more mature and trending well.
• Decision Making / Change Management Process: At Meta, things change fast and we need to make faster decisions! We need to react to those changes fairly quickly and adapt our plans based on that. As leaders driving the program/priority, it’s our responsibility to be scrappy, bring the right folks together, discuss what’s changing (including if there’s a significant change in strategy), seek inputs and rework the project plan and get buy-in from the key stakeholders and partners involved & communicate back to everyone involved.

As TPMs, we need to strike the right balance here in helping teams move fast while keeping a framework like this in mind. That said, I'd love to hear approaches that you've taken on, that has worked well for you in programs you've led as I'm sure there are different approaches that work better for different types of programs and operating models that different organizations/companies are used to.

Last but not least, I'd like to thank Ananth Sankaranarayanan, Sung Hsueh, Sudarshan Govindaprasad, Poorvaja Ramani and Priyanka Patankar for their inputs in shaping this post. I'd also like to thank Aparna Lakshmi Ratan and Ankit Asthana who have been my partners in crime in driving some of these large initiatives at Meta in the AI space.

Disclaimer: Any views expressed in this post are my own and not that of my employer(s).