Quarterly Engineering Plan Template
Template for communicating where engineering spends its time and why. Copy and fill in each section.
How to Use This Template
- Name the file:
quarterly-plan-[year]-[quarter].md- Example:
quarterly-plan-2026-q2.md
- Example:
- Collect inputs first. Each team lead writes their top 3 priorities before you draft
- Review last quarter. What carried over? What did you learn?
- Fill in each section below. Delete the instructions (gray text) as you write
- Workshop with engineering leads. 3-day feedback window
- Align with product/leadership. Present themes and allocation
- Publish and kick off quarter. Review monthly. Grade at quarter-end
When to use: Every quarter. Answers "What is engineering doing and why?" for stakeholders, teams, and leadership.
Quarterly Plan: [Year] Q[1-4]
Owner: [Your name] Date: [YYYY-MM-DD] Org size: [Number of engineers] Status: Draft | Published | Archived
Context
Instructions: Set the stage in 2-3 sentences. What's the org situation? What happened last quarter? What's the most important thing leadership/product/customers need from engineering?
Example: 45-person engineering org. Post-Series B. Q1 focused on API reliability (resolved) and billing v1 (shipped). Q2 priorities: launch billing v2 for enterprise customers ($2M ARR at risk), continue reliability improvements, and ramp 10 new hires.
[Write 2-3 sentences of context.]
Themes / Bets
Instructions: List 3-5 investment themes. Each theme is a bet: "We believe spending X% on this will produce Y outcome."
Good themes: Specific, outcome-oriented ("API Reliability," "Billing v2," "Developer Experience") Bad themes: Vague ("Improvements," "Tech stuff," "Various projects")
For each theme:
- Investment % — Share of total engineering effort
- Why — Business justification in one sentence
- Connection — Link to relevant strategy or vision doc
| Theme | Investment | Why | Connection |
|---|---|---|---|
| [Theme 1] | [X]% | [Business justification] | [Link to strategy/vision] |
| [Theme 2] | [X]% | [Business justification] | [Link to strategy/vision] |
| [Theme 3] | [X]% | [Business justification] | [Link to strategy/vision] |
| [Theme 4] | [X]% | [Business justification] | [Link to strategy/vision] |
| [Theme 5] | [X]% | [Business justification] | [Link to strategy/vision] |
| Total | 100% |
Example:
| Theme | Investment | Why | Connection |
|---|---|---|---|
| Billing v2 | 40% | Enterprise customers need usage-based billing by June. $2M ARR at risk | Billing strategy |
| API Reliability | 25% | 3 incidents/month. Largest customer threatened churn | API Performance Strategy |
| Developer Experience | 20% | Hiring 10 engineers. Onboarding takes 6 weeks — can't afford the lost productivity | Eng Vision 2028 |
| Tech Debt | 15% | Auth library EOL in August. Must migrate before then | — |
| Total | 100% |
Allocation
Instructions: Map teams to themes. Show how headcount maps to the investment percentages above. Every team should know their primary and secondary focus.
| Team | Headcount | Primary Theme (%) | Secondary Theme (%) |
|---|---|---|---|
| [Team 1] | [N] | [Theme] ([X]%) | [Theme] ([X]%) |
| [Team 2] | [N] | [Theme] ([X]%) | [Theme] ([X]%) |
| [Team 3] | [N] | [Theme] ([X]%) | [Theme] ([X]%) |
| [Team 4] | [N] | [Theme] ([X]%) | [Theme] ([X]%) |
Example:
| Team | Headcount | Primary Theme (%) | Secondary Theme (%) |
|---|---|---|---|
| Payments | 8 | Billing v2 (100%) | — |
| Platform | 6 | API Reliability (70%) | Tech Debt (30%) |
| Growth | 5 | Billing v2 (60%) | Developer Experience (40%) |
| Infra | 4 | Developer Experience (75%) | Tech Debt (25%) |
Milestones
Instructions: For each theme, list 2-4 milestones. Each milestone needs:
- Owner (name, not "team")
- Due date (specific date, not "mid-quarter")
- Success criteria (how we know it's done)
Milestones should be outcomes, not activities. "Invoice generation live" not "Work on invoices."
[Theme 1] Milestones
| Milestone | Owner | Due | Success Criteria |
|---|---|---|---|
| [Outcome 1] | [Name] | [Date] | [Measurable result] |
| [Outcome 2] | [Name] | [Date] | [Measurable result] |
| [Outcome 3] | [Name] | [Date] | [Measurable result] |
[Theme 2] Milestones
| Milestone | Owner | Due | Success Criteria |
|---|---|---|---|
| [Outcome 1] | [Name] | [Date] | [Measurable result] |
| [Outcome 2] | [Name] | [Date] | [Measurable result] |
[Theme 3] Milestones
| Milestone | Owner | Due | Success Criteria |
|---|---|---|---|
| [Outcome 1] | [Name] | [Date] | [Measurable result] |
| [Outcome 2] | [Name] | [Date] | [Measurable result] |
Example:
| Milestone | Owner | Due | Success Criteria |
|---|---|---|---|
| Usage metering in production | Alice | Apr 15 | Meters track 100% of API calls |
| Invoice generation live | Alice | May 30 | First enterprise invoice sent |
| Query budget middleware deployed | Charlie | Apr 10 | All endpoints enforce 10-query limit |
| One-command local setup | Dana | Apr 30 | make dev works on fresh laptop |
Deprioritization
Instructions: List what you're explicitly NOT doing this quarter. This is the hardest and most valuable section. For each item:
- What — The thing you're not doing
- Why — Why it didn't make the cut
- Revisit — When you'll reconsider
If this section is empty, you haven't made real tradeoffs.
| What we're NOT doing | Why | Revisit |
|---|---|---|
| [Item 1] | [Reason] | [When] |
| [Item 2] | [Reason] | [When] |
| [Item 3] | [Reason] | [When] |
| [Item 4] | [Reason] | [When] |
Example:
| What we're NOT doing | Why | Revisit |
|---|---|---|
| Mobile app | No mobile revenue yet. Focus on enterprise web | Q3 planning |
| GraphQL migration | 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 | When international >20% |
Risks
Instructions: What could derail the plan? For each risk:
- Likelihood (High / Medium / Low)
- Impact (what happens if it materializes)
- Mitigation (what we'll do about it)
Focus on risks that would force you to change allocation. Not every possible thing that could go wrong.
| Risk | Likelihood | Impact | Mitigation |
|---|---|---|---|
| [Risk 1] | [H/M/L] | [What happens] | [What we'll do] |
| [Risk 2] | [H/M/L] | [What happens] | [What we'll do] |
| [Risk 3] | [H/M/L] | [What happens] | [What we'll do] |
Example:
| Risk | Likelihood | Impact | Mitigation |
|---|---|---|---|
| Billing v2 scope creep | High | Delays launch past Q2 | Freeze scope after Apr 1. Anything new → Q3 |
| Key engineer departure | Medium | API reliability stalls | Cross-train team. Document decisions weekly |
| API incidents consume reliability budget | Medium | Team stuck in reactive mode | Ring-fence 10% for incidents. Rest = planned work |
Success Criteria
Instructions: Define what good looks like BEFORE the quarter starts. Use letter grades so the quarter-end review is objective, not political.
Grade definitions:
- A: Exceeded expectations. All themes delivered. Stretch goals hit
- B: Met expectations. Major milestones delivered. Minor misses acceptable
- C: Partially met. Significant delays or scope cuts, but progress made
- F: Failed. Major themes undelivered. Plan was unrealistic or execution broke down
| Grade | Criteria |
|---|---|
| A | [What exceeding looks like] |
| B | [What meeting expectations looks like] |
| C | [What partial delivery looks like] |
| F | [What failure looks like] |
Target grade: [B / B+]
Example:
| 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 |
Monthly Check-In Log
Instructions: Review monthly. Compare actual allocation to planned. Adjust if reality changed — but document why.
Month 1 Check-In: [Date]
Actual allocation vs planned:
| Theme | Planned | Actual | Delta | Notes |
|---|---|---|---|---|
| [Theme 1] | [X]% | [X]% | [±X]% | [Why the difference] |
| [Theme 2] | [X]% | [X]% | [±X]% | |
| [Theme 3] | [X]% | [X]% | [±X]% |
Milestone status: [On track / At risk / Blocked]
Adjustments: [Any changes to allocation, milestones, or themes]
Month 2 Check-In: [Date]
[Repeat structure above]
Month 3 Check-In: [Date]
[Repeat structure above]
Quarter-End Review
Instructions: Grade yourself honestly. This feeds into next quarter's planning.
Final grade: [A / B / C / F]
Theme results:
| Theme | Planned Investment | Actual Investment | Key Result |
|---|---|---|---|
| [Theme 1] | [X]% | [X]% | [What was delivered] |
| [Theme 2] | [X]% | [X]% | [What was delivered] |
| [Theme 3] | [X]% | [X]% | [What was delivered] |
What worked:
- [1-3 bullet points]
What didn't work:
- [1-3 bullet points]
Carry-over to next quarter:
- [Items that didn't finish and need to continue]
Lessons learned:
- [What would you do differently?]
Template Checklist
Before publishing, verify:
- [ ] Context sets the stage (org size, last quarter's outcomes, key constraints)
- [ ] 3-5 themes, each with investment % and business justification
- [ ] Allocation adds to 100%
- [ ] Every team mapped to primary and secondary themes
- [ ] 2-4 milestones per theme, each with owner + date + success criteria
- [ ] Deprioritization list is non-empty (you've made real tradeoffs)
- [ ] Risks identified with mitigations
- [ ] Success criteria defined with letter grades
- [ ] Shared with engineering leads for feedback (3-day window)
- [ ] Aligned with product/leadership
- [ ] Monthly check-in dates in calendar
Review monthly. Grade at quarter-end. Feed lessons into next quarter's plan.
Back to Quarterly Plan Guide · Back to Engineering Strategy & Vision