Contact Us

Use the form on the right to contact us.

You can edit the text in this area, and change where the contact form on the right submits to, by entering edit mode using the modes on the bottom right. 


123 Street Avenue, City Town, 99999

(123) 555-6789


You can set your address, phone number, email and site description in the settings tab.
Link to read me page with more information.

It only makes sense in hindsight

Improving Systems and Habits

Scott Miker is the author of several books that describe how to use systems and habits to improve.  This free blog provides articles that to help understand the principles related to building systems.  

It only makes sense in hindsight

Scott Miker

When you utilize the systems and habits approach to improvement, you likely don’t see everything clearly in front of you when you start.  Some elements seem easy some seem hard and some seem impossible. 

When I first started to improve a few areas of my life I had a very vague idea of where it would lead.  I always struggled with having a very clear vision despite reading over and over how important it is to have this vision in the early stages of goal setting.

I changed based more on gut feeling and based on the direction I wanted to take my life, not a specific vision.  It is one of the reasons I tend to recommend action over goal setting.  Action moves you towards success and without it you merely remain a dreamer with clearer dreams. 

With some areas it definitely pays to have a concrete plan before getting started.  We probably wouldn’t set out to build a house without a blueprint and a plan.  But even times when we think we should start with a rigid plan, it isn’t the case.

Software development started out decades ago using the same rigid project management approach as building a house.  The developers would meet with the person wanting the final product built and would explain what they were looking for.  They would have meetings to clarify exactly what they would build and then set out to build it.

But what tended to happen was that the product that was built was actually much different than what the person wanting the product thought they explained.  Many times they were left disappointed with the large investment they made into something that didn’t function the way they intended. 

Over the decades people started to realize the difficulties in building software in this manner and set out to change.  In 2001, a document was published that finally brought these naysayers together and formed a new way to see project management in software development.

When the Manifesto for Agile Software Development came out, it started to slowly impact more and more developers and the way project managers tackled big projects.

Instead of relying on in-depth conversations in the early stages, agile software development relies on small changes done quickly (usually over 2 week periods called sprints).  Then they regroup and reevaluate the project to determine the next sprint.  They can develop a roadmap of future work that outlines what they will do to achieve their goal but they don’t plan out every detail.  Instead they make the decision for the upcoming sprint and then reevaluate after the sprint.

This really is a very different way of thinking about project management but it also mirrors the systems and habits approach to improvement.  Instead of hoping to have a clear vision with every step early on, we take small changes and work iteratively in order to keep improving.  As we make progress the final project becomes clearer and we can adjust if that vision isn’t what we really need. 

In Brain Briefs by Art Markman, PhD and Bob Duke, PhD, the authors tell a story of how they started working together.  Then they say, “The funny thing about the whole story is that it sounds a lot clearer and more consequential in hindsight than it did when all of this was going on.  Life doesn’t have a clear narrative as you’re living it.  You often don’t know what the important events are going to be until long after they happen.”

Life happens in this same manner.  It doesn’t start with a clear path that we simply follow the plan and it all works out perfectly.  It is more like software development because we really don’t know how everything will turn out.  Some elements will be more impactful than we can predict and some will be less.  Things that have an impact might not even seem possible right now. 

By staying flexible (agile) and working iteratively we can be assured that we are constantly reevaluating in order to make the best use of our resources and take the best next step that we can.  And when we turn around and look at our path, it suddenly looks much more deliberate and clear than it does when we start out.