Back at Facebook, I used to always show up to the 6 months performance conversations with my manager wearing one of the FB old-school SWAG t-shirts. It was made to mimic the posters we had around the office. It said "FAIL HARDER". I started doing that after I received my first (and thankfully, last) "Meets most" rating.
More than anything, it was a reminder to myself that no matter what feedback I hear at this conversation, insightful as it may be, I shouldn't stop taking risks and pushing my own envelope. You only fail hard if you try doing something that's hard. Regardless, you keep growing.
This feels to me like a corollary to "good is the enemy of great, " which I buy into whole-heartedly.
I also wonder if those who settle for meeting (rather than striving to exceed) also buy into "perfect is the enemy of good enough." I suspect they do, but since I'm not in that group it's only speculation.
I realize that sounds somewhat self-righteous, which wasn't my intention. But I'll leave it anyway; I think the point is worth mentioning even if the language used isn't perfect.
As for “perfect vs good enough”, I want to add some of what I have seen. Engineers who tend to go for perfection often focus on non-business related aspects. For example, one could perfect the code (which is often comfortable), while ignoring inconsistencies in metrics (which are hard to analyze and fix). In that scenario, people feel self-righteous in their performance conversations: “I did a great job on the code and metrics aren’t really my fault”. Since the first business need is to move the metrics, spending time on perfecting the code while the metrics are lagging is viewed as a mistake by a manager and may even land a below expectations rating (depending on the person’s level and context).
Now, imagine a scenario where the metrics have moved “up and to the right in perfect unison”, and on top of that the code is clean and covered by tests. Now we probably talking about exceeds. If you add great logging, real-time monitoring, and timely alerts, we may be talking about greatly exceeding.
So, to summarize, pushing beyond “meets” requires meeting (or exceeding) the business objectives while also being technically excellent. However, if people over-focus on technical excellence and play fast and loose with the business objectives, the rating may end up being very disappointing relative to the expectations.
Back at Facebook, I used to always show up to the 6 months performance conversations with my manager wearing one of the FB old-school SWAG t-shirts. It was made to mimic the posters we had around the office. It said "FAIL HARDER". I started doing that after I received my first (and thankfully, last) "Meets most" rating.
More than anything, it was a reminder to myself that no matter what feedback I hear at this conversation, insightful as it may be, I shouldn't stop taking risks and pushing my own envelope. You only fail hard if you try doing something that's hard. Regardless, you keep growing.
"It’s only when you draw your own map that you can arrive somewhere others don’t expect." Words to live by.
This feels to me like a corollary to "good is the enemy of great, " which I buy into whole-heartedly.
I also wonder if those who settle for meeting (rather than striving to exceed) also buy into "perfect is the enemy of good enough." I suspect they do, but since I'm not in that group it's only speculation.
I realize that sounds somewhat self-righteous, which wasn't my intention. But I'll leave it anyway; I think the point is worth mentioning even if the language used isn't perfect.
I agree with “good is the enemy of great” part.
As for “perfect vs good enough”, I want to add some of what I have seen. Engineers who tend to go for perfection often focus on non-business related aspects. For example, one could perfect the code (which is often comfortable), while ignoring inconsistencies in metrics (which are hard to analyze and fix). In that scenario, people feel self-righteous in their performance conversations: “I did a great job on the code and metrics aren’t really my fault”. Since the first business need is to move the metrics, spending time on perfecting the code while the metrics are lagging is viewed as a mistake by a manager and may even land a below expectations rating (depending on the person’s level and context).
Now, imagine a scenario where the metrics have moved “up and to the right in perfect unison”, and on top of that the code is clean and covered by tests. Now we probably talking about exceeds. If you add great logging, real-time monitoring, and timely alerts, we may be talking about greatly exceeding.
So, to summarize, pushing beyond “meets” requires meeting (or exceeding) the business objectives while also being technically excellent. However, if people over-focus on technical excellence and play fast and loose with the business objectives, the rating may end up being very disappointing relative to the expectations.