Standards Over Goals: Why Your Next Breakthrough Isn't About Setting More Targets
Goals change. Standards stick. Here's how I stopped chasing metrics and started building the identity that makes progress automatic.
I spent two years setting goals like they were going out of style. "I'll ship this feature by Friday." "I'll learn Rust in 90 days." "I'll get promoted by Q3." I'd hit some, miss others, and feel exactly the same way every time I reset.
Then something clicked: I was measuring the wrong thing.
Goals Are Negotiable. Standards Aren't.
Here's the difference nobody talks about: you can move a goal. Change the metric. Push the timeline. A goal is a moving target—and that's the problem.
A standard is different. It's non-negotiable.
When I shifted from "I want to ship better code" (a goal) to "I am someone with high standards in how I approach my work" (a standard), everything changed. The goal could slip. The standard never did.
Think about it in your own role. You probably set a goal like "learn this new framework better." But what if instead you set a standard: "I am someone who doesn't ship code I'm not proud of"? That standard doesn't get renegotiated. It gets applied.
Take Imperfect Action, Not Perfect Planning
Here's what kills momentum: waiting for certainty before you move.
I used to overthink decisions at work. Should I refactor this? Am I ready to lead this project? What if I mess up? The analysis loop never ended. And the longer I stayed in my head, the farther behind I fell.
Then I started taking imperfect action instead. Put the PR up. Ask for feedback. Make the mistake. Learn it.
The feedback you get from doing beats any amount of planning. You see what's actually wrong. You see what you can improve. You move forward instead of spinning.
Align Your Daily Choices to Your Identity
This is where it gets practical.
If you want to be "someone who is a strong engineer," but every day you:
- Ship code without testing it
- Skip code reviews to hit a deadline
- Don't ask questions when stuck
Then you're not actually building that identity. You're just talking about it.
The opposite is true too. If you want to be "someone who learns fast in new codebases," then your daily choices need to match:
- Read the test suite before touching production code
- Ask about architecture decisions before implementing
- Document what you learned as you go
Identity doesn't come from hitting goals. It comes from compounding small choices over time.
Take the Concept, Leave the Cargo Cult
Last thing: don't copy someone else's system wholesale.
You'll read advice like "wake up at 5 a.m., do this routine, say affirmations." Some of it works. Some of it won't fit your life. The mistake is taking all of it or none of it.
Instead, extract the concept behind the teaching and make it yours.
The concept might be: "positive self-talk matters more than the specific action." Then you apply that in your own way, on your own schedule, aligned with your actual life. Not the ritual someone else designed.
Same with learning on the job. You don't copy someone's "learn Kubernetes in 30 days" plan. You extract: "deliberate, focused time on the fundamentals matters." Then you build the approach that fits your role, your brain, and your constraints.
What This Means Monday Morning
Pick one area where you feel behind. Your new stack. Your new role. Whatever.
Don't set a goal to "catch up by Q2."
Instead: Raise your standard to "I don't move forward until I understand why this works, not just how."
Then take one imperfect action today—read one file, ask one real question, ship one small thing—and let the feedback tell you what's next.
Standards compound. Goals just expire.