Work goals examples you can actually check off

What makes a work goal useful

A useful goal tells you, six months from now, whether you did it. That’s most of what the SMART checklist is getting at: specific, measurable, achievable, relevant, and time-bound. You don’t need to recite the acronym. Just check that the goal names an outcome, says how you’ll know, and has a date on it.

Here’s the difference in practice:

The vague versions sound fine in January. In December, nobody (including you) can say whether they happened.

A simple goal template

By [date], I will [specific outcome],
measured by [how you'll know it happened],
because [why it matters to the team or the business].

Filled in, it looks like this:

By the end of Q2, I will cut p95 latency on the search API from 800ms to under 400ms, measured on our production dashboard, because slow search is the top complaint in support tickets.

The “because” part is easy to skip, but it’s what makes the goal easy for your manager to support, and later, easy to defend in your review.

Work goals examples for engineers

Borrow the shape and swap in your own systems and numbers.

Delivery and impact

• Ship the self-serve billing page by the end of Q3, so support stops handling plan changes by hand (about 40 tickets a week today).
• Lead the migration off the legacy auth service, with all traffic moved and the old service shut down by October.
• Deliver the three roadmap features I own this half on the dates we committed to, or flag a slip at least two weeks ahead.
• Get new-engineer setup time from about two days to under half a day by scripting the local environment.

Technical quality

• Bring CI’s failure rate from around 15% to under 5% by quarantining and fixing the flakiest tests.
• Remove the deprecated v1 endpoints from the API, with every client migrated, by the end of the year.

Reliability and operations

• Define SLOs for our two tier-1 services and set up alerts on their error budgets by the end of Q1.
• Cut the median time to resolve incidents in our area from about 45 minutes to 20, mostly through runbooks for our top five alerts.
• Run a post-mortem within a week for every incident I’m on call for, and close out its follow-ups within a month.

Collaboration and leadership

• Mentor one of our newer engineers through their first on-call rotation and their first project lead.
• Run the design review for our team, with every RFC getting written feedback within three working days.

Learning and growth

These are what most people mean by professional development goals. They work best when the learning is tied to something you’ll ship.

• Learn enough about our Kafka setup to handle consumer incidents without escalating, and lead one on my own by June.
• Get comfortable with capacity planning by owning the forecast for our main database this year.

Professional goals by level

The categories stay the same as you get more senior, but the scope grows.

Junior engineer

• Take medium-sized tickets from start to merge without a pairing session by the end of the half.
• Shadow two on-call rotations, then take a primary rotation by Q3.

Senior engineer

• Lead one project end to end, from the design doc to launch and the post-launch review.
• Be the go-to reviewer for one area of the codebase, so changes there don’t wait on the original author.
• Mentor at least one engineer, with specific goals you agree on together.

Staff engineer or tech lead

• Set a technical direction that more than one team adopts, such as a shared queueing platform or a common API standard.
• Grow at least one senior engineer into leading projects without you.

Short-term work goals vs. long-term career goals

Work goals usually cover a quarter, a half, or a year. Career goals are bigger and slower: where you want to be in two or three years.

Some examples of long-term career goals:

• Get promoted to staff engineer.
• Move from backend into machine learning infrastructure.
• Try engineering management, or decide for sure that it isn’t for you.
• Become the person the company relies on for payments.

A career goal is easier to act on once you break it into this year’s work goals. If the target is staff engineer, this year’s goals might be leading one cross-team project, writing two design docs that other teams use, and mentoring a senior engineer. Each of those can be checked off. “Become staff” on its own can’t.

Goals for your performance review

Most self-review forms end with “What are your goals for the next period?” A few tips for answering it:

• Three to five goals is plenty. More than that and none of them get real attention.
• Include at least one stretch goal, and say which one it is.
• Tie each goal to something your team or manager already cares about.
• Agree on them with your manager, so “met” means the same thing to both of you in six months.

There are sample answers for that question and the rest of the self-review if you’re in the middle of writing one.

The part everyone skips: tracking progress

Badly written goals are only part of the problem. The bigger one is that nobody looks at them between January and the review, and by then it’s too late to do anything about the goal that never moved.

What helps is keeping the evidence as you go: a line in a work journal whenever something moves a goal forward, and a quick look every month at which goals have nothing behind them yet.

Perfly has this built in:

1. You can set yearly goals, plus a one-line theme for the year if you like. It’s optional.
2. As you log work, by hand, from GitHub, Jira, Google Calendar, or Notion, or through your coding agent, each confirmed entry can be linked to a goal.
3. For each goal, Perfly shows how many entries back it, how many of those include a number, and when it was last touched. In May you can see which goal has nothing behind it while there’s still time to fix that.
4. At review time, your self-review groups each goal with the work behind it and can suggest a 1 to 5 score with a short rationale for every goal. You decide what to keep.

That evidence is also exactly what you want in hand when you ask for a raise or promotion.

FAQ

How many work goals should I have?

Three to five for a half or a year. If you have ten, you have a to-do list.

What’s the difference between SMART goals and OKRs?

SMART is a checklist for writing any single goal well. OKRs pair an objective with a few measurable key results, and companies usually use them for team or company goals. You can write your personal goals either way, as long as each one has an outcome you can check.

What if a goal stops making sense halfway through the year?

That happens, especially after a reorg or a change in priorities. Talk to your manager, rewrite or drop the goal, and note why. A goal that changed for a good reason looks fine in a review. One that was quietly abandoned doesn’t.

Should my goals be things I’m already doing?

Some of them, sure. Writing down work you’re already committed to keeps it visible. But include at least one goal that stretches you, or the goals won’t help you grow.

How much does Perfly cost?

30 days free with everything unlocked. After that it’s $6.99 a month, or $69.99 a year.