Goals That Transform You

Most people set goals that keep them busy. “Improve my skills.” “Be a better engineer.” “Contribute more to the team.” These are wishes dressed up as intentions. You can check them off at the end of the quarter without changing anything about what you’re capable of.

A goal worth setting answers a different question. Not “what will I do?” but “who will I be?” The test is simple: if you achieve the goal and someone asks what’s different about you now, can you give a concrete answer? “I’m better” is not an answer. “I can now design systems for a million users without asking anyone” is an answer.

The goal is not the work. The goal is the capability you unlock by doing the work.

Three things separate a real goal from a task list. First, it gives you a capability you don’t have today. Not more of what you already do — something new. A junior engineer who sets out to “write better code” stays a junior engineer who tries harder. One who sets out to “ship a feature end-to-end without pairing” becomes someone the team can hand things to. The difference is what you can do after, not how much you did during.

Second, it makes you uncomfortable. The right level of confidence is around seventy percent. If you’re certain you’ll hit it, it’s not a stretch goal — it’s a to-do list with a date on it. If you’re certain you’ll miss it, it’s a fantasy. The discomfort is a signal, not a warning. It marks the edge of your current capability, which is exactly where growth happens.

Third, success is observable without debate. “Improve leadership” fails this. “Run the weekly design critique for ten people without my manager in the room” passes it. At the end of the quarter, there is no question about whether you hit it. Either you ran it or you didn’t. The test: tell a teammate your goal and ask them whether they’d know at the end of the quarter if you hit it. If they’re unsure, rewrite it.

The practical implication is that you should pick one to three goals per quarter, not ten. Transformation takes focus. One big stretch goal — the capability you most need to unlock — and one or two supporting goals that build the skills you need for the main one. That’s it. Nice-to-haves are not goals. They’re backlog.

Each quarter should compound. The engineer who ships features independently in Q1 can lead small projects in Q2, design systems in Q3, and mentor others in Q4. That’s a year of compounding growth. The alternative — random goals with no connection — produces motion without direction. You end the year busier, not stronger.

The transformation test is the final check. Ask: if I achieve this goal, will I be a fundamentally different person? Red flags: “I’ll have done more work.” “I’ll have shipped a feature.” “I’ll know more about the codebase.” Green flags: “I’ll be the person who leads design reviews for ten people.” “I’ll be trusted to make product decisions without checking in.” “I’ll be the one people ask about system design.”

If you achieve your goal and you’re the same person, you aimed too low.