I think discussing this requires getting clear on what OKRs are. At the company I was at they were broad personal goals set every 3, 6 or 12 months related generally to your career at the company. They were not related to any specific project or deadline.
An example might be "Do more public speaking". Where as generally I'd speak if the opportunity came up but I wouldn't seek out opportunities and AFAIK the OKR didn't make me seek more out. It was just something I wrote to get management to sign off that I had written some OKRs.
It gives you a nice defense when some seemingly urgent but less important work comes along. "We could do that, but it would cost us this OKR which we agreed at all levels was one of the most important things for our team to do."
You could have said: these OKRs have to describe my actual work... here are my attempts to document what that means, and what to look for if I do a good job at that.
If they had pushed back on that, I think you would have a leg to stand on, but as described it sounds like you were just unwilling to engage.
I'm genuinely struggling to understand the place of a construct like OKR in a world where Slack like tools exist.
Ones a chat app the other is a system of setting objectives and measuring against those objectives.
Does it still make sense when the org is closer together due to slack
Your OKRs put that sort of thing in one place. The process to determine what the OKRs are ensure that everyone's on the same page about the objectives. People in an organization want to feel like they know what they're working towards. When they don't they get stressed out and unproductive.
Most okr are dependent on someone else - the Android app guy will not achieve their okr if the API guy is off doing something else. In that way, the whole aspect of goal setting and achieving that is probably more inefficient using an okr structure than thrashing it out on slack (and most likely in a dedicated channel called "planning")
You need to try and think about what things look like when the company is much, much larger.
If you’re setting them and always missing them because of entities with other objectives, then your organization is obviously misaligned and needs to evaluate its goals.
Slack is a chat app.
You can chat over slack about goals, but slack isn’t goals and goals aren’t a chat app.
You can be on slack or email or around the water-cooler all day long. I don't think that makes that much difference. It's not like as soon as you bring Slack into an organization all this structure emerges that helps you focus your efforts on what to do. Chat app or no chat app, people are always coordinating with each other to complete task-level work.
OKRs help you think first strategically (longer than 1 year) then tactically (between 1 month to 1 year) and then operationally (day to day, week to week). Chat apps don't do that for you.
They just aren't related.
One thing I did, I don't know if this is part of OKRs anywhere else, is I really wanted numbers on all the KRs. So I added columns for the success value and data type: binary, ordinal, normalized, continuous, whatever it is. So at least I know what kind of math to apply. And it's a nice checksum that you know you've discussed that KR enough that you understand it enough to compute on: (binary, success=1, 0) or (ordinal, 37, 12) is super useful.
I let the 1:1s slide to every 2 weeks once we had a visual. Some prefer keeping the weekly. Some just stopped showing up. Hint: I've learned the 1:1 no-shows are also the ones who mail it in generally.
We have some federally mandated inspections coming so I dropped a big red line on that quarter. That's a nice visual to help say "it's gotta happen by then, or we're not doing it until after".
Laid out in front of me, some of these arrows clearly needed more wood. Some needed to be discarded. Some personnel changes were needed. Personnel changes are in progress.
Let me be very clear, my direct reports absolutely manipulate my behavior. That's their job. I've got plenty of clinical and research work. My role as the lab director is to synthesize what they're telling me and recruit resources for them, cut deals with other departments, go to my boss, whatever it takes.
And, when my boss's boss's boss put out word that my boss was getting promoted and they were looking for my new boss, I could have stepped into that breach, gunning for a promotion. But it's frankly a lot early for me to be looking for another promotion and I knew I had lots of work to deal with locally. So instead, I wrote a recommendation for a colleague and encouraged her to apply. And guess who my new boss is?
The upshot is my former colleague, now boss, is totally on my side. For her, this was a pheonix-rising sort of opportunity. She's on a mission from God to be the best boss ever. In our first meeting (remember, first impressions) I showed her our OKRs. She had never heard of OKRs, probably still doesn't know what that stands for, but she knew, instantly, that I'm tracking "all the stuff" like white on rice. You know you did it right when the boss sees your OKRs and completely changes the subject to start talking about problems in other areas. She's not worried about the lab's direction. She was, and is, plenty stressed with other departments she owns. But if I tell her we need help, she's very clear we need that help.
And we've got some of the things done. Which is nice. It's a little early to start computing annual success rate, but it won't be 0. I think most people hear about OKRs and setting the bar so high it makes you nervous, 60-70% success rates, etc and get worried. I think without OKRs,or something like that, a lot of people don't realize how many high bars they've set for themselves. 70 projects for 40 people is a little concerning. And I won't even tell you how many times I said "Hey, it's okay, let's dial this back a little" or "Can we buy more time on this? Who do I need to talk to?"
Also, we do use numbers on OKRs (at well-known modern tech giant). We do try to normalize to a real number [0,1] indicating roughly the probability of successfully meeting the goal by the end of quarter.
EDIT: to clarify, we do track something quantitative for each KR: error rate, response time, customer satisfaction score, whatever. Then we normalize to a probability so that we can scan the columns quickly and compare like with like.
If it has an acronym it's useless to functioning contributors. The original purpose has disappeared with the name.
I'd say I have some pretty smart people working for me but large orgs are large because they have lots of work that needs doing and the big chunks are big enough the people doing the work tend to self-organize. Some work never stops (e.g. healthcare) so you have to establish shift work. Does that mean those people are drones? They might be young, they might enjoy a sense of belonging and camaraderie, even when things suck, and maybe they would benefit from some additional experiential learning of discipline, but does that mean they're drones? Did you consider the fact that my direct reports themselves have advanced degrees?
A word of advice ... the worst thing I could have done to you right now is ignore you and let your opinion fester. Maybe step back, have all the disdain for me you want, but I hope you at least read this far.
It turns out that OKRs made the employees happier, because it served as a “more abstract” form of feedback.
Before, they were receiving feedback, but it was too specific and narrow. Things like “this class can be refactored to X pattern” or “You missed a few unit tests covering X Y Z cases.”
But when we started tracking things like time to ship a new feature, bugs per implemented feature, hard deadlines for certain product releases, etc. it really helped to give some better feedback.
You could tell people who were writing code very fast to slow down in general, and write more stable, thought-out code.
For example, there was one dev who tended to have substantially more bugs in his code than the others, and slower ship times. It turns out that he was always being assigned to more complicated Tasks and Stories, and the poor guy was overworked to shit and he didn’t even realize it.
It’s got nothing to do with being a drone, and everything to do with not being able to improve until you measure.
Do you think Usain Bolt doesn’t have a stopwatch when he runs?
In order to keep up, we needed to turn development time from just a metric, into an OKR. Moreover, our clients sometimes put pressure on us to ship out X feature immediately, in response to a competitor. This means that sometimes the 10 devs are working on different features for different clients.
So, just like the book, “Measure what matters.” Don’t measure useless things like commits per dev or features shipped last quarter, the important thing for our division is development time.
Presumably when we get development times down, our OKRs will change to other things, like overall client satisfaction. But for now, the top concern is to meet sales volume, so our OKR is development time
The process gets heavier at the level where OKRs are getting aggregated across multiple teams, or teams of teams, but that's a cost paid by managers, not by "drones," so I don't see why line employees should be concerned with it.
FWIW I spend about four to six hours a year thinking about OKRs, and that's assuming I'm paying attention for the entire OKR team meeting (fat chance).
As a non-IC, I'd spend that much time per week on OKRs: writing the OKRs for a team involved planning out the next quarter's topics, which required aligning the team (with individual meetings & group ones) for the 2-3 weeks at the end of the quarter. Then drafting them, aligning with the department/VP's topics for the quarter, finishing them, getting feedback from other team leads, dry-run presentation for the dev manager meeting, then live run-through for the department all-hands, mid-point scoring updates, end-of-quarter scoring, back to the beginning
Concrete team stories are usually quite clear. OKRs force you to encode a bunch of them into objectives and key results. This produces utter nonsense if the duties and opportunities are generic or fragmented. Not every team can write a clear OKR which makes it obvious what's happening, especially if you servicing multiple departments.
I am also in a massive, MASSIVE, organization with literally acres of people dedicated to formal communication processes. I submit that OKRs were handy because they forced formal communication that revealed problems outside the official formal methods. It's a hack. And in the realm of formal comms, it's a particularly low-friction, low-cost-of-adoption hack.
10/10 will use again.