Venmo’s Technical Program Management Transformation

January 22, 2021

At the beginning of 2020, Venmo needed to change how we delivered products. In the previous year and a half, our organization had doubled engineers and added product managers. Looking ahead into 2020, we had a truly ambitious portfolio to help bring numerous new products to our customers, helping deepen their relationship with Venmo, and giving them tools to simplify their finances. The product portfolio spanned from a new credit card and Direct Deposit capabilities to QR Code touchless checkout and a business profile for small businesses and sellers. This diversity in products increased our work in progress, called for more iterative planning to meet the aggressive dates, and surfaced program management gaps in the SAFe model we were leveraging. The engineering leadership team identified five key issues that needed to be resolved:

  • The program management organizational structure was resource heavy, including scrum masters and release train engineers (who manage the trains of 8-10 scrum teams).
  • Release train engineers were the only program managers to see the whole engineering picture for each initiative and were assigned to too many initiatives to effectively manage.
  • Program managers did not engage until execution, meaning analysis phases often took multiple sprints beyond what was required.
  • Quarterly release trains took on too many initiatives to meet the product and business needs, spreading teams too thin.
  • Planning was quarterly instead of iterative, slowing the pace of innovation to match a quarterly cycle.

Technical Program Management (TPM) Model

To fix these issues and deliver our portfolio for 2020, the PMO leadership team decided to move to a Technical Program Management Model (TPM) for product delivery. This model leverages iterative planning to deliver initiatives with Technical Program Managers (TPM) focused solely on delivering engineering value. The Product Manager (PM), and Commercial Lead drive the non-technical deliverables like feature requirements, marketing, customer support, and ramp planning. Partnership between the three groups is critical for maximizing engineering capacity and ensuring iterative execution.

Quickly Implementing the TPM Model

After deciding on a TPM model, we identified multiple changes to roll out immediately:

  • Flatten the Program Organization: Migrate scrum masters and release train engineers into a single technical program manager (TPM) role.
  • Build a Repeatable Framework: Roll out processes and documentation that aligns all engineering, product, and commercial team members to one method of delivering initiatives.
  • Deepen TPM Partnership with Product and Commercial: Build deeper partnerships between TPMs, PMs, and Commercial Leads
Flattening the Organization

We immediately needed to get all program managers focused on initiative delivery. In SAFe, initiatives would be supported by multiple scrum masters and a release train engineer (RTE). While each team member had a clearly defined role, the sense of ownership for the initiative fell to the RTE who spanned across as many as eight initiatives on a train. Scrum masters were focused on the scrum team and minimally engaged on the overall initiative, except to provide context on their team’s work. This meant that the RTEs were the only team members to identify risks and issues that spanned engineering teams or collisions between deliverables. As we looked to scale, the role would become unsustainable and scrum masters were excited to see and support full initiative delivery.

Moving to the TPM model allowed us to move all scrum masters and release train engineers into a single role: Technical Program Manager. As a TPM, team members are accountable for the full life cycle of an initiative as well as running 1-2 scrum teams building their products. The new technical focus of the role also meant an expansion on the skill sets of all future TPMs. While some TPMs came from more technical backgrounds, many had less engineering experience but were excited to focus more on the technical aspects of their initiatives. To ensure a baseline technical background, we created a training plan including seven sessions led by engineering leaders detailing areas such as infrastructure, product engineering, payments and risk among others. We also included optional training on program management skills for scrum masters moving into a program manager role, and/or agile practices for program managers who would be managing scrum teams again. This combination of training courses allowed everyone to baseline on the requirements for the role.

Building a Repeatable Framework

Moving from SAFe, we had to dissemble the components of delivery and rebuild where we needed to become more iterative. The first decision was to not change our sprint cadences and existing scrum ceremonies, and to keep the focus on changing program delivery. To outline the new approach to program delivery we created three documents:

  • TPM Framework – An overview of the TPM role, the goals, and a breakdown of tasks by phase

  • RACI for Program Delivery – A task level breakdown showing each person’s roles and responsibilities throughout the full program lifecycle

  • Initiative and Scrum Team Mapping Document – Since scrum masters and RTEs were moving into the new combined TPM role we had to map our 20+ scrum teams and initiatives to the correct TPM. This was the first step to transition into our new end state.

These three documents formed the basis of our communication strategy, starting with the TPM organization and moving quickly across Engineering, Product, Commercial and Executive stakeholders. We started with the framework to give everyone an overview, moved to the RACI for detailed impacts to their teams and provided the mapping document for reference. With this approach, we successfully completed a 30-day transition, including migration of the duties between TPMs.

A key component of the SAFe model is the two-day Product Increment (PI) Planning off-site each quarter. Here, engineers refined features presented by our business and product partners into technical stories and refined estimates to a workable quarterly plan. This provided a clear vision and roadmap for each quarter. As we moved into constant and iterative planning, our goal was to have program leaders and the scrum teams continue to refine features regularly instead of waiting until a PI Planning event. By consistently pulling in features and refining them when needed, the team can plan when it makes sense for their program. Also, if a priority changes, it is easier for us to add a new feature or pause an initiative to pick up the new work.

To implement this framework, we avoided the big all hands and instead pulled all the TPMs into train-the-trainer sessions. Once they were armed with the needed knowledge, they trained their scrum teams. After finishing our last PI planning event, TPMs began planning work to refine and ensure they have key features planned and sized for the next quarter. By the time the quarter ended the teams had enough work prepared that the engineers were able to seamlessly continue without an impact from no PI Planning session.

Deepening our Partnership with Product, Design, and Business Partners

As we built our new model, it became clear that we needed our product and commercial business partners to take a bigger role in driving the nontechnical components of our programs. In partnership with these groups, we outlined the tasks for the non-engineering teams and ensured that all PMs and Commercial leads understood their role. They were trained on the three documents in team meetings and again during the scrum team trainings. We also took the additional step of moving the TPM organization under the Director of Product Management at Venmo. This allowed the PM and TPM teams to partner even closer as the rollout continued.

The Results - Bringing in Seven New Products in 2020

Nearly nine months after moving the first scrum master to a TPM role, the Venmo organization was able to deliver seven new products: this was nearly three times more than previous years. Our credit card initiative was able to plan iteratively and avoid a 2-day PI planning session in the critical July timeframe. And the iterative planning process matched how their partners were developing, making partnership more seamless.

In July, we decided we wanted to roll out our new business profiles registered business solution in November. The team was able to set to work immediately on items in the backlog and continue to plan with the leads until a path was solidified and then executed. Having to prepare for and spend nearly a week in two different PI Planning events would have been a detriment given the timelines and laser focus of the teams engaged to hit this date. Our QR Code project went from planning to ramp in 6 weeks to support shoppers and merchants looking for a touchless purchasing experience. Once MVP was completed, our TPM leveraged the new iterative process to roll out over 15 additional features. The process ensured our product and business teams could make early decisions on priority with minimal estimates before the engineering team dove in to plan and refine.

How We Continue to Mature

As the teams transitioned to iterative planning, we evaluated our reporting tools and made the decision to abandon our Jira Align reporting and revert to PowerPoint and Excel as our tools to track capacity forecasts, initiative status, and roadmaps. We did this because our automated tools no longer met the needs for tracking and forecasting, and we did not yet have reporting needs fully defined. Using Office has allowed us the flexibility to iterate on what we need and make quick changes until we can lock in on formats and data that meets our needs. As I’m writing this, we are in process of rolling out Jira Premium as well as looking at ways to leverage the JIRA data available through tools such as Looker. The reports we have been using from Excel and PowerPoint (while painful for the past few months), have been proven and modified to a workable format that meets our needs and will provide a blueprint for the future.

Our next step is to roll out a full product delivery lifecycle that will solidify the program delivery process the teams have been working on throughout 2020. It also includes a program initiation process to define intake of new work as well as capacity planning tools and reporting processes. This will standardize what’s worked well, ensure consistency across the teams, and allow us to track each phase and estimate accuracy in a standardized tool.

As we look ahead, we must focus on how we track success. Delivering more products more quickly than in 2020 is table stakes. We must define success criteria that will allow us to ensure that we are succeeding because of our people and our processes. The best place to pull the basis for success is to look back at the TPM Framework. The key goals defined there will be where we start with success metrics:

  • Efficiently track and manage a fiscal year’s goals set forth by the leadership team.
  • Ensure timely delivery of all engineering initiatives created towards achieving the fiscal year goals.
  • Efficiently organize, track and manage engineering teams to improve initiative planning and execution while avoiding engineers burning out.
  • Increase regular updates and timely escalations on all engineering initiatives to relevant stakeholders.

Our migration to our new Technical Program Management Delivery Model enabled us to move faster and deliver more than in any other year. 2021 will be another big year with even more revenue goals and initiatives to manage. Our new TPM Model gives us the flexibility to iterate and deliver better products which will be an excellent first step to achieving our goals.

Andrew Simmons, Engineering Program Manager