This final post in the series (see Part 1 and Part 2) examines failure, mistakes, destruction, and ghosts. Since I wrote this around All Hallows Eve time, it seemed appropriate. I am fascinated at what we choose to fear and hide or how we deflect from the core problems or blame. Thinking of my career, I make the most progress with personal and professional growth in environments where I am allowed to experiment, hold discourse, disagree, and derive a solution instead of living in fear of “getting it wrong”. Leadership’s responsibility is creating environments of trust and safety, improving the delivery process by listening to their teams, and implementing ideas. Read on.
10. Failure counts as done. So do mistakes.
Getting done means we learned something. Something either worked, or did not work, or worked in a way we didn’t expect. Failure means we can now move on to the next thing, which will either work or not work. (See Scott Adams’ Secret of Success: Failure.) It is OK to fail as long as we learn from it — that we learn what not to do as well as what to do.
A saying I like from my time in lean operations at a health insurance company is “fail forward fast”. It means that sometimes failure happens and it is just fine, and it is better to find out sooner rather than later. This is because it helps us get to the done we want to arrive at. Riddle me this … if you are going to fail (and you sometimes will), would you rather fail quickly or slowly? Me, I want to do so quickly and learn what works. In general we have this fear of failure. I believe this is because we may have been victim to management that punished failure instead of fostering an environment of learning. This leads to dysfunctional political posturing, CYA actions, and a legalistic “document everything up front” behavior in the belief this will mitigate failure. Here is a thought … what if we embraced learning and mitigating failure by finding mistakes quickly. This is just one of management’s responsibilities in a lean culture: Create a learning environment and help teams find and correct mistakes quickly.
11. Destruction is a variant of done.
Some things should be destroyed, like old dilapidated buildings and zombies, and old crappy code … and zombies (cuz they just keep coming at you). Think of the mythical phoenix. Its destruction makes room for the next iteration or version. If you don’t need it, destroying it creates less complexity. If you need to improve it, start killing it off and replacing it with the next version. It’s ok to let go of bad investments and code that just is not allowing us to get stuff done as effectively as we want to.
12. If you have an idea and publish it on the Internet, it counts as a ghost of done.
But ghosts have no real substance. This is exactly like a ginormous requirements document — it has no substance and it is a ghost of done. Done is taking what you wrote about in the requirements document and actually giving it life. Done = Life, and ain’t life grand?!
Alternatively, if someone picks up your idea that you published on the Web and then creates something (like the thought leader behind Tesla, Elon Musk, publishing his short and succinct idea for a high-speed train called the Hyperloop), then you contributed to done, but you didn’t get it done. Since an idea is a ghost of done, why spend a lot of time trying to communicate it in a ginormous document when you can write it down as a placeholder, in a short sentence or two, which elicits real conversation that can lead to done?
13. Done is the engine of more.
<this space left intentionally blank> … well, with the exception of actually containing the words “this space left intentionally blank” because then it is not really blank, is it?! You are now done with your choice to read this blog, now go get other stuff done. And may the force of done be with you … gesundheit!
This work is licensed under a Creative Commons Attribution-NonCommercial-NoDerivs 3.0 United States License.