The development of OKRs is generally attributed to Andy Grove, the “Father of OKRs”, who introduced the approach to Intel during his tenure there and documented this in his 1983 book High Output Management. Grove’s simple but effective concept is explained by John Doerr: “The key result has to be measurable. But at the end you can look, and without any arguments: Did I do that or did I not do it? Yes? No? Simple. No judgments in it”.
(Took me a while to re-find this word.)
I disagree with the below, but here is an example of what you can professionally describe as “culture” of a workplace:
Additionally, “culture” is a blanket term for behavior. When the candidate or employee is discussed, rather than the team of company itself, “culture” refers to communication, non-confrontation and ability to work with others.
- Monday: must go to gym; plan for the week
- Tuesday: most productive day at work. should go to gym. should socialize sober
- Wednesday: most productive day at work. should go to gym. should socialize sober
- Thursday: work from home. should socialize! should go to gym
- Friday: work from office. go out at night. no gym.
- Saturday: go out if you can. have a productive day. shopping. errands.
- Sunday: no drinking! prepare for the week ahead.
You have to do the best you can. You have to be on top of your game, at all times (and especially at crunch time or competition time). And remember the split-second rule: you only have a splitsecond to make a decision, and every mistake can make or break a task.
But what we are doing is developing ourselves, so that we are great. And from that, the success comes almost automatically. So we are not pursuing success as much as we pursue self-actualization, and success is a by-product of being on top of your game. That’s where faith and belief comes in. I’m a highly technical person and science plays a big role in my life and work, and it’s perhaps surprizing that I mention faith – but it’s true, faith has a place in my definition of personal corporate culture. You have to believe that success will come. You have to believe that small actions that you take and don’t seem to receive a rewad – eventually, the totality of your “correct” actions brings about success. It’s a bit of a leap because it’s entirely possible that a sequence of all the correct actions, still doesn’t bring success. You can make no mistakes, and still fail ([insert quite, image]), that’s the nature of the open market. The leap then is the leap of faith: the belief that eventually, the totality of correct actions brings about success. Whatever your definition of success might be.
I thought this topic is clear, but I’ve run into this again very recently. Since so much conflicting information is going around, let’s iterate once again on what the priority codes should mean. I’m drawing this originally from Jira definitions – I think that’s where i saw it first, and it is the most sensible.
- P0 – the work stops, site is down
- P1 – unblock someone else, required to be done before other things
- P2 – ordinary flow of work
- P3 – nice to have, but not required
- P4 – informational only
I recently saw another definition coming from a more “senior” individual, and it almost made sense, until it didn’t. At which time I stopped and re-evaluated the definitions for myself, once again. The faulty definition was:
- (DO NOT USE)
- P0 – the work stops
- P1 – the task affects customers
- P2 – the task affects customers, but there is a non-technical workaround solution
- P3 – the task doesn’t affect customers
- P4 – informational / never used
- (DO NOT USE)
The problem with the faulty definition is that everything is P1, and nothing can really be escalated to P0. P4 is completely useless, and junior PM’s and developers would usually create P3’s (the default in Jira), positioning themselves for a need to clarify or shift priorities, etc.
Another thing to note. The priority definitions are technical. They aren’t written with customers in mind – there are multiple layers between devs and customers, and the priority codes are for developers more than anyone else.
The default code is P2. If the work doesn’t need to be done, save the resources and time and don’t do it; change the priority to P3. If there is a change that a task needs to be done sooner rather than later, bump it to P1. And the P4 is effectively never used, because informational stuff resides in wikis and other communication channels..
This came up in Financial Times today. We aren’t Millenials, we’re Generation Burnout. We work too hard for too little, and do ourselves a disfavor by not seeing the forest for the trees. What’s the goal, anyway?
I say, leave some of your time (and money) unallocated. I say, if the problem is that we work too hard and spread ourselves too thin, let’s stop doing that. Cut yourself some slack, and have time and resources that are unallocated. This helps you cope with stress, AND allows you to effectively deal with instantaneous things that come up. If you have free time, you don’t have to schedule every little thing to be done later, you can just do it now.
Overall, look at the 80/20 rule, it’s quite interesting.
It does not quite refer to my little pony, it’s more of a corporate cultural term.
You can also say “velocity”, you can say “agility” to mean the same concept.
It’s how quickly and effectively you get stuff done. If the sprint is 2 weeks and you pack two sprint’s worth of work into one, that’s high cadence.
If you are able to bring teammembers together to solve a challenging challenge, it’s cadence.
You say, “we like the increased cadence this fiscal quarter.”
It generally refers to productivity. It is one of the highest states to aspire for.