BLUF: You will become quickly disliked if you are taking out one’s punishment on the group.
If you have ever seen Full Metal Jacket, then you remember a scene where Private Pyle is soap beaten by his platoon because they kept getting trouble for his mistakes. It is common, especially in military, to ensure everyone suffers for the mistakes or problems that only affect a few people or one person.
In the corporate world we have a very succinct breakdown for business organizations. You can find the same thing in the military. We have organizational control called detachments that have 1 or 2 personnel from many organizational structures that make up the entire small detachment. This can include pilots, maintainers, medics, fuelers, and cooks.
This past weekend the entire detachment was being held accountable for 2 person’s tasks that were not complete. They weren’t complete because of inefficiency, they were just taking longer. Because they were not complete the entire detachment was being held up even there was nothing that they could help out with. This is like holding everyone responsible for HR’s pay period responsibilities and no one can leave work until they are complete. Punishing everyone for the “faults” of a few is no way to instill a great culture in a business.
You have to understand the other side of the coin on this. The point to punishing everyone for the mistake of one is to show that we are a team and we need to ensure everyone is doing what they are suppose to do in order to have the most efficient work. You have to use the common sense meter to determine what is overboard in punishing everyone for an individual task. This is a step in providing a great culture for people to want to be a part of.
BLUF: There are times when you won’t have 100% of the answers to create a plan. Creating a contingency plan is to account for the remaining percentage of the answers you couldn’t find.
Contingency plans are critical to any operations or projects. It is the “if X, then Y“. You have to be able to account for these possibilities. Play devil’s advocate or punch holes in the plan. In the military this is a common practice. After we devise a plan a group will provide all of the counter plans that the enemy will execute. This is all in the process of war-gaming. In war-gaming you answer all of those IFTTT questions.
In software development you can also apply contingency planning. Have you ever been creating an architecture design that requires other teams to provide services or architecture in order for your design to work? I run in to it regularly.
- What if we don’t have access to a SQL Server database?
- Who controls federated logins?
- When will customers transition?
What is your plan at certain decision points? At some point you have to just build your solution knowing that you no longer have the ability to talk to a SQL Server instance and you have to use PostgreSQL. You have to run with it. Do you extend your deadline claiming you couldn’t get it done?
Always have a contingency plan for your project critical paths. A contingency plan is not pivoting. It is providing a solution to get over blockers or hurdles, and sometimes that solution is compromising with the product owner that there will be risks in the application if we cannot do things a planned way. Eventually you need to accept the risks or mitigate some or all of them. Only after that will you make the decision to not deliver on time because the risk is catastrophic to cause customer issues – exposing confidential data.
It doesn’t take long to run through some simple scenarios where you think something might go wrong. Cover your bases in the situations that you don’t have accurate or unknown answers. What database will you use if you don’t have access to a SQL Server instance at the current moment when you are designing and planning.
BLUF: Observe, Orient, Decide, Act (OODA)
As an aviator in the military there is a need to constantly scan your flight instruments and make quick corrections to maintain comfortable flight. These constant corrections lead to a smooth and level flight. Subconsciously you make decisions all the time, but the OODA loop is an explicit to make decisions quickly and always assess the next step to make another decision. This is an everlasting cycle.
Every situation that you encounter where you need to make a decision requires you gather as much information as possible. You will never be able to get 100% of the information you need to make the best decision, so you have to do your best to gain enough incite to make the best decision.
Now that you have a good source of information you need make a plan of action. You must be willing to look at multiple courses of action that involve a IFTTT plan of attack. In the military we look at two enemy courses of action (COA) at a minimum; most likely and most dangerous. Your job, once you have gathered information to build opposing forces course of action, then you can create your own course of action.
Now you have to make a decision. Choose which course of action best fits the situation.
This is self explanatory. Don’t waste time with the first three steps if you can execute to effect change.
The beauty of this process is that you can apply it to small decisions or big decisions. It allows you to quickly assess a situation, plan an action, decide on an action, and execute. I have always heard that it is better to make an 80% decision quickly, then make a 100% decision late. Don’t wait until it is too late to change the status quo. When the status quo changes then you start the cycle again.
Balancing risk and information will lead making great decisions. My senior pilot kept saying in certain situations – “This decision will either make you a hero or a zero.” When you think about that with the balance of risk and information, then you are taking a big risk on just enough information for you to succeed, but the risk is so large that if you succeed, then people are amazed at your wizardry, but if you fail, then everyone will tell you how stupid that was.
Having people make decisions to help you before you even ask them is the best situation to have as a leader. It means they understand your vision and guidance without confusion or misunderstanding. As part of the military there is a process known as the military decision making process (MDMP). The goal of MDMP is to provide a process to find the best solution to a problem. It is geared specifically to small or large scale military operations, but you can apply it to everyday tasks or problems.
- Receipt of Mission (What is the problem?)
- Mission Analysis (What needs to be done and what are factors that are effecting the solution?)
- Course of Action (COA) Development (What are the viable solutions to solve the problem?)
- COA Analysis (What is the result and overall effects of each COA?)
- COA Comparison (What are the compromises or pros and cons to each COA?)
- COA Approval (Which COA is the final one to execute?)
- Orders Production (Who needs to know what to do during the execution of the solution?)mililea
These steps occur in order, but you might have used these similar tactics to solve a problem without a full 7 step procedure. Apply this process to pouring a glass of milk when your current position is sitting on the couch. It might seem dumb to ask yourself 7 questions to get this problem solved, but you do it without even realizing it because it is natural to you. This vignette seems very watered down to the normal situations where you would apply the MDMP process.
If we dig into some of the sub parts of how a staff or team utilize this process we have to start with some common understanding. Common understanding has to start with the leadership or commander. An output from step 1 is the mission and the intent. These two pieces of information drive the entire process to a successful end. If a member of the team does not know what your goal/mission is, then how to expect them to do work that relates to the final product? What about if they don’t understand your intent and they accomplish a product that solves the problem but they added or removed features from the final product that doesn’t meet your criteria? How can you expect your team members to make decisions or take action in your absence without understanding these two key items? You might think that they are not doing good work and therefore might lead you to micromanaging their every move when in reality you never gave them understanding or enough information for them to execute your plan.
In steps 2-5 team member(s) are left to come up with a plan of action to solve the problem. During these steps the team will have questions that come to light. Answers are provided by me or the team to keep everything rolling along. In the end there will be one or multiple COAs. This all leads up to step 6 where my team brings me all the solutions that they have come up with and we decide on a single solution. Once the decision has been made for a solution, then it is time to execute which is step 7. During this entire process the team has been collaborating and all should be close to or right on track with the plan of execution. There is nothing to go back on once you hit step 7 unless you need to inform other parties that were not involved in the MDMP process.
One of my goals as a leader is to delegate tasks. I can’t do everything and I have to trust my team to execute effectively. In order to delegate to the other team members they have to know your expectations which would all be laid out in the mission and intent. This all leads to effective teams that are proactive and productive.