From my experience as a people manager (and an even longer stint as a developer), I’ve noticed that many engineers don’t see much value in goals.

If this is how you feel when your manager asks you to set yearly goals (or hands you new ones) you’re not alone.

In my perspective, they often feel like extra homework, tacked on after the “real work” of coding, only to resurface at the end of the year when someone asks about your progress. And from where I stand, you’re right: when treated this way, goals rarely deliver tangible benefits.

But it doesn’t have to be like this.

You’re missing out (on what exactly?)

Periodic goals, when used correctly, are a powerful long-term focus tool. In fast-paced teams, swamped with Jira tickets, code reviews, and spikes, you can be constantly busy yet rarely challenge the true priority or value of your next task.

That’s what goals are for:

• Company goals make sure you’re working on what matters.
• Personal development goals help you learn intentionally from your day-to-day work.

If your goals aren’t doing that, it’s probably because they’re not being used as intended.

How goals started making sense (and bringing value) to me

Once again: you must pick something that you truly feel strongly about. Realising this simple truth was the change in my case. It is better to have one goal that truly meets this requirement than four you only slightly care about.

My turning point came from my personal, not professional, life. I realised that my life wasn’t heading where I wanted, and if I didn’t change course, I wouldn’t be happy with how I’d spent it. This insight helped me see the importance of long-term planning (and I wouldn’t have seen it if I hadn’t read Stephen Covey’s classic book The 7 Habits of Highly Effective People).

From there, I began setting goals, actually tracking them, and finally seeing the value.

How to make goals work

For goals to work for you, you need three simple requirements:

1. Choose goals you genuinely believe are important and valuable.
2. Track progress regularly (if you’re not tracking, it’s usually a sign that requirement 1 isn’t really met).
3. Connect goals to your daily work, so progress happens as you ship, not as an afterthought.

Don’t isolate goals from your workflow

A common problem is that the goals are too detached from your daily work. You likely spend most of your time in the codebase, making changes based on your issue‑tracking system. Now consider a goal like:

By the end of the year, I will have finished a Kotlin fundamentals training.

That’s planning to fail. Will you truly make room for this while putting tickets on hold? If yes, great. But for most of us, day-to-day tasks feel more urgent. December arrives, and you realise you’ve made no progress. Cue the last-minute scramble.

Define a different goal instead: 

When I see a Kotlin feature in the codebase that I don’t understand, I’ll read the documentation and make a note of it (at least once a week).

Why this works: you don’t need much extra time, it won’t derail the task at hand, it’s easy to track, and it builds a habit of continuous learning rather than a one-off course completion.

Focus on the “how,” not just “what”

Another tip is defining goals that focus you on how you’d like to accomplish something. Probably the task from the issue tracking system already tells you what you need to do. A goal can help you define additional criteria or focus on the quality.

Let’s say you introduced a few bugs into the system recently and want to avoid this in the future. You could define a goal:

For every applicable pull request, I will leave a comment documenting measured test coverage before and after the change and ensure it increases.

This keeps the goal anchored in your daily work while adding a perspective often missing from the ticket.

Keep the goals visible

This relates to Requirement 2: if you do not see the goal often, you’re likely to forget to track it. Keep them in sight: as a sticky note on your monitor or pinned at the top of your to-do list.

Use OKRs (or something similarly effective)

There’s a reason OKRs have stuck around: they’re simple and effective. A practical check I like is to define the Objective and then ask:

Will it really happen once these KRs are met?

If the answer is “not quite,” adjust your Key Results until they make the objective inevitable.

Final thought

If you’ve made it this far, I hope it’s a bit clearer how goals can help. Pick goals that matter, track them regularly, and tie them to your daily work. You’ll feel the difference.

Happy goal‑setting!

The post Developer Goals Don’t Have to Be Corporate Theatre appeared first on ShiftMag.