Principles – The Foundation
One of the core things that I really liked about the 7 Habits of Highly Effective People is how it defines a meaningful foundation which is made up of Principles.
What is a principle? I used to define a principle as a rule I try to follow like always treat people nicely. The book defines Principles as self evident natural laws that exist in the world and never change. These laws define long term consequences for actions. Gravity is an example of a natural law. If we jump out of a window, we will fall. Whether we believe it or not, whether we value it or not, that is what will happen. If we are smart (and don’t want to seriously get hurt), we will “value” gravity. I.e. we will add the natural law of gravity to our values as important. Because we know the negative consequences of jumping out of a window, we will avoid doing that.
Similarly there are natural laws that are not physical but are similarly self evident. For example, there is a natural law that says if we act in a mean way to other people, in the long term, they will not want to be around us or work with us. It’s pretty self evident and I’m sure you have experienced this before. This will happen whether we believe it or not, value it or not.
Here are a couple of principles I was able to extract from the book which I thought were amazing because I’ve experienced them first hand.
You must diagnose before prescribing in order to truly solve problems. Here is a story from the book that easily demonstrates this. A guy goes to an eye doctor. He says, “Doctor, I am having trouble seeing”. After a minute, the doctor says, “oh, I know, I have the same problem, here, try my glasses, they’ve worked great for me, you can have them, I have an extra pair at home.” The guy puts on the glasses and says, “that’s terrible, I can’t see at all”. The doctor says “why, they work great for me. Try harder, have a positive attitude”. The guy says, “I positively can’t see”. This story tells us that we must diagnose first before we prescribe, i.e. before we can provide accurate solutions. We know this principle is true in all our experiences but how many times do we jump to conclusions before doing this and as a result get it wrong? This happens in my profession, software engineering, all the time. Its so tempting to guess at what is wrong but we learn the hard way over and over that we must find “the root cause”, i.e. diagnose, in order to be confident in a solution.
A second example which is just as powerful is we must have an accurate map in order to get to our destination. This is best exemplified in a short story. Imagine you were in Boston with a paper map, and due to a printing error, you had a map of Chicago labeled Boston. You can try using the map to get to your destination but it wouldn’t work. You can try harder, you can have a positive attitude. It still would not work but perhaps you would not care because you had a positive attitude and would be happy anywhere you ended up. Now, if you had an accurate map, then trying harder and having a positive attitude would actually work amazingly. How many times have we experienced this in different terms. We tried to achieve a certain goal using a plan or method that simply does not work?
One of the examples that comes to my mind which is relevant to our Yomez app is the “Waterfall” planning method versus “Agile”. Waterfall says we plan everything and all the dependencies before we start a project. You have probably seen one of these plans in the form of a Gantt chart where items in a top row have lines to other tasks which must be done first. It almost looks like a waterfall with all the lines pointing down, hence the name. This method, aka”Map”, does not work well for various reasons. A project can take a massive amount of time to plan, can last years, and is inflexible to change. If the business situation changes, the whole project is at risk. Any changes, can take a long time since all dependencies have to be figured out ahead of time.
Alternatively, another Map called “Agile”, based on the game Rugby, was invented to address the issues above. In Agile, a team defines tasks in a list which is called “the backlog“. The team then defines small “sprints” which are chunks of time that are small but allow actual progress to be made. Items from the backlog are added to a sprint based on the needs/goals of the team, the sprint occurs, progress is made, and then the process is repeated. During a sprint, the tasks are kept stable so that the team can actually make progress. I have seen and used this approach for the past 10-15 years and it has worked extremely well. Why? Assume your sprint is 2 weeks. You only need to have detailed planning for 2 weeks worth of tasks at any one time. You can change course every 2 weeks as business needs change. The team can focus and work for 2 weeks without disruption. Based on my experience and many others over the past 20+ years I would argue it is a more accurate map to accomplishing goals than waterfall.
There are many more principles and I will cover some more in future blog articles. The major thing I learned is that these principles exist, do not change, and have predictable long term consequences. They work outside of us. We can choose to “value” these principles and choose our actions with them in mind if we want the positive consequences. We can also choose to ignore them, but keep in mind what can happen when we ignore obvious laws such as gravity!
If you enjoyed this article and would like to receive notifications when new ones are published, consider subscribing to our blog at bottom of this article or top right of page.
