Simplicity. Why do we, in general, get so hung up on getting stuff done?
There are two things that I wish everyone could experience. One of them is driving on the autobahn in a Porsche 911 at over 200km/hour. The other is for software engineers to experience building and delivering product from scratch in a technology startup.
If the first wish came true, then I would not be stuck behind slow drivers in the fast lane. It is a PASSING lane people, and I mean pass within the next hundred feet, NOT mile. Pass and move over, don’t police me by thinking I should obey the speed limit (speed limits are suggestions in my mind). Thus, I love the autobahn. Germans know how to drive.
Another wish is for all people in the software world to experience living and succeeding at a product company startup. Like driving on the autobahn, startup companies must move. Startups must get stuff done — or they will not be around. When they finally ship, it is in hope of being successful. My experience in a startup taught me the fine balance of what we now call a minimal viable product.
A couple of years ago I came across this poster at Microsoft about the cult of done. We talk a lot about getting to done, being “done done”, exit criteria, acceptance criteria, and definition of done, definition of ready, and so on. These are all good implementations of the practice of getting done.
Please keep this in mind as you are reading this, in all things we need a goal or target. Getting to done does not mean we don’t think about where we are going, we actually do. It means we create goals based on the information we have today, and then adjust those goals as necessary when we get new information. So with this thought, please read on.
The principles of being done happen to reflect my experience in a startup. My inspiration for what you are about to read below comes from a very simple list in a post entitled the “Cult of Done” and the points in this series of blogs come from there.
1. There are three states of being: Not knowing, Action and Completion
I will only take a moment to discuss the “not knowing” state. Your sole purpose when faced with “not knowing” is to start knowing, quickly. It fascinates me when people batch up work into ginormous requirements documents and treat all of those requirements as the same. Instead they should start working on what they absolutely know needs doing. Then they can figure out what they don’t know by creating short experiments to begin knowing. If a team is faced with considerable risk due to a lack of knowing, that team should start work on experimenting to gain knowledge. You can’t get to done until you start, so start building or start learning what to build by creating experiments. In both those cases, start creating something so you can get to done.
2. Accept that everything is a draft. It helps to get done.
Too often I have heard the words “But we might have to throw it away if we don’t get it right,” to which I reply “…and … <pause for effect>, how do you know it is wrong or right until you get feedback? You can’t get feedback on what the thing should do until you actually start to build it. So guess what, you will have “throw away” work because you are going to learn later what to keep and what not to keep. So quit your whining and get it done.”
I can tell you that some of my most fun in architecting products has been in discovering and saying out loud “… well that was complete crap! Next option?”
3. There is no editing stage.
Well, there actually is, it is when you are typing and you hit the backspace and retype. Other than that, build in small increments, validate in small increments, get feedback in small increments, deliver in small increments … get the idea? Small feedback cycles are much more conducive for achieving success. The longer you edit, the longer it takes to get to done.
In my next post, I share some other principles to ponder.
This work is licensed under a Creative Commons Attribution-NonCommercial-NoDerivs 3.0 United States License.