As an engineer, I’m really tired of these processes and metrics that are supposed to increase focus and enable delivering value but in practice often don’t. A lot of organizational time is spent coming up with OKRs only for them to be either overridden due to the reality of running a business (gotta do what clients need, gotta do what you can to compete with competitors) or just by VPs/Directors deciding that something else requires the teams focus. Ultimately it seems like a whole bunch of busy work for PMs and TPMs, to justify their existence and hiring more of them.
“But you’re not doing OKRs correctly!” Sure, I agree to that. But what use is a system or process that’s so difficult to get right that most organizations fail? I would argue that it is useless.
I’ve seen this happen with another process: the church of agile. The way I’ve seen agile being used effectively is for orgs to agree to use the parts of it that make sense for them, not worry about what’s “right”, and constantly try out new ways of improving in response to feedback. That gives the team a sense that it’s a process that is evolving to meet their specific needs, rather than evolving to meet a dogma.
I think it's totally fair to see OKRs as silly and useless as an engineer. Personally I think they are really only relevant at the VP level and above.
All the things you say are true about OKRs, they run up against the reality of the business, and at the end of the day are fungible, but I would encourage a different way of looking at OKRs.
They inspire a conversation about how the company should really be spending its time and resources. What are the ultimate goals of what the business is doing. What is the real opportunity. How do we define success and how can we push success further? What's the dream by investing in these various initiatives?
Once you are leading an organization of several people, each of whom has their own individual success depending on some of these decisions, it behooves you to take this type of planning seriously and spend some time trying to answer these questions at some cadence (once or twice a year at least) to solidify the high level goals - even if there is constantly the risk of these OKRs getting trampled by the realities of the business as you eloquently put.
The purpose of having these conversations about OKRs at the leadership level is a bit different than the pragmatic benefits of the agile process and the two are a bit perpendicular in terms of purposes. Agile is on the ground execution, dealing with and greasing the wheels for the day to day efficiency of small teams. OKRs are occasional shocks to the system attempting to steer a large barge on course towards a far off goal.
Philosophically, it's important to have something concrete to work towards.
Like you say, what happens in practice, no matter what the system, is that it takes on a life of it's own, and there is a management layer discussing, planning, monitoring, etc thr KPIs, OKRs, whatever, as if tending the metrics is the goal of the business instead of delivering the underlying work. And this pisses off the engineers (or whoever the actual "doers" are, because it makes management look like a big circle jerk instead of a useful function - and a lot of the time, this is true.
Personally, I can see emphasis on these metrics and their associated processes as an important part of a process driven organization, where you want everything to be consistent, and are willing to sacrifice efficiency (and job satisfaction), while carrying a heavy admin layer. This is probably true for most big companies.
Personally, I think the solution is individual responsibility- less management and more focus on specifications. Basically treating each employee as a subcontractor or tradesman and telling them what you want done instead of how to do it, and having money or %utilization as a feedback mechanism. But they only works with the right mindset, and if you're the government or a big Corp, it's probably easier to just spend the time on OKRs
I empathize with this view and felt this way for a long time, but now that I work with managers who are really good at this stuff and are "pushing" me to get good at it, I am seeing its power.
> “But you’re not doing OKRs correctly!” Sure, I agree to that. But what use is a system or process that’s so difficult to get right that most organizations fail? I would argue that it is useless.
You can say that about a lot of stuff. Most people "fall off the wagon" with proper diets, for example - but that doesn't mean it's not a valuable thing to strive for.
I’m not really a fan of agile but I like the simplicity of OKRs if done well. It’s not easy and time consuming like you mention. My guess is it rarely gets done correctly.
One of the main benefits of OKRs imo is helping each person understand where they fit into the big objective. I don’t see the value in management using them to set lofty goals or push their team.
In threads that complain about work, I see a lot of comments about a desire for ownership of their work. OKRs can play a role in describing a persons ownership.
You are right.
I experienced the same cult-like fanatic adoration of the process with rather detrimental results for the company's IT department similar to the times of "agile will solve everything and heal cancer" which bit us like a holy hand grenade.
Maybe we computer people are, like anybody else, also in need of a Shepard and a holy book?
> But what use is a system or process that’s so difficult to get right that most organizations fail? I would argue that it is useless.
This is also what extremely difficult but fundamentally important problems look like. Getting clarity about goals across a big organization where every single person has a different conception of the problems it faces is Very Hard. I don't know if OKRs are the right answer, but the right answer will definitely reflect the Very Hard nature of the problem it's trying to solve. Probably the most any methodology can do here is trick you into asking the right questions.
(I think Agile is an entirely different story. But remember that agility is only easy if you have solid developers, and hiring is in general Very Hard, especially for the kind of people who muck up Agile.)
"That gives the team a sense that it’s a process that is evolving to meet their specific needs, rather than evolving to meet a dogma."
In my experience the most dogmatic organzations tend to just cargo cult their methodology.
There's no real deep understanding for "why" it works for whatever MAANG they're trying to mimic. There's just a hollow pursuit of vanity metrics and busy work.
There's value to be had with good work methods but it's almost always when people craft it to serve the unique value their organization creates rather than blindly doing whatever it is that Google does.
As an engineer, I’m really tired of these processes and metrics that are supposed to increase focus and enable delivering value but in practice often don’t. A lot of organizational time is spent coming up with OKRs only for them to be either overridden due to the reality of running a business (gotta do what clients need, gotta do what you can to compete with competitors) or just by VPs/Directors deciding that something else requires the teams focus. Ultimately it seems like a whole bunch of busy work for PMs and TPMs, to justify their existence and hiring more of them.
“But you’re not doing OKRs correctly!” Sure, I agree to that. But what use is a system or process that’s so difficult to get right that most organizations fail? I would argue that it is useless.
I’ve seen this happen with another process: the church of agile. The way I’ve seen agile being used effectively is for orgs to agree to use the parts of it that make sense for them, not worry about what’s “right”, and constantly try out new ways of improving in response to feedback. That gives the team a sense that it’s a process that is evolving to meet their specific needs, rather than evolving to meet a dogma.