Every fall, engineering organizations start the same ritual. Templates go out. Teams write up everything they want to do next year. Leadership reviews a stack of decks, trims some items, and declares the plan done. By February, a third of it has quietly been abandoned and nobody can remember why those items made the cut in the first place.
I don't think annual planning is a waste of time. Done well, it's one of the few moments when an organization makes trade-offs on purpose instead of by accident. But a lot of planning cycles are optimized for producing a document, not a decision. Here is how I try to keep the process useful.
Start From Capacity, Not Ambition
Most planning templates ask teams what they want to build. Very few ask what they can actually build. That gap is where most plans fail.
Before any roadmap conversation, I want a rough capacity picture for each team: headcount, expected attrition and hiring, and how much time disappears into work that isn't on any roadmap. On infrastructure teams that last category is large. On-call, incident follow-ups, security patching, customer escalations, dependency upgrades and internal support can easily take a third of a team's time or more. If the plan assumes 100% of engineering hours go to new work, it is wrong before it starts.
The simplest version I've found works: look at the last two or three quarters, estimate what fraction of each team's effort went to roadmap work, and plan against that fraction. It's not precise. It is far more honest than the default.
Plan the Dependencies, Not Just the Projects
Teams usually plan in isolation, which means each team's plan looks reasonable on its own. The problems show up where plans touch. Team A's top priority depends on an API that's priority seven for Team B. Three teams all assume the platform team will deliver something in Q1. A security review that every launch needs has one reviewer.
The most valuable thing a TPM can do during planning is draw those lines early. I ask each team to list what they need from other teams and when, and then I read the lists side by side. Mismatches surface quickly. It's much cheaper to resolve "you need it in March, they planned it for September" in October than it is to discover it in March.
When there are conflicts, the answer isn't always "the other team must move." Sometimes the dependent project should slip. Sometimes the scope should shrink. The point is to make that decision in the planning room with the right people present, not in a hallway six months later.
Fewer Commitments, Clearer Ones
A plan with forty top priorities has no priorities. I push teams toward a short list of firm commitments, a second tier of things they'll do if capacity allows, and an explicit list of things they are choosing not to do this year.
That last list is the one people resist and the one that helps most. Writing down "we are not doing X" ends a lot of recurring debates. It also gives stakeholders a clear signal early, so they can make other arrangements instead of waiting on something that was never going to happen.
For each firm commitment, I want three things written down: what done looks like, how we'll know it worked, and who owns it. Not a team. A person. Shared ownership in a planning doc usually means no ownership by the second quarter.
Leave Room for What You Can't Predict
Every year brings work nobody planned for. A major vendor changes its licensing. A critical vulnerability lands in a component you depend on. A large customer needs something urgently. An operating system reaches end of support faster than the migration plan assumed. None of these are rare events. Each one is unpredictable on its own, but the fact that something like them will happen is close to certain.
I'd rather plan for that explicitly with an unallocated buffer than pretend it won't happen and then cut roadmap work in a panic. How big the buffer should be depends on the team. Infrastructure and security teams need more than most product teams. The size matters less than the fact that it is visible and agreed on, so that pulling from it is a normal decision rather than a crisis.
Make the Plan a Living Thing
The annual plan should be revisited every quarter, briefly and on purpose. Not a full replanning exercise, just three questions: what changed, which commitments are at risk, and what are we going to stop or delay to absorb it. If those conversations happen regularly, the February drift I described at the top turns into a series of small, deliberate adjustments instead of silent abandonment.
I also keep a simple record of what each quarter's review decided and why. A year later, when someone asks why a project was dropped, there's an answer. That record is also the best input for next year's planning, because it shows how far reality ended up from the plan and which kinds of work kept getting pushed.
What I Watch For
A few warning signs tell me a planning cycle has turned into theater. Plans that nobody outside the team reads. Roadmaps with dates but no owners. Every team reporting green at the first quarterly check-in. Dependencies that appear in one team's plan but not in the plan of the team expected to deliver them.
None of these are hard to fix once you see them. Planning works when it produces a small number of clear decisions that people actually use to say yes and no for the rest of the year. Everything else is formatting.