OKR work is a subset of engineering time. We deal with things like interviews, meetings, tech talks, training, migrations, and maintenance work outside the framework.
You should always be making progress on OKRs, but it’s not the only thing you do. Engineering has its own overhead, not every hour is billable.
I'd say OKR work is/should be all work. Each task should be aimed toward moving forward on the goal. It doesn't mean however, that you can directly link one specific task to the OKR. It's just part of the strategy to achieve the goals.
Let's consider a KR of 'increase active users by X%'.
* Interviewing/hiring isn't going to move the needle on getting X% more active users by itself. Having more engineering time available for new (critical) feature work might, however and you have to do interviewing to get new hires.
* Training in and of itself isn't going to move the needle either. But having a more knowledgable engineering team probably will, by being able to move faster or better. You have to do training to improve knowledge.
* Maintenance work might not move the needle on active users FORWARD (or it might, if you have a lot of bugs that prevent users from actually using your stuff) but it might prevent it from going BACKWARD.
You should always be making progress on OKRs, but it’s not the only thing you do. Engineering has its own overhead, not every hour is billable.