This article should be a mandatory read for every company engaging with the OKRs. I would bet that ill-designed OKR software is accelerating the perception of OKRs as a macro-project management tool as opposed to a strategic one.
JIRA caused irreparable damage to the Agile idea and I am afraid a similar fate will happen to goal management. Good intentions are not enough if implemented with bad practices in order to satisfy hungry stakeholders.
I'm afraid software vendors in all fields tend to spread practices that are non-optimal. If vendors do a good job, they develop the features that most companies want. The problem is that by definition, most companies are not "the best" in any field, and thus are looking for software to implement not the "best" practices, but the bad ones.
I worked for a company in the past that was implementing OKR. Not unlike Agile, it turned out to be a half-baked and misunderstood solution... to whatever problem we think we had.
One of my biggest issues with processes is the overuse of processes. Processes are great! Don't get me wrong. But one problem that ends up surfacing is that we become so focused on implementing and using processes that delivering actual value now takes longer to do. The funny part about all of this is that it's being sold as a way to deliver more value sooner. The opposite is often the result... from my experience.
The mere mention of "due dates" will be triggering. So I applaud you for publishing this article. Bold move.
I mentioned above about the "half bakedness" of processes like Agile and OKRs in a business: the point I want to try to make here is that due dates are business 101. I would absolutely love to believe that there is a world where businesses have less of a focus on due dates and more focus delivering outcomes and value, but I highly doubt that this will ever truly become a reality. There's no reality where business people divorce themselves from due dates for these reasons:
1. Business people believe that they NEED to know when they're going to get the thing that they're paying for. And sure, this is reasonable, but as is often the case with trying to predict the future, deliveries shift regardless. For really good examples of this, look no further than the aerospace industry. There is always shift and cost overruns.
2. Forcing functions! Due dates serve as forcing functions. Business people believe (and there is some legitimacy to this) that people won't push themselves to get work done faster/sooner without a due date. Wether the due date is a legitimate due date or not. It doesn't matter. The psychological effects of due dates FORCE people to work harder and faster... for better or worse. Often worse. The reason for that is simple: when your daily life is a constant grind, you will search for short cuts. Those short cuts are when quality starts to slip. :cough:Boeing:cough: Believe me, I know there's a lot more to it than that with Boeing, but this is certainly one aspect. Who needs bolts on door plugs anyway? Amirite? We need to ship this thing yesterday. < due date!
I've seen many business people over the years grip hard onto their due dates and any challenge to them will often be met with the excuse of "...we have external forces that make shifting the due date impossible". A full-stop, non-debatable excuse. Another eye roll.
Even if you could convince business people to stop focusing on due dates, they will find ways to keep them and hide them. One such way is renaming them. Say hello to "Sprints"! Sprints are another forcing function. They are, in effect, due dates! True story! Deliver smaller chunks of value every two weeks. Welcome to the velocity grind! Another VERY misused concept. "Take on more story points", they will tell you. Increase your velocity... uh huh :eye_roll:...
Felipe, I wish you the best of luck with this mission. I would love to see/read some examples where you've successfully convinced a business to operate this way. Though, I'm not sure I'd be convinced that they haven't found a way to hide their old habits.
Thanks for commenting. As I've mentioned in the first article in this series, I'm not talking about zero dates. There are always cases where we need to commit to dates:
Bravo. I’ve shared this with my colleagues as many are focused on project completion since a big customer is asking for something… how does that help the overall product (what’s the objective….)?
Or how does that help your big customer? What are they trying to achieve?
One of the challenges of focusing on outcomes in B2B tech companies is that often your customer is a traditional IT department that is used to focusing on projects and due dates. In those cases, we often have to work with them to help them define their desired outcomes.
Your article will help clarify my explanations on why we need to think in terms of results, not projects, when working with OKRs. But do you know what one of the biggest problems is? The fact that in "Measure What Matters," there are examples that you cited as BAD OKRs, but because they are in the most famous book by the most famous author, they are considered GOOD OKRs. As a result, people who believe that OKRs should be used to accelerate projects will use John Doerr's reference to contest the ouctecome (results-oriented) approach of OKRs.
Another serious issue is that many people, especially in Brazil, have a huge difficulty defining the "from X to Y."
If the formula is Verb + what you're going to measure + from X to Y, the discussion starts with "measuring," because most processes—except for production and commercial ones—are not measured. And when they have the X, the Y is usually a guess, since people don’t take the time to analyze trends, scenarios or even historical data to define it.
This article should be a mandatory read for every company engaging with the OKRs. I would bet that ill-designed OKR software is accelerating the perception of OKRs as a macro-project management tool as opposed to a strategic one.
JIRA caused irreparable damage to the Agile idea and I am afraid a similar fate will happen to goal management. Good intentions are not enough if implemented with bad practices in order to satisfy hungry stakeholders.
Thank you again, for the valuable article.
Thanks, I'm glad you liked it.
I'm afraid software vendors in all fields tend to spread practices that are non-optimal. If vendors do a good job, they develop the features that most companies want. The problem is that by definition, most companies are not "the best" in any field, and thus are looking for software to implement not the "best" practices, but the bad ones.
I worked for a company in the past that was implementing OKR. Not unlike Agile, it turned out to be a half-baked and misunderstood solution... to whatever problem we think we had.
One of my biggest issues with processes is the overuse of processes. Processes are great! Don't get me wrong. But one problem that ends up surfacing is that we become so focused on implementing and using processes that delivering actual value now takes longer to do. The funny part about all of this is that it's being sold as a way to deliver more value sooner. The opposite is often the result... from my experience.
The mere mention of "due dates" will be triggering. So I applaud you for publishing this article. Bold move.
I mentioned above about the "half bakedness" of processes like Agile and OKRs in a business: the point I want to try to make here is that due dates are business 101. I would absolutely love to believe that there is a world where businesses have less of a focus on due dates and more focus delivering outcomes and value, but I highly doubt that this will ever truly become a reality. There's no reality where business people divorce themselves from due dates for these reasons:
1. Business people believe that they NEED to know when they're going to get the thing that they're paying for. And sure, this is reasonable, but as is often the case with trying to predict the future, deliveries shift regardless. For really good examples of this, look no further than the aerospace industry. There is always shift and cost overruns.
2. Forcing functions! Due dates serve as forcing functions. Business people believe (and there is some legitimacy to this) that people won't push themselves to get work done faster/sooner without a due date. Wether the due date is a legitimate due date or not. It doesn't matter. The psychological effects of due dates FORCE people to work harder and faster... for better or worse. Often worse. The reason for that is simple: when your daily life is a constant grind, you will search for short cuts. Those short cuts are when quality starts to slip. :cough:Boeing:cough: Believe me, I know there's a lot more to it than that with Boeing, but this is certainly one aspect. Who needs bolts on door plugs anyway? Amirite? We need to ship this thing yesterday. < due date!
I've seen many business people over the years grip hard onto their due dates and any challenge to them will often be met with the excuse of "...we have external forces that make shifting the due date impossible". A full-stop, non-debatable excuse. Another eye roll.
Even if you could convince business people to stop focusing on due dates, they will find ways to keep them and hide them. One such way is renaming them. Say hello to "Sprints"! Sprints are another forcing function. They are, in effect, due dates! True story! Deliver smaller chunks of value every two weeks. Welcome to the velocity grind! Another VERY misused concept. "Take on more story points", they will tell you. Increase your velocity... uh huh :eye_roll:...
Felipe, I wish you the best of luck with this mission. I would love to see/read some examples where you've successfully convinced a business to operate this way. Though, I'm not sure I'd be convinced that they haven't found a way to hide their old habits.
Let the poo-flinging comments ensue!
Thanks for commenting. As I've mentioned in the first article in this series, I'm not talking about zero dates. There are always cases where we need to commit to dates:
https://members.outcomeedge.com/i/143301848/im-not-talking-about-zero-due-dates
Bravo. I’ve shared this with my colleagues as many are focused on project completion since a big customer is asking for something… how does that help the overall product (what’s the objective….)?
Or how does that help your big customer? What are they trying to achieve?
One of the challenges of focusing on outcomes in B2B tech companies is that often your customer is a traditional IT department that is used to focusing on projects and due dates. In those cases, we often have to work with them to help them define their desired outcomes.
Hi Felipe. I will tell you something: this article is PURE GOLD! Thanks for it!
Thanks, I'm glad you've liked it. What were your main takeaways?
Hi Felipe.
I’m back, although later than I intended.
Your article will help clarify my explanations on why we need to think in terms of results, not projects, when working with OKRs. But do you know what one of the biggest problems is? The fact that in "Measure What Matters," there are examples that you cited as BAD OKRs, but because they are in the most famous book by the most famous author, they are considered GOOD OKRs. As a result, people who believe that OKRs should be used to accelerate projects will use John Doerr's reference to contest the ouctecome (results-oriented) approach of OKRs.
Another serious issue is that many people, especially in Brazil, have a huge difficulty defining the "from X to Y."
If the formula is Verb + what you're going to measure + from X to Y, the discussion starts with "measuring," because most processes—except for production and commercial ones—are not measured. And when they have the X, the Y is usually a guess, since people don’t take the time to analyze trends, scenarios or even historical data to define it.
Thank you, Felipe.
I'm making the last adjustments to a class on OKRs that I'll give in a couple of hours. One of the adjustments is an excerpt from your article.
That's why I'll mention the takeaways tomorrow.😉