How To Do Quarterly Planning As Program Managers

Read the Full Transcript

The following transcription has been paraphrased for readability. 

Bhaji Illuminati: We have two wonderful women with a great background in program management joining us today. First, I’ll introduce Becky Flint. She’s the CEO and founder of Dragonboat, a PPM platform for outcome driven product organizations. Becky built product portfolio management and led quarterly planning at PayPal, Shutterfly, big commerce, and feeds AI. She has also partnered closely with both product, business, and technology leaders. Becky started Dragonboat from her firsthand learning to streamline and automate product portfolio planning and tracking and reporting.

Pamela Surjadjaja is the Head of TPM for LinkedIn marketing solutions. She leads a team of TPM that drives planning, engineering ops, portfolio, and program management. And she led planning and programs at LinkedIn, Fitbit and PayPal as well as serving as a Deloitte consultant.

The challenges we’ll talk about today fall into 6 primary buckets: Who gets the resources? Where are we stuck? How do we all get on the same page? What if things change? How do we change along with it? And lastly, is it working?

Becky Flint:  Pam, tell us a little bit of your career journey and how you went from a program manager and from Deloitte consultant all the way to leading a program management team.

Pamela Surjadjaja: I started my career in program management. I was actually part of Deloitte digital, so we do implementation, but also strategy consulting. From consulting, you can actually go into many different kinds of career routes. But I think what really stuck with me was program management, I was really good at it. But also, it was a way for people to see things holistically as to what is happening in the company. So I moved into PayPal, I joined as an IC and started out my career as a program manager. I led a platform team. And then from there, I started moving towards the UI team. From there, I transitioned into Fitbit. I actually joined as a portfolio program manager. And then from there, I transitioned to LinkedIn. I transitioned as IC, but I quickly grew into management.

A lot of the skills throughout my career, especially around planning, built on top of each other and helped me to understand the different varieties of planning out there.

Becky Flint: I really love the fact that you use and leverage your experience from business, which has both the product and execution. Similarly my career has also been in product and tech execution. Program leaders ultimately become executives. That planning plays a very big role in how you tie the moving pieces of business goals, customer needs, and product initiatives, with your resources and stakeholders. It’s actually more like a CEO more than individual projects at the execution level. So this is a really good segway to come into talking about this topic. The best companies today will complement agile sprint activities with quarterly planning.

Pamela Surjadjaja: Right, and there are multiple stages to quarterly planning. There’s the team level, then the org level, and then the executive level.

So depending on which company you call, it can have different needs. I think what really is a good experience is when people leverage quality planning to align on executive decisions. I think that is the most effective way to leverage. Then, at the lower level, before you come in, make sure that you’re already pre-aligned. Make sure that you’re coming to coordinate with me. Do you have any input information that I’m not aware of that I may need to adjust. But a lot of the known stuff should already pre align.

Becky Flint: Yeah, and at the bigger framework, every company has the executive level, much like the manager. Then there’s director level, and then you have the team level. And to your point, if we do an executive level, you have a high-level alignment annually. You should know what you want to achieve a year out. There are different strategic themes, of course. Then quarterly planning down at the manager’s and director’s level, becomes something where you set up clinical milestones- things that lead to the annual goal.

Once you’ve done good quarterly planning that can cascade down to your team for execution and agile and the scrum level, it will be very smooth. If you don’t do quarterly alignment, it will be chaotic. You won’t know where the bottlenecks are, and things are not identified.

I also would like to echo what you said earlier about doing homework and relying on our product. I had a session earlier about quarterly planning with a product. From a product perspective, it’s a continuous process, but it also comes together, meaning product managers continuously carry in their research in the market and customer feedback in their system. That way, they can add a quarterly cadence. They can say, “here’s how we align our product-thoughts with our OKRs and goals so that once we go into the quarterly planning,it’s pre- aligned already. Product ideas with product initiatives are aligned to the quarterly goals. Furthermore, those are already aligned to the company vision and direction so that it’s much easier to talk across teams.

Pamela Surjadjaja: Yeah and we often use the term continuous planning. And what we mean by that is that planning should not only start in the first month when preparing for the next quarter. You should already have an idea of where you want to go- like a roadmap. Give a snapshot of the next three months. You should ideally have a continuous plan, and that roadmap can show you longer-term. That’s also how you pre align. Where I’ve seen really successful teams is when they pre-align dependencies far ahead as well. For example, they might say, “in six months, I anticipate to do this, can we pre align? Maybe you need to do dependency in q2 for us to be done in q3”.

Becky Flint: Exactly, because our work does not start at the first of the month of the first day of the quarter. It’s continuously moving so it totally makes sense to continue to monitor and think ahead. And then coming together on a quarterly basis, that makes a lot of sense to us as well.

Now quarterly planning and delivering a portfolio involves a lot of stakeholders, what are your experiences from a primary Program Manager point-of-view on engaging with different stakeholders and how your product team plays this role together in the quarterly planning process?

Pamela Surjadjaja: Typically, I would say there is a core team that is really involved in quarterly planning, then there are other kinds of teams that you should be engaging as well. The core teams that I know, as part of production, are always the engineering lead. Then you have, of course, the product manager, right. So three of you. And then with design, there is usually very much involved in the quarterly planning. Beyond that, other stakeholders that have been extremely valuable are PMM or Product Marketing, as well as BD. If you’re trying to go to market during that period of time, then you want to make sure you’re informing your product marketing folks, because sometimes that may or may shift some of your plans for the quarter.

There’s also, depending on where you are, regional partners or other partners that you have in the company. These are to inform what pipeline is coming in that you potentially want to partner with. So those are the kind of folks that we usually work with. At the end of the day, the people that are accountable for the quarterly planning are product, program, engineering, and design teams.

Becky Flint: Yeah, that’s a great point I want to touch on. Like you said, a product manager, product program, and an engine lead, and maybe design, are fairly involved in the quarterly planning. In some ways they are continuously planning. We have to continue to think about what we could do, what we should do and what other things can be evaluated.

One key thing that a lot of people were trying to figure out is, what is the product manager’s role, what is the program managers role in this process? From my experience especially as the company gets bigger, the scope becomes broader as well. When a company gets bigger, we start to have program manager and product manager roles.

There is a little bit of separation of who covers what. In my experience, program managers focus on cross functional collaboration and cross functional stakeholder involvement. The magic is that sometimes something it’s really urgent, it’s a really high priority, but it’s not ready to start because there are dependencies or whatever or they have a longer deadline. So then program managers can help in the process to make sure the timeline is lined up in an optimal way. This would also help the product to slot different pieces in in the best way possible. That way, the most important things don’t necessarily need to be done first. That’s my experience on how program managers can create magic by leading the quarterly planning, and changing the outcome.

Pamela Surjadjaja: Yeah, and I see product manager and program manager roles involved even in smaller sized companies. In a small company, product and program managers tend to be tightly knit. They think about a strategy to get around that, divide and conquer. There may be some overlap in terms of both skills and function, but as you grow bigger, I’ve noticed that product managers usually focus a lot more on the strategy side of the house such as big picture and marketing of the project. That’s usually where they spend a lot of their time because it takes a lot of time.

That’s also where they handoff to program managers to kind of help with everything else. So once there is alignment on the top, then it’s more of understanding how we operate. What is the operating plan? How do we execute this? How do we align this so that there is less disruption during handoff, especially with multiple teams, and that’s where program managers do their magic. They help make sure that everything is aligned. They also identify places where there will be a handoff and how to do the handoff. So they are really responsible for the operating plan and executing it up.

I’ve seen program managers hold different kinds of roles. Some program managers will help until the end of the life cycle. I’ve seen program managers help up to the point of delivering to go to market, feedback, and everything. I’ve seen it done many different ways, but program managers always help with quarterly planning. They identify how to structure the delivery and when in the quarter the handoff should happen.

Becky Flint: Right, I think that’s totally true, I think there are two things to mention. One is that obviously the skill sets, the interest, and the focus of the individual varies, but in many ways the program manager’s value is to take the programmer to the end. Taking it to the end would also add a lot of value and drive the continuous planning.

The second thing I like that you mentioned is I think the timing of the execution is very important. Even though they’re not like a waterfall so you do not have to plan everything to the dates, you do want a good idea on how things look. And that’s achievable by any new resource and dependencies. That also means that if you don’t have the element, plans won’t come into place and that the quarter will just fall apart.

So with that said, I’d like to touch on the next topic around multiple teams and multiple resources. That’s something that a program manager deals with a lot. Oftentimes, other teams come to our team asking for resources despite our own team also having to deal with the dependencies and bottlenecks. How do you go about and help manage this?

Pamela Surjadjaja: With multiple products the best way for program managers to be really effective is to go in and bridge everything together. Look at this more from a program’s perspective, instead of my team and your team. Put aside the actual planning to come together as a kickoff. Figure out all the teams needed, and the vision so that everything is aligned on the top. That way, you know, roughly what people need to be doing in their area. From there, you can give them the opportunity for them to actually pre-plan, and then give them a week to come back together and ask “what does this look like in terms of timeline?”.

Lastly, that’s when you can talk about sequencing and dependencies to figure out what can be adjusted, dropped, and slotted. There’s a lot of times people think that you have this chunk of work that you need to do and you can only come and start integrating in the middle of it. But you don’t have to wait for this whole chunk of work to be done. We can start integrating depending on what the thing is. That’s where that discussion is. You’re not necessarily just planning in silos, because it becomes really dangerous when you’re planning in silos. Planning in silos means you don’t have any input on whether you’re on the right direction or not. Thus, when you come together it will actually become much messier than it is.

Becky Flint: There was a funny thing in the past we called “agile madness” because in the earlier days, when a team adopted agile, they thought they had managed everything. But then very quickly, they realized, it’s not the same as when the company started with three or four teams. Now, everyone’s running around trying to align things at the scrum level and it just falls apart. What’s causing that problem is planning in silos.

When we do quarterly planning at the portfolio level, we can understand the dependencies in the product functionality. So people tend to think about dependency of product functionality. But really, also from a resourcing perspective, if one team requires multiple teams, it’s important to have a tool like Dragonboat. With Dragonboat you can have a list of product features that require team A, B, C at different efforts. Therefore, when you plan it, you can already account for team A being oversubscribed. You can solve that problem collaboratively by looking at the efforts and the resourcing needs of one team and comparing it with another team’s needs all in one place.

You can see your projects or initiatives and the resourcing needs of different teams. When you add these two together with the plan, it will give you a highlight that easily identifies bottlenecks before going to the execution.

Pamela Surjadjaja: Yeah, and I have to echo the importance of planning together because that’s where you actually have collective minds to brainstorm. Also I have to emphasize what Becky was mentioning around planning and the portfolio level. It makes it much easier when things are aligned at the top, especially for larger initiatives that have maybe 10 dependencies. There’s definitely a lot of things that need to happen before you actually talk about the timeline.

Becky Flint:  You know, a lot of people who are program managers today, may or may not realize that in the past, the program manager role was defined as someone managing a basket of projects. But in reality, with agile coming, the modern project manager is not really defined in that way, especially in software. Program managers have really evolved into portfolio managers because you manage a lot more fluid teams. So for quarterly planning, for our team and multiple teams to be successful, you have to take a portfolio mindset.

I want to go down and actually talk a little bit about politics. I think we have program managers, because we interact with so many stakeholders in many different places. And eventually you will find there are a lot more perspectives, more politics happening. If someone wants to work on certain areas, how do you deal with this? I think politics started happening with maybe a 10 or 20 person company, and that gets more complicated when you get hit 100. So how do you handle undercurrents, politics, and pet projects?

Pamela Surjadjaja: I think there’s one thing to always take notice, make sure you are actually evaluating every project especially if somebody is dependent on you. For example you probably have a lot of people dependent on you. How do you measure? There’s definitely the element of figuring out the common kind of metric. Is it revenue? Is it ROI? What is it that you are assessing all these projects against? What is important for the company, and what is important for my team? You need to address it more objectively. There is no “you’re not taking my project”. It’s more of an “okay, based on these criterias and based on what is important for the company, here is what the segments are.”

The best thing you can do is be transparent with what you’re doing. Make sure your partners are also part of this journey. Use really objective metrics to evaluate and then be transparent. Therefore, if there’s any negotiation to be had, you can facilitate that and be open to the world to facilitate those discussions.

Becky Flint: I totally agree with you in terms of being transparent, because sometimes the program managers could both be a connector, or the bottleneck, or the person in the middle, right. Therefore, if we hold all the information to ourselves people might feel like you are hiding behind spreadsheets.

There’s a question from the audience, “when you have a cross team cross backlog, how do you prioritize?”

It is inherent you have different teams with different priorities because every product team or product areas have their own charter. So when you have two teams coming together, prioritizing this team’s work versus Team B’s work is challenging. The way we find out a way to manage that is adding a two step process.

The number one step is to agree on company or bigger-level goals that are going to drive growth and engagement. Once you align on a bigger level, define those goals and define allocation. Maybe spend 50% on this growth row, or 20% on the retention row.

This way, when we come to this cross team dependency we look at the goals and compare them with each other to see who drives more benefits to the goal. Then we will figure out how much to allocate. When you have different needs, different departments, different goals and cross teams, we use both allocation.

Pamela Surjadjaja  My experience is very similar. The framework we use is number one. We need to know the top level goal. We need to figure out the initiatives across teams that are contributing to SMB scores. You want to make sure that your roadmap is not just the dependencies that are on you. You also want to have some kind of allocation agreed upon.

Becky Flint: Yeah, I totally agree. There’s a related question- “how much authority does the program managers have in telling other teams what we can or cannot do?”

Pamela Surjadjaja: I think as the company grows, as your team grows, sometimes you do need to figure that out. I would say it really depends on the company. For program managers, I would say that in the absence of full technical parameters and product or engineering, you’re there to bring those insights as well, you can help make decisions.You can help because you know the context, the vision, where the team is going.

It all depends on the dynamics within the organization and the team that you’re at. It isn’t a hard line. But if something is at risk, then you have the authority to tell people. In some cases, you need to be more assertive.

Becky Flint: I totally agree with you, and I want to switch gears and go back to the allocation because I think it is tied to pre-planning. One of the challenging things for a program manager in quarterly planning is the cross team decision making. It’s easier when individual product managers make a decision on his or her own product backlog. It is harder when you go across multiple teams because everyone has a different perspective and focus.

Pamela Surjadjaja:  In terms of how we allocate resources, I think, again it comes down to the common goal. In some cases where we have a lot of people come into a single team, sometimes we have this process where we see the onboarding process. Basically, you come in, and as a part of the pre-planning, you’re pitching to the teams on what you want to do. It starts that discussion of whether it aligns with the principles of the product- it’s more like a brainstorming.

Becky Flint: It’s almost like a product discovery, and then a participation and allocation at the same time.

I would just like to componentize the three things for those not as familiar with this process.

First, product managers should continue to have their own product ideas, and backlogs and feedback and concept all the time. This shouldn’t be limited to just quarterly planning. Product managers should think all the time about what they want to do and what they want to say to their stakeholders. That’s a key component of pre-planning and allocation.

Once product managers are thinking about their product ideas, they will have implications that impact the other areas. And that’s where we think about the second part, which is the conversation between product and engineering. This can involve other areas of product and engineering to see how things come together.

The next thing to be aware of is timing. How do we decide across multiple teams, what we can do in this quarter, and allocate. This will help you to decide what can or cannot fit in this quarter and become a very transparent prioritization discussion, based on agreed upon alignment. That’s the pre planning, if you think about the three steps, the right product continues to manage their own backlog, and the product works with other areas that are dependencies for technical alignment and cohesiveness. And then finally, it will be the actual quarterly planning. You want to build a roadmap together. Aligning resources together in a roadmap prepares you for the inevitable regulations down the road, it won’t be a surprise.

Pre-planning really helps when you get into the actual quarterly planning, so that even at a meeting, you won’t be surprised with anything that anybody says. That’s the real goal of pre-planning, to be aware of what’s happening with an open channel.

Pamela Surjadjaja: I also want to address somebody’s question around what allocation means. For us, allocation, in the context of software, is literally engineering or design. Don’t forget about design because it also needs resources. If you have a source of truth, and then keep track of things, you know, every product manager has managed their own backlog, you can actually manage these workflows inside the tools. Then if you have dependencies, you call all the other teams who can see it. And if you have the tools, you can amend your product workflow in terms of backlog of product. You can conduct all this pre-planning to track these things while keeping it transparent to everyone. I personally believe it’s your responsibility to have information available to everyone. Invest in a tool where multiple teams are onboard with the tool, so they can see each other’s roadmap easily.