How Good Is Good Enough? (#14 - 5/11/23)
In your day-to-day, how good is good enough?
Spoiler alert and cop-out answer, it depends.
The answer is different per person, per situation, and per company. Some examples of what I mean.
For documentation, 40% is good enough to get it in someone’s hands for review/early feedback
For change management, 80% is good enough because you can’t predict everything
For reading books, 10% may be good enough, depending on the outcome you are aiming to achieve
For releasing feature sets, 50% may be good enough as long as it allows you to test or experiment with a small blast radius
There are certain scenarios where only 100% is good enough, like building and maintaining elevators, but in tech and in business, an acceptable version is likely less than 100%.
As an IC, my sense of good enough was: does the thing work as intended without bugs, and look the way it was designed (for the most part)? By staying mindful of when something was good enough, I learned how to push projects through on tight deadlines. I also learned that maintaining such projects can be brutal. Work to identify best practices with your teams and determine the line of “good enough” in your work.
In my mind, “good enough” is important to keep in mind, because most businesses can’t run on perfection. Startups that aim, aim, aim, aim, aim, then fire are usually too late on the uptake and someone else has jumped ahead of them. Think in simple terms. How do I get this out of my head and into someone else’s hands quickly, with the lowest risk? Knowing what you’re worried about and why will help you increase the speed.
Thinking about risk can be paralyzing, but the more comfortable you get, the faster you can go. I work on this weekly by writing down the risks I know I’m taking and the risks I’m worried about taking. By putting it on paper, it becomes more real, but when it’s real it means it can be solved. Don’t stew for too long with something in your head alone. Tell your dog, tell a piece of paper, tell anything or anyone to get it out in the open. Once you understand the risk, you can make a better assessment of what "good enough” looks like.
In what categories do you aim for perfection? In what categories do you spend less time worrying about perfection? Let me know in the comments below!
What Made Me Think This Week:
Workers Now Spend Two Full Days a Week on Email and in Meetings - WSJ
Real-Time Shipping Visibility, Thanks to Predictive Analytics - Multichannel Merchant
On hiring, rehiring, and one question to answer them all - Jason Fried
Executive Coaching Can Be Your Secret Weapon - Sean Byrnes
Why Few Organizations Adopt Systems Thinking - Russel Ackoff
I'm an entrepreneur who lost myself to mental burnout until 3 simple habits helped me recover - Insider
Extra Nugget
I was sent this article earlier this week: Use this 2-word phrase when your boss asks you to do more work than you have time to do, according to a therapist. The thought behind it is nice and gives individuals a better way to say “no,” but there are times where the answer should be “no.” Saying “no” is painful. I did it this past week and was in my head the whole time afterward, but it got others to think more critically with me about why the request could or couldn’t be done, and to what degree.
Brandon Smith, the therapist interviewed for the article notes, “You always want to treat a boss like the number one client or customer,” but I disagree. If your boss doesn’t have a good sense of what’s already on your plate, then one of you is not getting the right information out in the open. A boss should be a partner, and while you want to do good work for your boss, it shouldn’t come at the cost of saying “yes” to everything. Same conclusion, different approach.
If you find yourself saying “yes” too often with your boss, broach that conversation. Don’t jump directly to “yes, and…” as it won’t get to the root of the problem.
What I’m Reading: Build: An Unorthodox Guide to Making Things Worth Making
Tony Fadell led the teams that created the iPod, iPhone and Nest Learning Thermostat and learned enough in 30+ years in Silicon Valley about leadership, design, startups, Apple, Google, decision-making, mentorship, devastating failure and unbelievable success to fill an encyclopedia.
This is another reference book for the engineering leadership shelf. Fadell’s candor and overall tenor are the right mix of amusing, direct, and insightful for anyone to learn something new. A quote from today I found helpful, especially for younger leaders:
Don’t worry that your team will outshine you. In fact, it’s your goal. You should always be training someone on your team to do your job.
Thinking about a world where everyone else is growing into the tasks that make up your day-to-day is scary, but it’s critical for moving up. How this book wasn’t on my radar last year is beyond me, but I am glad I found it.
As always, let me know below if you have any thoughts, questions, or comments!