Every December, someone writes "ship faster" and "improve code quality" on a whiteboard and calls it next year's engineering team goals. Every February, nobody remembers the whiteboard existed. I've run engineering teams long enough to know the problem isn't ambition, it's that the goals were never actually owned by the people expected to hit them.
Goals a manager writes alone and hands down get nodded at in the all-hands and ignored by Tuesday. Goals a team co-authors, with numbers they picked and can defend, tend to survive contact with a busy quarter. The difference isn't the content of the goal. It's who's holding the pen when it gets written.
Here's the structure I actually use, three categories, each with a concrete target the team helps set, reviewed monthly instead of judged once in December.
Delivery goals: commitments, not velocity points
Skip story points and velocity charts as a goal target. Velocity measures how a team estimates, not how a team performs, and optimizing for it teaches people to inflate estimates. What you actually want is a commitment the team believes it can hit and a track record of hitting it.
A delivery goal that works: "80% of sprint commitments shipped on the committed sprint, measured over a rolling quarter." Not 100%, because 100% just means the team is sandbagging estimates to guarantee an easy win. 80% leaves room for the reality that some weeks a dependency breaks or a client escalation eats two days.
Let the team set the number. If they push back and say 80% is unrealistic given current staffing, that's useful information for you, not a negotiation to win. A team that argues for 65% and hits it consistently is more valuable than a team that agrees to 90% and misses it every sprint while quietly resenting the target.
Quality goals: defects and rework, not lines or coverage
Line-count metrics and raw test coverage percentages are the fastest way to get gamed metrics instead of better software. A developer told to hit 80% coverage will write tests that touch the line without testing the behavior. I've seen it happen inside a month.
Better quality targets:
| Metric | Why it works |
|---|---|
| Production incidents per release | Ties directly to customer impact, hard to game |
| Rework rate (tickets reopened within 2 weeks) | Catches "done" work that wasn't actually done |
| Time from bug report to fix in production | Measures responsiveness, not just volume |
Set a baseline first. If you don't know your current rework rate, spend one sprint just measuring it before you set a target against it. Guessing at a starting point is how you end up with a goal that's either trivially easy or quietly impossible.
Learning goals: one skill, tied to a real project
This is the category most teams skip, and it's the one that keeps senior engineers from leaving out of boredom. Pick one technical skill gap the team actually has, not a trendy technology nobody needs yet, and tie it to a real piece of upcoming work rather than a training course nobody finishes.
If your team is about to build something that needs proper staging and rollback discipline, that's your learning goal for the quarter, not "learn Kubernetes" in the abstract. I've written more on why staging environments specifically tend to be the gap that bites teams hardest: Why Your Business Needs a Staging Environment.
If your team's next quarter involves evaluating AI coding tools, make that the learning goal, with a concrete deliverable: a written recommendation for which tool the team adopts and why. I cover how to run that evaluation in AI Coding Assistants Compared: Picking for Your Team.
How to run the co-authoring session
Block 90 minutes with the full team, not a subset. Bring last quarter's actual numbers, not opinions, whatever delivery and defect data you have even if it's rough. Ask three questions in order:
- What got in the way of shipping on time last quarter, specifically?
- What broke in production that shouldn't have, and why?
- What's one thing we don't know how to do yet that next quarter's work will require?
The goals fall out of the answers. Your job is to turn the discussion into three numbers with owners, not to arrive with the numbers pre-written.
Reviewing monthly, not judging in December
Annual goals fail partly because a year is too long a feedback loop for anyone to adjust course. Put a 30-minute check-in on the calendar monthly. Not a performance review, a status check: are we tracking toward the number, and if not, is the number wrong or is the execution wrong. Both are valid answers. Adjusting a goal mid-quarter because the team learned something real is not failure, it's the goal-setting process working as intended.
The takeaway
Engineering team goals that survive the year share three traits: the team wrote the numbers, the metrics resist gaming, and someone actually looks at them before December. Skip the velocity chart, measure what customers actually feel, and put one real check-in on the calendar every month. That's a smaller ask than most annual planning decks, and it's the version that's still being followed in Q3.