Quarterly 1:1
What this is for:
Every quarter, we sit down and get clear on what you want to achieve and how to make it happen. This doc is your plan.
Three months from now, what will you have built? What will you have learned? What will you be able to do that you can't do today? Write that down here. Be specific - the more concrete you are, the easier it is to know if you succeeded.
This isn't about making promises you can't keep. It's about painting a picture of success and working backward to figure out how to get there. Start with where you want to be, then map the path.
How to think about it:
Great goals are specific enough that you'll know without question whether you hit them. "Ship the new payment system" beats "work on payments". "Launch user research program with 20 interviews" beats "do more research". "Reduce design revision cycles from 5 to 2" beats "improve design quality".
Each goal should pass the dinner table test: if you told a friend at dinner what you accomplished this quarter, would they understand why it mattered? "I launched a feature that increased conversion by 15%" lands. "I improved my work" doesn't.
Career development is the same. Don't write "become better at my job" - write what you'll be able to do. Run a design critique with 10 people. Lead product discovery without your manager. Present roadmap to executives. Ship a feature end-to-end. The more specific, the more useful.
Read the examples below to see what this looks like in practice.
Quarter: Q[X] 20XX Person:
Goals
Pick 3 things that, if you nail them, make this quarter a win. What will exist at the end that doesn't exist now?
Think: shipped features, numbers that moved, capabilities you unlocked, problems you solved.
Examples of strong goals:
- "Ship payments v2 to production handling 100% of transactions" (not "work on payments")
- "Launch design system with 15 components adopted by 3 teams" (not "improve design consistency")
- "Run 20 user interviews and ship 2 validated product bets" (not "do more research")
- "Reduce feature spec revision rounds from 4 to 1" (not "write better specs")
- "Hire 2 senior engineers with start dates before Q3" (not "help with hiring")
Goal: One liner - verb + noun + outcome
- Why it matters: Business or team impact in one sentence
- Success looks like: Number, shipped thing, or observable change
Goal: One liner - verb + noun + outcome
- Why it matters: Business or team impact in one sentence
- Success looks like: Number, shipped thing, or observable change
Goal: One liner - verb + noun + outcome
- Why it matters: Business or team impact in one sentence
- Success looks like: Number, shipped thing, or observable change
Actions This Quarter
For each goal, break it into steps. What happens in month 1? Month 2? Month 3?
Be specific - use dates, numbers, milestones. "Ship X by Week 4" beats "work on X". "Reduce from 800ms to 200ms by Month 2" beats "improve performance". If you can't break it down, the goal might not be concrete enough.
Goal 1:
- Action 1 (Week X-Y or Month)
- Action 2 (Week X-Y or Month)
- Action 3 (Week X-Y or Month)
Goal 2:
- Action 1 (Week X-Y or Month)
- Action 2 (Week X-Y or Month)
- Action 3 (Week X-Y or Month)
Goal 3:
- Action 1 (Week X-Y or Month)
- Action 2 (Week X-Y or Month)
- Action 3 (Week X-Y or Month)
Support Needed
What do you need from me to make this happen? Be direct. "Budget approval for $5K Redis" is useful. "More support" is not.
Career Development
By the end of this quarter, what will you be able to do that you can't do today?
Don't write "get better at X". Write the thing you'll do that proves you got better. "Run design critique for 10 people without help" beats "improve leadership". "Present product strategy to executives" beats "improve communication". "Ship a feature end-to-end as DRI" beats "take more ownership". "Debug production issues in 30 minutes" beats "learn debugging".
Think: if you had this capability today, what would you do differently tomorrow?
- By end of quarter, I will be able to: Specific capability you'll have
- How I'll build it: The project, training, or practice that gets me there
- How we'll know it worked: What I'll ship or do that proves I have this capability
Example
Quarter: Q2 2024 Person: Alex Chen
Goals
Goal: Ship payments v2 by end of Q2
- Why it matters: Unlocks enterprise customers worth $2M ARR
- Success looks like: 100% of transactions processed through new system
Goal: Reduce API latency to sub-200ms p95
- Why it matters: Current 800ms is causing 15% cart abandonment
- Success looks like: p95 latency < 200ms across all endpoints
Goal: Build team from 3 to 5 engineers
- Why it matters: Current team underwater with maintenance debt
- Success looks like: 2 senior engineers hired and onboarded
Actions This Quarter
Goal 1:
- Complete Stripe migration by Week 4
- Run parallel processing for 2 weeks (Week 5-6)
- Full cutover by Week 8
Goal 2:
- Database query optimization (Week 1-3)
- Implement Redis caching layer (Week 4-6)
- Load testing and tuning (Week 7-8)
Goal 3:
- Job descriptions live by Week 1
- First offers out by Week 6
- Start dates before Q3
Support Needed
- Need design partner for Stripe migration edge cases
- Budget approval for Redis infrastructure ($5K/month)
- Recruiting bandwidth from HR for hiring pipeline
Career Development
- By end of quarter, I will be able to: Design and defend architecture for 6-month projects in front of 20-person eng org
- How I'll build it: Lead payments v2 design reviews (8 sessions), present architecture monthly to eng org, get feedback from Staff+ engineers
- How we'll know it worked: Payments v2 architecture approved with zero major revisions, able to answer scalability questions without help
Example 2: Product Manager
Quarter: Q2 2024 Person: Maria Santos
Goals
Goal: Launch checkout redesign that increases conversion from 8% to 12%
- Why it matters: Each 1% improvement = $500K annual revenue
- Success looks like: New checkout live, 12%+ conversion sustained for 2 weeks post-launch
Goal: Build user research practice - run 20 interviews and validate 2 product bets
- Why it matters: Current roadmap based on gut feel, not customer insight
- Success looks like: 20 interviews completed, 2 features specced and prioritized from research findings
Goal: Reduce feature spec revision rounds from 4+ to 1-2
- Why it matters: Specs taking 3 weeks means we ship 40% slower than competitors
- Success looks like: 80% of specs approved in ≤2 rounds, measured across 10 specs
Actions This Quarter
Goal 1:
- Run A/B test on current checkout to establish baseline (Week 1-2)
- Ship redesign to 10% of users (Week 3-4)
- Ramp to 50% and monitor metrics (Week 5-6)
- Full rollout if metrics hold (Week 7-8)
Goal 2:
- Recruit 20 users for interviews (Week 1-2)
- Conduct interviews, 5 per week (Week 3-6)
- Synthesize findings into 3 product bets (Week 7-8)
- Write specs for top 2 bets, get eng buy-in (Week 9-10)
Goal 3:
- Review last 10 specs to identify common revision patterns (Week 1)
- Create spec template with eng/design checklist (Week 2)
- Use template on every spec going forward (Week 3+)
- Monthly review with team on spec quality trends
Support Needed
- Design resources for checkout redesign (4 weeks of dedicated designer time)
- Budget for user research incentives ($100 x 20 = $2K)
- Engineering lead to review spec template and provide feedback (2 hours in Week 2)
Career Development
- By end of quarter, I will be able to: Run end-to-end product discovery and ship features without manager review at every step
- How I'll build it: Own checkout redesign from research to launch, run 20 user interviews, present findings to exec team, ship feature and measure impact
- How we'll know it worked: Checkout feature shipped with >12% conversion, manager didn't need to step in at any stage, exec team approved research findings
Example 3: Junior Engineer
Quarter: Q3 2024 Person: Jamie Rodriguez
Goals
Goal: Ship user notification system end-to-end without senior engineer pair programming
- Why it matters: Proves I can own features independently, unblocks team from babysitting me
- Success looks like: Notifications live in production, zero P0 bugs for 2 weeks post-launch
Goal: Reduce my PR revision cycles from 4+ rounds to 1-2 rounds
- Why it matters: Currently blocking team velocity - my PRs take 3x longer than other engineers
- Success looks like: 80% of my PRs approved in 2 rounds or less (measured over 20 PRs)
Goal: Debug production issues without escalating to senior engineers
- Why it matters: Currently wake up seniors for issues I should handle, makes me unreliable for on-call
- Success looks like: Handle 5 production issues start-to-finish during on-call rotation
Actions This Quarter
Goal 1:
- Write tech spec and get approval (Week 1-2)
- Build notification service backend (Week 3-5)
- Build frontend components and integration (Week 6-8)
- Testing and launch (Week 9-10)
Goal 2:
- Read team style guide and write personal checklist (Week 1)
- Self-review every PR using checklist before requesting review (Week 2 onwards)
- Ask for pairing session on "what good code looks like" with Sarah (Week 2)
- Track PR rounds in spreadsheet, review monthly with manager
Goal 3:
- Shadow senior engineer on 3 production incidents (Month 1)
- Document runbook for 5 common issues (Month 2)
- Take on-call rotation with senior backup (Month 3)
Support Needed
- Pair with Sarah for 2 hours in Week 2 to learn code review best practices
- Access to production logs and monitoring dashboards
- Senior engineer as backup during my first on-call week (Month 3)
Career Development
- By end of quarter, I will be able to: Write production-ready code that passes review in 1-2 rounds like other mid-level engineers
- How I'll build it: Study team's style guide, build personal PR checklist, review 10 recent PRs from senior engineers to learn patterns, apply checklist to every PR
- How we'll know it worked: 80% of PRs approved in ≤2 rounds (currently 20%), measured across 20 PRs