In organizations that adopt OKRs, leaders often say, “Write the goals more clearly.” But the point where OKRs actually become unstable is not the wording but the operating process. Employees can write Objectives and turn Key Results into numbers. The problem arises when it is not decided what to give up for those goals, who will coordinate when conflicts occur, and what decisions will be made when progress deteriorates.
In OKRs, the leader’s role is not to be a cheerleader. The leader is the person who narrows priorities, coordinates resource conflicts, surfaces dependencies between teams, and turns check-in meetings into forums for decision-making. Without this role, OKRs become a document that asks employees for more goals.
What leaders must decide first is not goals but “work not to do”
The Google OKR playbook explains that well-run OKRs make clear to teams what is important, what they should optimize, and what tradeoffs they should make in daily work. This sentence shows the leader’s first responsibility in OKR operations. It is not to make people write more goals, but to decide what to choose and what to set aside during this period.
Atlassian also recommends 1–3 Objectives and 3–5 Key Results per Objective when setting OKRs. The meaning of these numbers is not simply a writing rule. Without reducing the number of goals, priorities do not emerge. In an organization that says every goal is important, there is no goal that is actually important.
The question leaders should ask is not “Should we include this goal too?” but “If we include this goal, what must we remove?” If no goals are deleted in an OKR meeting, the strategic conversation is not yet over. Employees understand priorities not by looking at the list of goals the leader approved, but by looking at the list of work the leader decided to give up.
An OKR check-in is not a reporting meeting but a conflict-resolution meeting
Atlassian recommends that teams score, analyze, and summarize OKRs every month. It also explains that regular and visible progress checks strengthen accountability and momentum. In many organizations, however, check-ins turn into reporting meetings. Each team states its progress rate, and the leader concludes by saying everyone should work harder. With this approach, OKRs struggle to become an operating rhythm.
The Google playbook says that if a team determines it cannot achieve a committed OKR, it should escalate immediately. The more important point is the purpose of escalation. It is described as a process that enables executives to create options and resolve conflicts when disagreements over priorities, shortages of time, people, or resources, or disagreements over the goal itself arise.
Therefore, the question a leader should ask in an OKR check-in is not the progress number. “What obstacle is preventing the goal from being achieved?” “Are dependencies with other teams still unresolved?” “Are resources insufficient, or has the goal’s priority become lower?” “If we do not adjust now, what loss will grow next month?” Without these questions, a check-in ends as a reading of reports.
For example, when a product-launch OKR is delayed, if the leader only says, “Raise progress to 80% by next month,” the check-in becomes a motivation meeting. By contrast, if the group separates whether the bottleneck is legal review, development capacity, or excessive expansion of sales requirements, and adjusts priorities on the spot, the check-in becomes an operating meeting. OKR leadership is not a technique for pressuring employees; it is a technique for turning conflict into decisions.
In cross-team OKRs, leadership is not a slogan about collaboration but the design of accountability
The Google playbook explains that cross-team OKRs are appropriate when important projects require contributions from multiple groups. In such cases, every group that must materially participate should be included in the OKR, and each group’s contribution should appear explicitly in that group’s OKRs.
This principle is also important in cross-department collaboration in Korean companies. Many organizations write “strengthen collaboration” as a goal, but in reality it is not clear which department must provide which output by when. If a goal requires marketing, sales, product, HR, and data teams to move together, each organization’s OKRs must show the responsibilities connected to the others. Otherwise, a shared goal becomes a goal that no one takes responsibility for until the end.
A leader is not someone who merely declares cross-team OKRs, but someone who designs the connection structure. It is not enough to create a meeting body. Leaders must disclose the dependency list, decide who to escalate to when bottlenecks arise, and align the success criteria for the shared goal in a common language. Collaboration does not work through good attitudes alone. Collaboration needs lines of accountability and authority to coordinate.
If committed and aspirational are not distinguished, leaders send the wrong signal
The Google playbook distinguishes between committed OKRs and aspirational OKRs. A committed OKR is a goal promised for achievement, and the expected score is 1.0. If it is not achieved, an explanation and retrospective are needed. By contrast, an aspirational OKR is a goal that stimulates higher challenge and innovation. Even with the same achievement rate, the interpretation should be different.
If leaders do not make this distinction, employees receive confusing signals. If a leader asks for stretch goals but criticizes low achievement rates, only safe goals will come up in the next quarter. Conversely, if underachievement of promised goals is treated only as “fine because we challenged ourselves,” execution accountability weakens. A leader who handles both types of goals with the same expression blurs the language of OKRs.
Leaders must make the type clear from the moment they approve a goal. Is this goal a commitment that must be achieved, or a challenge that pushes the organization further? If it is a committed goal, resources and priority must be guaranteed. If it is an aspirational goal, the possibility of failure should be allowed, but what will be learned must be defined. Only when this distinction exists do employees set goals honestly.
HR should provide leaders with operating questions, not just OKR forms
One reason OKR training fails is that it remains training on forms. It is not enough to explain how to write Objectives and how many Key Results are appropriate. Training must connect to what questions leaders should actually ask in meetings and what decisions they should make.
HR can provide leaders with at least four operating questions. First, what will we give up this quarter? Second, if this OKR fails, where is the most likely bottleneck? Third, are the parts that require other teams’ contributions explicitly stated in each team’s OKRs? Fourth, is this goal committed or aspirational? When these questions are repeated in meetings, OKRs become not a document but an operating language.
OKR leadership is not a matter of charisma or encouragement. It is a matter of management capability: narrowing priorities, making uncomfortable tradeoffs visible, escalating conflicts at the right time, and designing accountability between teams. Employees do not move simply by hearing goals. They move by watching what leaders choose and what they adjust. For OKRs to become an operating system for performance management, the leader’s role must also change from goal manager to designer of the execution structure.
