Quarterly Engineering Plan
How to write quarterly plans that answer: "Where is engineering spending its time and why?"
TL;DR
- Quarterly plan = execution bridge. Connects strategy (problem-solving) and vision (long-term alignment) to "what are we actually doing this quarter?"
- Themes, not task lists. Organize around 3-5 investment themes ("API reliability," "developer experience"), not Jira tickets
- Allocation is the strategy. Where you spend time is what you believe. Make it explicit: "60% product, 25% platform, 15% tech debt"
- Say what you're NOT doing. Deprioritization is the hardest and most valuable part
- Bottom-up, then top-down. Collect team plans first, then synthesize into org-level themes
- Review = accountability. Grade yourself at quarter-end. Did allocation match intent?
Quarterly Plan vs Strategy vs Vision
| Quarterly Plan | Strategy | Vision | |
|---|---|---|---|
| Purpose | Direct execution for the quarter | Solve a specific problem | Align teams long-term |
| Question | "Where are we spending time and why?" | "How do we fix this?" | "What does the future look like?" |
| Tone | Concrete, operational | Practical, decisive | Aspirational, directional |
| Timeframe | 1-2 quarters (3-6 months) | 3-12 months | 2-3 years |
| Detail | Specific themes, allocations, milestones | Diagnosis, policies, actions | Illustrative, broad strokes |
| Quantity | One per org/group per quarter | Many (one per problem) | Few (one per area, max) |
| Tradeoffs | Explicit (we fund X, not Y) | Explicit (we choose X over Y) | Implicit (we move toward X) |
| Use case | "What is engineering doing in Q2?" | "How do we scale the API?" | "What does engineering look like in 2028?" |
When to write a quarterly plan: You're entering a new quarter and need to communicate what engineering will focus on, how effort is distributed, and what's explicitly deprioritized.
Structure
A quarterly plan has six parts:
- Themes / Bets — The 3-5 areas where you're investing time
- Allocation — How engineering effort is distributed (percentages)
- Milestones — What "done" looks like at quarter-end
- Deprioritization — What you're explicitly NOT doing
- Risks — What could derail the plan
- Success Criteria — How you'll grade the quarter
Example: Q2 2026 Engineering Plan
Context: 45-person engineering org. Post-Series B. Product-market fit established. Key challenges: API reliability issues (3 incidents/month), slow onboarding (6 weeks to first commit), and pressure to ship billing v2.
Themes / Bets
| Theme | Investment | Why |
|---|---|---|
| Billing v2 | 40% | Revenue blocker. Enterprise customers need usage-based billing by June. $2M ARR at risk |
| API Reliability | 25% | 3 incidents/month. Largest customer threatened churn. Ties to API Performance Strategy |
| Developer Experience | 20% | Onboarding takes 6 weeks. Hiring 10 engineers in Q2 — can't afford 60 weeks of lost productivity |
| Tech Debt | 15% | Auth system on deprecated library. Migrate before EOL in August |
Allocation
Billing v2: ████████████████████ 40%
API Reliability: █████████████ 25%
Developer Experience: ██████████ 20%
Tech Debt: ████████ 15%Team mapping:
| Team | Primary Theme | Secondary Theme |
|---|---|---|
| Payments (8 eng) | Billing v2 (100%) | — |
| Platform (6 eng) | API Reliability (70%) | Tech Debt (30%) |
| Growth (5 eng) | Billing v2 (60%) | Developer Experience (40%) |
| Infra (4 eng) | Developer Experience (75%) | Tech Debt (25%) |
Milestones
| Theme | Milestone | Owner | Due | Success Criteria |
|---|---|---|---|---|
| Billing v2 | Usage metering in production | Alice | Apr 15 | Meters track 100% of API calls |
| Billing v2 | Invoice generation live | Alice | May 30 | First enterprise invoice sent |
| Billing v2 | Self-service billing portal | Bob | Jun 15 | Customers can view/pay invoices |
| API Reliability | Query budget middleware deployed | Charlie | Apr 10 | All endpoints enforce 10-query limit |
| API Reliability | Redis caching layer live | Charlie | May 1 | Cache hit rate >80% |
| API Reliability | Zero incidents for 30 days | Charlie | Jun 15 | Incident count = 0 for trailing 30 days |
| Dev Experience | One-command local setup | Dana | Apr 30 | make dev works on fresh laptop |
| Dev Experience | Onboarding guide v2 | Dana | May 15 | New hires ship code in week 1 |
| Tech Debt | Auth library migration | Eve | May 30 | Old library removed. Zero auth-related incidents |
Deprioritization
| What we're NOT doing | Why | Revisit |
|---|---|---|
| Mobile app | No mobile revenue yet. Focus on enterprise web | Q3 planning |
| GraphQL migration | Nice-to-have but won't move revenue or reliability metrics | Q4 earliest |
| Design system overhaul | Current UI is functional. Not a growth bottleneck | Q3 if hiring design eng |
| Multi-region deployment | Only 5% of users outside US. Premature optimization | When international >20% |
Risks
| Risk | Likelihood | Impact | Mitigation |
|---|---|---|---|
| Billing v2 scope creep | High | Delays launch past Q2 | Freeze scope after Apr 1. Anything new → Q3 |
| Key engineer departure (Charlie) | Medium | API reliability stalls | Cross-train Platform team. Document decisions weekly |
| API incidents consume reliability budget | Medium | Reliability team reactive, not proactive | Ring-fence 10% of reliability time for incidents. Rest = planned work |
| New hire ramp slower than expected | Low | Dev experience theme under-resourced | Pair new hires with seniors. Accept slower progress on onboarding guide |
Success Criteria
At quarter-end, we grade ourselves:
| Grade | Criteria |
|---|---|
| A | Billing v2 live with paying customers. Zero API incidents for 30 days. New hires ship in week 1 |
| B | Billing v2 in beta. API incidents ≤1/month. Onboarding improved to 3 weeks |
| C | Billing v2 delayed but scoped. API incidents ≤2/month. One-command setup works |
| F | Billing v2 not started. API incidents unchanged. No onboarding improvement |
Target: B+ or better.
Good vs Bad Quarterly Plans
| Bad (vague) | Good (specific) |
|---|---|
| "Improve reliability" | "API Reliability: 25% of eng time. Goal: zero incidents for 30 days by Jun 15" |
| "Work on tech debt" | "Auth library migration: 15% of eng time. Eve owns. Done by May 30" |
| "Ship features" | "Billing v2: 40% of eng time. Three milestones. First enterprise invoice by May 30" |
| "Support growth" | "Developer Experience: 20%. One-command setup by Apr 30. New hires ship in week 1 by May 15" |
| No deprioritization section | "Explicitly NOT doing: mobile app, GraphQL migration, design system, multi-region" |
| "We'll be flexible" | "Scope freeze Apr 1. New requests → Q3 unless P0 incident" |
How to Write It
Bottom-Up Process (recommended)
Week 1: Collect inputs
- Each team lead writes: "Our top 3 priorities for next quarter and why"
- Collect active strategies — what problems are we mid-solving?
- Review last quarter's plan — what carried over? What did we learn?
- Gather stakeholder requests — what does product/sales/leadership need?
Week 2: Synthesize themes
- Group team priorities into 3-5 org-level themes
- Assign rough allocation percentages (must total 100%)
- Draft deprioritization list — what didn't make the cut?
- Identify key milestones per theme
Week 3: Workshop and finalize
- Share draft with engineering leads. 3-day feedback window
- Present to product/leadership for alignment
- Finalize milestones, owners, dates
- Publish and kick off quarter
Top-Down Process (when speed matters)
- Leadership defines 3-5 themes based on company priorities
- Engineering leadership assigns allocation percentages
- Team leads map their teams to themes
- Milestones drafted in 2-day sprint
- Published with 1-day feedback window
Common Mistakes
| Mistake | Fix |
|---|---|
| Too many themes (>5) | Force-rank and cut. 3-5 themes max. More = no focus |
| Allocation doesn't add to 100% | It's a budget. Everything must fit. If you add something, cut something |
| No deprioritization section | This is the hardest and most valuable part. List what you're NOT doing |
| Milestones without owners | Every milestone: name + date. No "team will handle" |
| Plan written by one person | Bottom-up: collect team inputs first, then synthesize |
| No connection to strategy/vision | Reference active strategies. Show how themes advance the vision |
| No success criteria | Define grades (A/B/C/F) upfront. Grade yourself at quarter-end |
| Treating it as immutable | Review monthly. Adjust allocation if reality changes — but document why |
| Confusing plan with backlog | Themes and milestones, not Jira tickets. Stay at the right altitude |
How to Know It's Working
| Signal | What it means |
|---|---|
| Teams can explain their quarter in 30 seconds | Working — plan is clear and internalized |
| Allocation matches actual time spent (±10%) | Working — plan reflects reality |
| Stakeholders stop asking "what is eng working on?" | Working — plan answers the question |
| Deprioritization prevents scope creep | Working — saying no is easier with a written plan |
| Quarter-end grade is B or better | Working — execution matches intent |
| Teams reference the plan when making tradeoffs | Working — it's a decision-making tool |
| New requests get evaluated against themes | Working — plan provides a filter |
| Signal | What it means |
|---|---|
| Allocation is wildly off from actual time | Not working — plan is fiction. Investigate why |
| No one can name the themes | Not working — plan isn't communicated or isn't memorable |
| Everything is "high priority" | Not working — no real tradeoffs made |
| Deprioritization list is empty | Not working — you're not making hard choices |
| Quarter-end grade is consistently C or F | Not working — either plan is unrealistic or execution is broken |
Review the plan monthly. Grade yourself at quarter-end. If the plan didn't guide decisions, simplify it next quarter.
Quarterly Plan Template
Use this to write your own quarterly engineering plan. Copy and fill in.
File: quarterly-plan-[year]-[quarter].md
Example: quarterly-plan-2026-q2.md
References
- Engineering Strategy & Vision — How strategies and visions connect to quarterly plans
- Strategy Template — For specific problems referenced in your themes
- Vision Template — For long-term direction your plan should advance
- Quarterly Plan Template — Fillable template
- Rock Sizing — How to scope quarterly initiatives
- DRI Responsibilities — Who owns what during the quarter