Introduction
They should have clear delivery dates, a clear scope of what is within and outisde. A clear priority and should be aligned with both your vision and mission. They need to have measurable metrics for quantitative output and qualitative outcomes of completing the objective.
The purpose of an objective is to subordinate individual craftsmanship to systemic output.
Parable
In The Practice of Management (1954), Peter Drucker illustrated the fundamental problem of organizational alignment through the parable of the three stonecutterscite: 3. When asked what they were doing:
- The first said: "I am making a living."
- The second said: "I am doing the best job of stonecutting in the entire country."
- The third said: "I am building a cathedral."
The second stonecutter is always the most dangerous person in an organization. He is an artisan who cares more about the elegance of his craft, whether that is clean code, beautiful mockups, or complex spreadsheets, than whether the cathedral ever gets built. Without a clear, unifying objective, organizations naturally elevate the second stonecutter. Senior engineers will spend six weeks redesigning an internal build pipeline for marginal aesthetic pleasure; designers will obsess over micro-interactions for features that solve no real problem; managers will optimize their localized team headcount. Each person operates under the delusion that doing exceptional work in their narrow discipline automatically helps the business.
It does not. High craft in service of the wrong outcome is just expensive self-indulgence. An objective provides the single external standard that judges all internal effort: Does this specific technical or design trade-off get the cathedral built before the deadline, or is it just vanity stone-polishing?
With clearly defined objectives in your team, everyone can row in the same direction.
Deadlines
In order to forcefully introduce momentum and velocity you need to always set deadlines, this operational constraint will introduce friction so teams are forced to make hard trade-offs.
The deadlines are not part of some rigid waterfall schedule, however we cannot let it be soft suggestions either, as the moment scope creeps or a hypothesis fails, the reflex of weak leadership is to move the deadline. While the disciplined response is to protect the deadline and ruthlessly cut scope. If moving a deadline carries zero friction, it will become the standard way of operating: huge initial scope, soft schedules, everything delayed.
Cutting scope should be within the authority of the team to make that decision, as they will be the owners of the problem space.
Hysteric focus towards fake goals
Lacking a continuous, stable vector, leadership governs through rolling panic. One month an executive declares an costs drive to slash spending. That is immediately followed by a quality drive to get rid of bugs, which is followed by a speed drive to hit an arbitrary marketing release. Each campaign is launched with breathless urgency, derailing active engineering work to focus entirely on whatever symptom is currently screaming the loudest.
Management by drive is an admission of managerial debt and incompetence. It exhausts teams, induces cynicism, and teaches people to silently wait out every new corporate campaign, knowing that everything will collapse back into a broken status quo three weeks after the "drive" ends.
Objectives exist to eliminate the hysteria, by replacing unpredictable executive mood swings with the steady, unemotional discipline of building towards fixed constraints.
Death by hierarchy
The fastest way to destroy objective-based management is to cascade it into a bureaucratic hierarchy. This is what happened to agile and scrum, and once the bureaucracy catches up, it becomes yet another weapon by the laptop class to use to avoid work, accountability and focus.
When leadership forces every department and sub-team to invent its own bespoke layer of formal objectives, you create an administrative nightmare. Teams begin managing to proxies—metrics designed to simulate value without having to produce actual business outcomes. Engineering measures story points burned; QA measures test tickets closed; Product measures shipping frequency. Proxies incentivize teams to game the system at the direct expense of the whole. A team can hit 100% of its internal proxy metrics while the actual product fails completely in the market. Objectives cannot be an intellectual exercise in fractal tree-building. If an engineer on a pull request cannot draw a direct, unbroken line between their current technical task and the company’s primary objective without passing through three layers of corporate abstraction, the hierarchy is useless. Keep the objectives minimal, visible, and tied directly to real-world outcomes rather than internal activity.
Once each team start defining their own objectives and breaking them into, you risk them becoming too abstract and seize to be useful anymore. Just as the risk of competing priorities we have the same for competing or different objectives that end up
That is why we think these abstractions/proxies of goals and metrics are not actually that useful in practice, beyond giving the teams a way to think about how they contribute.
But this should really just be something they think about always. How is the task im doing right now contributing to the organziations objectives?