Does Daily Business Belong in OKRs?

Does the “normal” day-to-day business also need to be integrated into OKRs? Should OKRs be applied to routine tasks or only for projects and special assignments?

This question divides the community of OKR followers and consultants.
Some say, “All tasks must be included in OKRs – even daily business.”
Others believe that “daily business operates independently of OKRs, and OKRs should only be set for change processes, new topics, or projects.”

Who is right?
Both – and neither.

Instead of exchanging arguments, let’s examine real-life scenarios. Then, you’ll easily be able to decide whether and to what extent daily business should be integrated into OKRs.

When Should Daily Business Be Included in OKRs?

Constant Change 

Daily business should absolutely be reflected in OKRs when a significant portion of this business is subject to constant change. Departments like development, sales, or marketing are ideal candidates for OKRs that encompass daily business.
For instance, the daily business of a software developer (amongst other things) is coding. And the product of her software company is constantly improved.

When her team works toward a new strategic software release relevant to generating new business, this new release will be covered by multiple OKRs across the organization. In this case, her work results must also be included in OKRs. 

Organizational Change Processes

If a company is undergoing a major change process that involves altering entire work processes, collaboration styles, task distribution, etc., OKRs are essential – for all departments.
Only by covering all departments’ OKRs will we create transparency about which tasks are being neglected, where interfaces break down due to changes, duplicate work is happening, or which tasks are being overlooked.

Optimization

Whether optimizing the collaboration of a five-person team or a department with 1,000 employees across 15 countries, employees often lose sight of the actual goal in optimization projects.
The highest potential for optimization often lies at the working level, where employees know precisely what could make their work more efficient. If they have clarity about the final goal of the optimization, they can leverage their deep know-how and truly optimize.
OKRs allow this knowledge to be surfaced, valued, and implemented.
OKRs also ensure that, due to transparency, you don’t over-optimize.

When Should Daily Business Not Be Included in OKRs

Routine Work

Imagine we work in a company’saccounting department. There, invoices are recorded, accounts reconciled, and financial statements prepared—important tasks that must be done daily or regularly.
As long as this accounting team is on top of their job, with no delays or mistakes, it’s perfectly fine for them to “just keep working.”
What’s the point of suddenly introducing OKRs to an accountant and forcing them to translate their everyday work into OKRs? It becomes absurd, especially when they end up with the same OKRs every quarter because their job is routine.

One might say, “Well, they should think about what they could do better.”
Fair enough.

But this accountant probably does not influence how the SAP system is configured. They also can’t control that the invoices they need to process still arrive in paper rather than being automatically digitized into SAP. They’ve pointed this out 12 times already without anything changing. OKRs won’t change this either!

It’s great to optimize things continuously.
But we also need the ability to do so—both in terms of influence, intellect, and interest.
I’ve met many employees who would love to improve their work processes.

But they also tell me:
“I’m already struggling with my 40-hour workweek because our department is 20% understaffed. When should I think about optimization, talk to colleagues, propose ideas, and implement the changes? Yes, I know the story about the dull saw and the lumberjack. But sorry, I get into big trouble if bookkeeping falls behind – while I don’t get into trouble if I don’t make improvement suggestions.”

And that’s the crux of the matter.

OKRs are not made for routine work.

So What Does This Mean for OKRs and Daily Business?

It is unnecessary or even pointless to define OKRs for daily business when:

• The daily business is purely routine work.
• Employees have no control over what they do or how they do it.
• The tasks cannot or should not undergo any significant changes and must remain the same.
• Employees have no time to address or implement improvements because their team/department is massively understaffed.

It makes sense to define OKRs for at least parts of the daily business when:

• Tasks need to be improved, optimized, accelerated, or adjusted
• Tasks or processes are undergoing significant changes, allowing for broader adjustments
• Employees are given more freedom to influence daily business themselves

For employees to understand where their priorities lie, the following approach is strongly recommended:

The Compromise for Daily Business + OKRs: Define Time Blocks

The most pragmatic approach, which gains the most acceptance from employees, is as follows:

For tasks, projects, or changes that can be effectively improved by using OKRs, then OKRs should definitely be used.

If a large part of an employee’s, team’s, or department’s work consists of unchangeable daily business and only a small portion can be included in the OKRs, then a time block should be defined and reserved for OKR-related tasks.

Example:
If a finance department implements a new SAP module, it must still manage and oversee finances. No company can afford to ignore finances for 3-6 months or neglect legal reporting requirements because it’s introducing new software.

We would define how much time must still be dedicated to daily business and how much time will be allocated to the 1-2 OKRs to support the SAP implementation. (Note: in such a case, only 1-2 OKRs are recommended, not 5!)

This way, you set clear expectations for employees and ensure that the SAP implementation project team knows that finance employees only have 15% of their time available for the project.
This level of transparency is otherwise rarely achieved.

OKRs and SCRUM Project Teams

If you are part of a team working on a project using the agile SCRUM method, everything must also be reflected in the OKRs.

SCRUM breaks down a large project into many small tasks stored in the so-called backlog. Every two weeks, the team decides which tasks will be included in the following “sprint” to be worked on. At the end of each sprint, a functional result must be achieved.

OKRs provide a high-level overview of SCRUM projects.

Since SCRUM focuses on short-term implementation, priorities can be misplaced or the bigger goals might get forgotten over time. OKRs are the ideal addition to SCRUM.

When OKRs are defined for SCRUM projects, they cover everything the team aims to achieve in the next quarter.
However, don’t make the mistake of reintroducing a waterfall project model through the back door using OKRs!

If the project team also has additional tasks beyond this project, OKRs make this transparent. Some projects fall behind because employees have “side tasks” not accounted for in time or resource planning. 

OKRs bring this to light and prevent unrealistic planning.

So what’s the answer? Does Daily Business Belong in OKRs?

Once again, we arrive at the answer: “It depends.”

Anyone who believes OKRs can cover everything is like someone with a hammer who sees everything as a nail. 

If you consider the criteria mentioned and make team- and task-specific decisions on whether OKRs should include daily business, you’ll foster acceptance for this brilliant method.

However, forcing everyone to work with OKRs will create frustration and lay the foundation for the method’s failure.