To me, standards are a clear, agreed-upon baseline that every member of the team must meet. They're not what we preach, they're what we tolerate. It is intolerable if a member of the team doesn't meet a standard.
Goals on the other hand, are what we hope for; they cannot be "lived up to", coerced on an individual or forced from the outside. If a member of the team can't achieve a goal, then they need differents goals.
I set the standards to be low and universal, while the goals are high and person-specific[1]. I'm thinking objectives could be thought of as "parts of standards that must be met at a later point in time but now now"[2]. But I'm still figuring it out. I think material about education is relevant, and helps to avoid easy, versatile, and deceiving thought-terminating cliches like "expectations".
[1] https://apasseducation.com/education-blog/3-differences-cont... [2] https://dataworks-ed.com/blog/2014/07/how-to-craft-a-learnin...
Example: the goal for someone is to build feature X. Now, they could tremendously help the company by answering the questions of another developer for feature Y, but that makes them look worse when it comes to evaluation of their goal because it's less time they can spend on it.
Now, you can also set a second goal of "be helpful" or so, but how do you measure that?
And so on. In the end, goals might be good to get a better performance out of unmotivated/lazy folks, but for motivated/engaged folks, it's the opposite of being helpful.
Measuring development performance at the individual level is futile given the collaborative nature of the work and its complexity. Team and manager performance are more tractable.
Team performance is highly influenced by external disruptions, which is why the culture of engineering management since the 1980s has been centered around "removing blockers". Focusing on building a smooth-running operation (good hardware and software, fast code reviews, fast deployments, minimum amount of meetings, etc.) is probably what this article means by DecisionOps.
Re: managers, one formula I've used in the past (inspired by Andy Grove I believe) for managers' performance is a combination of the following: how is their team delivering ? How are they helping neighboring teams deliver as well? Do people want to work for this person (internal transfers + hiring) ? Or do people want to leave this team ?
1) How do you actually measure performance? 2) How do you deal with performance and variance in individuals? 3) How do you set an acceptable performance level? 4) How do you make allowances for external disruption that affects performance?
With more than 3 years in management, I have personally found that you cannot really measure development performance much more than hand-waving.
A much more effective approach is to find somewhere that each member of the team can have a stake in something and be engaged. Make someone in charge of teh CI server or the deployment server or Git practice or coding challenges. It is much easier to see how people are performing then.