The annual plan is one of the highest-leverage artifacts an engineering manager produces. Done well, it sets expectations, surfaces dependencies, and aligns the team for a year. Done poorly, it becomes a wishlist that everyone ignores by Q2. The difference is mostly in the negotiation, not the document.
Inputs you need before drafting
- Company strategic priorities for the year (from your skip-level, CTO, or all-hands deck)
- Product roadmap (from your PM partner)
- Headcount plan (current + planned hires + attrition assumption)
- Open roles, open requisitions, hiring market reality
- Carry-over commitments from last year
- Top engineering health issues (debt, on-call, hiring quality)
If any of these are missing, your plan is fiction. Spend the first week chasing inputs.
Themes, not features
An annual plan is too coarse for feature-level commitments. Anchor it on themes:
- “Reliability — reduce SEV-2 incidents 50%”
- “Onboarding — new-engineer time-to-first-PR from 12 days to 5”
- “Search platform — replace legacy Solr cluster with managed service”
- “Mobile — ship the next-gen iOS architecture”
For each theme, name an outcome (measurable), an owner (single throat), and a rough quarter. Save feature-by-feature detail for quarterly planning.
The capacity model
Translate themes into person-quarters. Be aggressive about overhead:
- Subtract on-call rotations
- Subtract interviewing and hiring overhead
- Subtract one full quarter of slack for unknowns
- Subtract ~20% for maintenance, support, and small ad-hoc requests
Most first-time annual plans assume 100% feature-bandwidth and miss by 50%. Be honest in the model and the plan will hold.
Surface dependencies
Themes often depend on other teams: platform, infra, design system, security. Pull a list of cross-team dependencies and email those owners:
- “Theme X depends on a feature your team owns. Are you committing to ship it in Q2?”
- “If your team slips, we will need to descope theme X. Want to align before plans are locked?”
The most common annual-plan failure is silent cross-team assumptions. The cheapest insurance is a written confirmation.
Risks and contingencies
- What if hiring slips by 2 quarters?
- What if a SEV-1 in Q1 burns 4 person-weeks of unplanned work?
- What if the legacy migration discovers a major surprise?
For each top risk, name a mitigation or a descope candidate. “We will descope theme Y if hiring slips” is a legitimate plan; “we will work harder” is not.
The reviews that matter
- Your manager: reviews capacity assumptions and theme priorities. Catches misalignment with leadership.
- Product partner: reviews scope and trade-offs. Resolves feature-vs-platform tension.
- Tech lead / staff IC: sanity-checks technical estimates and dependencies.
- Skip-level: validates the plan against company strategy.
- Team: the team reviews the plan after the leadership reviews. They will surface omissions and feasibility issues you missed.
The mid-year update
Re-plan in Q2 or Q3 — formally. The world will have changed. Document what shipped, what slipped, what was added. Re-baseline themes for the second half. Skipping this step is the most common reason annual plans become irrelevant by Q3.
Pitfalls
- Over-specifying features in the annual document; lock those at quarterly cadence
- Pretending hiring will save the plan; assume current capacity
- Hiding risks to make the plan look better; this is detected within a quarter and costs you trust
- Skipping the team review; you miss feasibility issues that surface only at the leaf level
Frequently Asked Questions
Should the annual plan have OKRs?
Theme outcomes can serve as annual KRs. Quarterly OKRs flow from the annual themes. Avoid OKRs that are themselves annual unless your company genuinely operates on annual cycles.
How do I plan when leadership won’t commit to direction?
Build the plan with explicit “if-then” branches. Force the conversation that produces a decision. Sometimes the lack of clarity is the actual problem to solve.
What format does the document take?
One-pager top, themes section middle, capacity model bottom. Less than 10 pages total. If it is longer, no one above your manager will read it.