Adam Bullied wrote a really good article about not losing motivation in the face of challenges. His closing quote spun us off on a philosophical tangent about being “good enough.”
I’ve enjoyed several great conversations with Adam over the past couple years. I thank this blog as the catalyst for introduction to him and other really sharp folks, many of whom generously contribute to the discussion that launch themselves from some of our articles. Thanks to all of you!
Adam’s article wrapped up into three general ideas for me:
- Good general advice (don’t get discouraged by external events).
- Good product management advice (focus on the problem).
- Pragmatic execution advice (be good enough).
On the first point – just go read Adam’s article. You’ll like his writing, and you’ll find a new blog to read regularly (if somehow you aren’t already).
On the second, Adam says the following (the links are ours):
You need to just do a few things really well. In fact, things I’ve already mentioned:
- Ensure you are solving a problem
- Align things from top to bottom
- Execute — quickly and with confidence
This “top-down” stuff I speak of is from the vision / problem identification, to the roadmap, to the requirements, to each release being pushed out the door.
Don’t Get Discouraged, Adam Bullied
Good Enough (For Now)
Adam’s third point, about being good enough, I believe, is an encouragement to make progress, and move the ball forward in the face of adversity.
Perhaps it’s my own character flaw, but my first instinct was to think of his comment out of context. I’ve always believed that “good enough” is the enemy of great. “Good enough” can be interpreted as “do less than you can.” That’s not what I think Adam is saying, although that’s the thought that popped into my head at first. Adam’s point is really a good one – don’t let the fact that you can’t make something perfect today prevent you from making it better today. Tomorrow you can make it better still. Add up enough tomorrows…
Maybe this distinction is why I like the underpinnings of agile (iterative) development. Find the most important thing you can do today and do it. Tomorrow, you will be smarter, having done something already and learned from it. You’re in a position to better understand importance. Use that learning to do the most important thing you can think of – even in the unlikely event that the most important thing you can do is refactor what you just did the day before. Over time, things get better.
Good enough for now means do the best thing you know how to do today. Don’t hesitate because you suspect there is something even better you could do, if you could only think of it.
Maybe this nuance is not communicated well by some proponents of agile development. Many smart people rail against the hyperbole of big-A Agile, and throw the baby out with the bathwater and discard small-a agile.
Present yourself with two possible approaches to deciding where you will live for the next fifty years. The first approach is to decide now (but you have a month to do research and make your decision), and no matter what, you have to live there for fifty years. The second approach is to decide now (and your answer must be given in the morning), but if you decide after a year that you want to live somewhere else, you can move. And every year, you get to re-assess and stay or move.
I like this better than the classic “build a house” analogy, because it represents both the cost of change and the impermanence of decisions in a way that is more aligned with software development. It also allows for some other analogies. If you know that you may decide to move again in a year, you’ll make different investments in your new abode. You may choose to live minimally to reduce the cost of moving again. You may become an expert at moving. And you can easily balance the cost of any particular move with the perceived benefit of making the move. “Not worth it?” stay where you are. As you learn more about where you live (and where you might live), you develop a better appreciation of what is important to you. My guess is that sometime well before the fifty year mark, you would have settled in on the “perfect” home.
Now what are the odds that the perfect home after several iterations of change is the exact same home you would pick with a month of research and no experiences?
Each home is good enough for now, and likely to be better than the last home (after all, you’re smarter each time you move than the time before). And you stop moving when the opportunities to improve fall short of the cost of making changes.