Goal Setting
Set goals that transform you, not just keep you busy.
TL;DR
- Stretch goals change who you are - If you achieve your goal and you're the same person, you aimed too low
- Bad goal: "Improve code quality" → Good goal: "Review 50 PRs from senior engineers, build coding standards doc, reduce my PR revisions from 5 to 1"
- The transformation test: Ask "Who will I be after achieving this?" If the answer is "the same but busier," rewrite it
- Goals should scare you a little - If you're 100% confident, it's a task list, not a goal
- 90-day transformation - Each quarter should unlock a new capability that compounds over time
The Problem with Most Goals
Bad goals keep you busy. Good goals transform you.
Most people set goals like this:
- "Improve my skills"
- "Be a better engineer"
- "Contribute more to the team"
- "Work on important projects"
These aren't goals. They're vague wishes. You can check them off without changing anything about who you are or what you're capable of.
Here's the test: If you achieve your goal and someone asks "What's different about you now?", can you give a concrete answer?
- ❌ "I'm better" → Not a real transformation
- ✅ "I can now design systems for 1M users without help" → Real capability unlocked
What Makes a Goal a Stretch Goal
A stretch goal has three properties:
1. It unlocks a new capability you don't have today
Ask: "What will I be able to do at the end that I can't do now?"
Examples:
| Bad (Task List) | Good (Stretch Goal) |
|---|---|
| "Write better code" | "Write production-ready code that passes review in 1 round (currently 4 rounds)" |
| "Learn system design" | "Design and defend architecture for 6-month projects in front of 20-person eng org" |
| "Be a better PM" | "Run product discovery end-to-end without manager review - from research to launch" |
| "Improve communication" | "Present quarterly roadmap to 50-person exec meeting and get approved without revisions" |
The good examples describe a future version of you that can do things current-you cannot.
2. It makes you uncomfortable
If you're 100% confident you'll achieve it, it's not a stretch goal.
The right level of difficulty:
- 100% confident → Too easy, it's a task
- 70% confident → Stretch goal (perfect)
- 30% confident → Unrealistic, you'll give up
Example:
- Junior engineer: "Ship a feature without senior engineer pairing" (scary but achievable)
- Mid engineer: "Own platform migration affecting 10 teams" (stretches leadership skills)
- Senior engineer: "Build new org from 0 to 15 people in 6 months" (stretches hiring/scaling)
The discomfort is the signal. If it doesn't scare you a little, aim higher.
3. Success is measurable and obvious
You should know without debate whether you achieved it.
Bad (ambiguous):
- "Improve leadership"
- "Get better at debugging"
- "Ship more features"
Good (measurable):
- "Run weekly design critique for 10 people without manager backup"
- "Debug production issues in under 30 minutes (currently 2+ hours)"
- "Ship 3 features as DRI, each hitting success metrics within 2 weeks of launch"
The dinner table test: If you told a friend what you accomplished, would they understand why it mattered?
How to Set Stretch Goals: The Framework
Step 1: Start with the transformation
Question: "Who do I want to become in 90 days?"
Not "What do I want to do?" but "Who do I want to be?"
Examples:
- "The engineer who can design scalable systems independently"
- "The PM who runs product discovery without supervision"
- "The designer who influences product direction, not just takes orders"
- "The manager who builds high-performing teams, not just manages tasks"
Write this down first. This is your north star.
Step 2: Make it concrete
Question: "What would I do differently tomorrow if I already had this capability?"
Example 1: Engineer
- Transformation: "The engineer who writes production-ready code"
- What I'd do differently: Lead code reviews, ship features without 4 rounds of revisions, debug issues without escalating
Example 2: PM
- Transformation: "The PM who shapes product strategy"
- What I'd do differently: Present roadmap to execs, make prioritization calls without checking with my manager, run customer discovery that influences the roadmap
Example 3: Designer
- Transformation: "The designer who influences product direction"
- What I'd do differently: Propose features backed by research, push back on bad product ideas with data, run design sprints that generate roadmap ideas
Step 3: Define success criteria
Question: "What will exist or be different that proves I transformed?"
Use this format:
Goal: [Capability I'll unlock]
Success looks like:
- [Observable outcome 1 with number/metric]
- [Observable outcome 2 with number/metric]
- [Observable outcome 3 with number/metric]
How I'll build it:
- [Action 1 with timeline]
- [Action 2 with timeline]
- [Action 3 with timeline]Example:
Goal: Write production-ready code that passes review in 1-2 rounds
Success looks like:
- 80% of my PRs approved in ≤2 rounds (currently 20%)
- Zero P0 bugs from my code for 6 weeks post-launch
- Ship notifications feature end-to-end without senior engineer pairing
How I'll build it:
- Review 20 PRs from senior engineers, document patterns (Week 1-2)
- Build PR self-review checklist, apply to every PR (Week 3+)
- Pair with Sarah for 2 hours to learn what "good" looks like (Week 2)
- Ship notifications feature solo (Week 4-10)Step 4: Apply the transformation test
Ask yourself: "If I achieve this goal, will I be a fundamentally different person?"
Red flags (not stretch goals):
- "I'll have done more work" → Just volume, no growth
- "I'll have shipped X feature" → Task completion, not capability
- "I'll know more about Y" → Learning isn't transformation unless you apply it
Green flags (real stretch goals):
- "I'll be able to lead design reviews for 10 people" → New capability
- "I'll be trusted to make product decisions alone" → New level of responsibility
- "I'll be the go-to person for system design questions" → New role in the team
Common Mistakes
Mistake 1: Setting activity goals instead of outcome goals
❌ Activity goal: "Attend 10 talks on system design" ✅ Outcome goal: "Design a system that handles 1M requests/sec and present it to the team"
Why it matters: Activity goals measure busyness. Outcome goals measure transformation.
Mistake 2: Making goals too comfortable
❌ Too easy: "Ship 2 small features" (you already do this) ✅ Stretch: "Ship 2 features as DRI with no senior engineer pairing" (proves independence)
The test: If your manager says "that's exactly what I expected from you," it's not a stretch goal.
Mistake 3: Confusing effort with transformation
❌ Effort-based: "Work 60 hours a week" ✅ Transformation-based: "Reduce feature delivery time from 8 weeks to 4 weeks by cutting unnecessary meetings and improving specs"
Why it matters: Working harder doesn't make you better. Working differently does.
Mistake 4: Setting too many goals
Pick 1-3 stretch goals per quarter. That's it.
Transformation takes focus. If you have 10 goals, you're spreading yourself too thin.
Formula:
- 1 big stretch goal (main transformation)
- 1-2 supporting goals (skills needed for the main goal)
- 0 "nice to haves"
Example for junior engineer:
Main stretch goal:
- Ship notifications feature end-to-end without senior engineer pairing
Supporting goals:
- Reduce PR revision rounds from 4+ to 1-2 (need this to ship independently)
- Debug production issues without escalating (need this for on-call)
Examples: Bad vs Good Goals
Example 1: Junior Engineer
| Bad | Why it's bad | Good | Why it's good |
|---|---|---|---|
| "Get better at coding" | Vague, no measure | "Reduce PR revisions from 5 rounds to 1-2 by learning team patterns and building a review checklist" | Specific, measurable, describes how |
| "Learn React" | Just learning, no application | "Build user dashboard using React, ship to production with <2% error rate" | Applied learning with measurable outcome |
| "Write more tests" | Activity, not outcome | "Increase test coverage from 40% to 80%, catch 3 bugs in staging before production" | Outcome-focused with impact |
Example 2: Mid-Level PM
| Bad | Why it's bad | Good | Why it's good |
|---|---|---|---|
| "Do more user research" | Activity, no outcome | "Run 20 user interviews, synthesize into 2 validated product bets that get added to roadmap" | Research → insights → impact |
| "Improve specs" | Vague | "Reduce spec revision rounds from 4+ to 1-2 across 10 specs by creating eng/design checklist" | Measurable improvement with method |
| "Ship features faster" | No baseline, unclear | "Reduce feature delivery from 8 weeks to 4 weeks by cutting unnecessary review cycles" | Specific numbers, clear mechanism |
Example 3: Senior Engineer
| Bad | Why it's bad | Good | Why it's good |
|---|---|---|---|
| "Mentor junior engineers" | Activity, no outcome | "Mentor 2 junior engineers to ship features independently (currently need pairing)" | Transformation in others, measurable |
| "Improve system architecture" | Vague | "Reduce API latency from 800ms to <200ms p95 by implementing caching and query optimization" | Specific numbers, clear improvement |
| "Lead more projects" | Just doing more work | "Lead platform migration affecting 10 teams with zero production incidents and <10% eng time overhead" | Leadership proven by outcomes |
The 90-Day Transformation Mindset
Each quarter should unlock something that compounds.
Think about it:
- Q1: You learn to ship features independently
- Q2: You learn to lead small projects (builds on Q1)
- Q3: You learn to design systems (builds on Q1 + Q2)
- Q4: You mentor others to do what you learned in Q1-Q3
This is compound growth. Each quarter's transformation enables the next quarter's stretch goal.
Bad approach: Random goals every quarter with no connection
- Q1: "Improve code quality"
- Q2: "Learn Kubernetes"
- Q3: "Do more meetings"
- Q4: "Ship faster"
Good approach: Each goal builds toward a bigger transformation
- Q1: "Ship features independently without pairing" (foundation)
- Q2: "Own end-to-end feature including design decisions" (adds product thinking)
- Q3: "Lead project affecting 3 teams" (adds leadership)
- Q4: "Design system architecture presented to 20-person eng org" (adds strategic thinking)
By end of year: You went from junior engineer who needs pairing → mid-level engineer who leads cross-team projects and influences architecture.
How to Know If Your Goal Is Good
Use this checklist:
✅ Good stretch goal if:
- [ ] Scares you a little (70% confident, not 100%)
- [ ] Describes a capability you don't have today
- [ ] Has specific success criteria with numbers
- [ ] Passes the dinner table test (you can explain why it matters)
- [ ] If achieved, people would notice you're different
- [ ] Builds on previous quarters' growth
❌ Not a stretch goal if:
- [ ] You're 100% confident you'll achieve it
- [ ] It's just "do more of what I already do"
- [ ] Success is vague ("improve," "better," "more")
- [ ] It's an activity, not an outcome
- [ ] Achieving it wouldn't change your capabilities
- [ ] It's isolated from your long-term growth
Action: Write Your Stretch Goal
Use this template:
Quarter: Q[X] 202X
Transformation:
In 90 days, I will be: [describe the future version of you]
Stretch Goal:
[One sentence: capability you'll unlock]
Success looks like:
1. [Measurable outcome with number]
2. [Measurable outcome with number]
3. [Measurable outcome with number]
How I'll build it:
- Month 1: [Focus area]
- Month 2: [Focus area]
- Month 3: [Focus area]
How I'll know I transformed:
If I had this capability today, tomorrow I would: [specific example]Example filled out:
Quarter: Q2 2024
Transformation:
In 90 days, I will be: The engineer who writes production-ready code that ships without multiple revision rounds
Stretch Goal:
Write production-ready code that passes review in 1-2 rounds (currently 4+ rounds)
Success looks like:
1. 80% of PRs approved in ≤2 rounds (currently 20%)
2. Ship notifications feature end-to-end without senior engineer pairing
3. Zero P0 bugs from my code for 6 weeks post-launch
How I'll build it:
- Month 1: Study patterns - review 20 PRs from senior engineers, build review checklist
- Month 2: Apply patterns - use checklist on every PR, pair with Sarah once for feedback
- Month 3: Prove it - ship notifications feature solo with clean review process
How I'll know I transformed:
If I had this capability today, tomorrow I would: Start leading code reviews for other junior engineers, take features from spec to production without constant check-ins, be trusted for on-call rotationRelated
- Quarterly 1:1 Framework - Use stretch goals in your quarterly planning
- Rock Sizing - How to prioritize quarterly goals
- Career Levels - What capabilities define each level
Remember: If you achieve your goal and you're the same person, you aimed too low. Stretch goals transform you.