Our industry is very goal-oriented, and for a good reason. Setting ambitious goals and executing on them is how organizations move forward in the modern economy. But goals alone aren’t enough. To achieve meaningful progress—at a company level, within a team, or as an individual contributor—we need standards.

Dr. Gabrielle Lyon once shared a clever insight when asked about goal-setting: one should set standards, not goals. Paraphrasing her words:

When you set a goal, you either reach it or you don’t. But when you set a standard, you uphold it every day. And by keeping that standard, you eventually reach the goal.

She was speaking in the context of strength training, muscle growth, and longevity. But this principle applies just as well to software engineering. Her insight inspired this post.

Standards vs. goals

So what’s the base difference between a goal and a standard? Goals are the targets we aim for, while standards are the baseline for how we operate daily. We reach for goals, because they are outside of our current environment. We live by standards, because they are the very foundation of our environment, the backbone.

Goals are distant targets and endpoints - not processes and actions. They often encourage bursts of progress/motivation, rather than consistent output over long durations of time. This doesn’t make them bad or less valuable. It makes them a great tool for moving forward on a larger scale. It’s a vision; a direction.

If goals are directions, standards are like taking a step in that direction. Standards are not distant at all, they are right by our side - always. A key aspect of standards is that they are non-negotiable. Adaptable? Of course. Negotiable? Never.

Finally, another interesting distinction between the two is where they land on the locus of control spectrum. This is a fancy way of saying “goals often rely on external factors, while standards remain fully within your control”.

What? I get to look smart too, give me a break.

A 3-step framework

Enough of the theory and philosophy, let’s get practical. I’ll break down a simple, yet effective 3-step framework for managing standards in software engineering. The steps are: define, uphold and refine. I wasn’t witty enough to create a backronym such as YAGNI, KISS, DRY, SOLID or any of the gazillion terms we use in software.

Consider yourself challenged, and propose one in the comments.

Step 1: Define

During this step, we identify key areas to focus on. Lots of engineers and companies make a mistake of blindly borrowing standards, usually from one of the big 5 companies (think FAANG). They need to align well with your goals, and make sense for your business context. You can still borrow, but do so with a grain of salt.

Another aspect of this step is making sure your standards are specific and measurable. You can’t manage what you don’t measure applies neatly here.

Finally, a third aspect of effectively defining standards is - sustainability. Reserve the ambitions for the goals, and make sure standards are something you can actually follow or regular basis. The baseline should be high, but realistic and practical.

❌ Bad

Engineers should strive to write high-quality code whenever possible.

• not specific or measurable

• implies optionality (not non-negotiable)

• unclear how to achieve it

✅ Good

All production code must include meaningful tests covering key functionality, be reviewed by at least one peer, and follow team coding guidelines.

• specific and measurable

• explicit about non-negotiability

• very clear on how to achieve it

Step 2: Uphold

Making sure we uphold the standards is equally important as defining them. And the best way to ensure we uphold them is to enforce them. Standards are guaranteed if the option to bypass them is removed.

Practically speaking, this means we need to introduce templates, automations and checks into our workflows. The tooling should either help us reach a standard more easily, or ban us from proceeding until the standard is met.

Unfortunately, for some standards we need to rely solely on self-accountability and respect. This is why it is crucial that all team members understand the value of these standards, so they are less likely to fall short in these scenarios.

Lastly, it is more valuable to prioritise for consistency rather than intensity. Consistently good is a lot more valuable than occasionally great. Small and steady improvements win over time.

Step 3: Refine

Every quality and long-lasting framework leaves some wiggle room for the future. Because things change, all the time. Goals change, environment changes, team capacity changes, maturity level changes, etc.

Our third step in the framework serves precisely that purpose - adapting to change. We should regularly asses the effectiveness and the practicality of our standards. Are they serving the purpose they’re supposed to? Are they too rigid and difficult to uphold? Have we established firm ground and are ready to raise the bar?

These are the types of questions you should be asking yourself, your team and your organization. Do it frequently, but careful not to do it too often because the constant changes will make the standard difficult to uphold. If you find yourself making changes a little too often, your standards may be standing on shaky foundations.

It’s a wrap

Thanks for reading this far! It means the world to me.

I love having conversations and learning from others so definitely don’t hesitate to reach out via the comments or privately in DMs. It’s all about connecting, growing together and having fun. Until next time!