Making fast and informed decisions

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.

Managing Expectations

BLUF: Always present realistic expectations.

One of the biggest issues that I always see with software projects is timing.  Either from developer inexperience or misunderstanding of the problem, but there always seems to be a example of over promise and under deliver.  We all know this to be the opposite of what you should follow.  Always under promise and over deliver, but don’t do it so much that people expect you to be super conservative with your estimates.  It is your job to estimate a project timeline and what tasks can be accomplished in the time given.

You need to have regular meetings with your stakeholders to keep them informed.  If something happens to the project that needs to be addressed before the next meeting so that your team can move forward, then gather information, inform the stakeholders, and make a decision.  Recently we had to make a decision to refactor our front end code base from Knockout.js to AngularJS 4.  We had a deadline looming in 4 weeks, but in order to move forward and not waste more time with Knockout.js development we needed to have an extended runway.  I quickly asked the boss for an extra 4 weeks to make this happen now and feel like we weren’t running in place.  After laying everything out we got our extra 4 weeks.

That boss was the CEO.  I had to tell him that we weren’t behind, but that this would a great benefit to us in the long run.  Obviously I can’t and don’t get a lot of face time with the CEO, but I needed to go straight to him and let him know what we wanted to do, so that he could make the business decision.

We still have to maintain all expectations.  My team is rebuilding the flagship product and we receive requests all the time from the “good idea fairy (GIF)”.  These are the sales and marketing teams that start off with “You know what we could do….” or “What would be great is…”  These are the beginnings of an extended project timeline.  A customer has not even seen our product yet.  We have to be able to say a resounding “No”.  Not a “We’ll see” or a “Maybe” knowing we will never get to it.

I am not the most experienced developer, so estimating getting something done is not always the easiest task and sometimes I have to overcome inexperience in estimations with extra time to make sure I get done what I said I would.  I have to stand by what I said or have a really damn good reason as to why I did not make my deadline.  We don’t build mission critical systems, so I am lenient on myself with 100% code coverage and every feature working flawlessly, and I definitely fall in the camp of putting documentation off until last.

Things happen and events occur.  You cannot prepare for everything, but you need to be able to communicate how something is effecting your project, so being well informed all the time enables you to provide better expectations to stakeholders.

Volunteer To Tackle Problems

BLUF: Don’t complain to people unless you have a solution that you think is viable.

Everyone complains, and no one likes a complainer.  There is a distinct difference between my kids complaining to me about eating vegetables versus my team member complaining about using AngularJS instead of React.  If you are going to complain about an issue, then you need to have some assemblance of the solution to the problem.

We have issues that come up daily.  Most recently I had a team member bring up – “Why don’t we put in tickets for these issues that we are talking about.”  My response was:

Me: “Have you put in a ticket yet?”
Him: “No.”
Me: “You have access to do it.”
Him: “Well…”
Me: “You can put in the tickets.”

This is a simple example to illustrate what I am talking about.  Don’t mistake this for me getting annoyed or mad about him saying something.  We have to be able to call people out at any level.  If my teammates cannot tell me that my code sucks or my tests are failing, then we aren’t a team.  What the take away is if you are going to complain, then make sure you follow it up with a solution.

Him: “Why don’t we put tickets in for these issues?  I’ll add that to my daily tasks today to make sure we capture these issues for later when we have time.”

Look, I am stressing the point.  I don’t expect a team member to have this very “elegant” sentence, but the bottom line is that I want my teammates to be thinking ahead and not just what’s in front of them.

You should be the one that wants to volunteer to solve the hard problems.  This action will garner you career capital.  People will seek you out for your input, and you are solving the problem that no one wanted to.  People always solve low hanging fruit problems first, which leaves a lot of undesired issues to be tackled and these are your money makers.

Go out of your way to solve issues.  As a leader you don’t let a problem persist.  Attack it head on, assess the problem, and implement a solution.  These things can spin out of control quickly.  I had a commander once tell me that small problems in mass can cause a catastrophe.  We need to be able to break the chain of events before the catastrophe.

Lead By Example: Characteristics

When I first entered the Army the Chief of Staff of the Army posted his book list for leaders; The Mask of Command, The Face of Battle: A Study of Agincourt, Waterloo, and the Somme, For the Common Defense: A Military History of the United States from 1607 to 2012, 3rd Edition. I also had a reading list when I talked to outside help regarding my transition from military to a civilian career; How to Win Friends & Influence People, Topgrading, 3rd Edition: The Proven Hiring and Promoting Method That Turbocharges Company Performance, and Winning. There was a common theme to everything. You have to lead by example. My last post was a small taste of leading by example. It is really like a stepping to stone to being a good leader. Can you do the small things that allow you to have an impact on subordinates?

The are a litany of characteristics that you can debate on what makes up a good leader, but I have my personal ones that I think are important.

  1. Listen
    You have to listen to others.  It shows that you care what they are saying.  Let others do the talking in conversation.  Engage them by asking questions about their life and what’s going on with them.
  2. Honesty
    You have to be able to talk to people about what is going on in business or life.  If you don’t want to be honest with someone, then don’t engage in the conversation.  I always want transparency with my team and even further with interviewees.  I definitely don’t want to misrepresent what someone is getting into when I hire them.
  3. Flat Organization
    Treat everyone as an equal.  Even the brand new teammate can bring insight into your organization.  Unless you are going to school everyday, reading every blog, and reading every piece of documentation there is no way that you can be an expert on everything, and even then I don’t think you are an expert if you do those because you don’t have the experience in implementing the learned principles.
  4. Know Your Faults
    You have to acknowledge where you are lacking.  As previously said, you cannot know everything.
  5. Responsibility
    Your team, your product, your failures.  You have to take responsibilities for any failures; big or small.  You will lose trust in all of your teammates if they get a whiff of any lies or long paths of ambiguity.
  6. Do The Work
    You have to be able to get your hands dirty once and awhile.  Don’t ask people to do something that you are not willing to do on your own.  You have to be able to do the lowest level work.

Leading by example is a core tenant of being a great leader.  If you can do the lowest level of work, then you can mentor and lead all levels to the final product.  You also show the ability to delegate tasks effectively because you know what needs to be done.

Leaders eat last

When I started out in ROTC there was one lesson that everyone had to learn. Let your soldiers eat before you. Make sure everyone gets something before you do so that you ensure your soldiers are taken care of. This is selfless service and puts those interests of your team above your own. It shows them where you stand and exemplifies what you expect.

If you go through every day putting your team’s best interest above your own self interest and self serving actions, then you ensure a reciprocal response from them. For example, when the website or server goes down over a holiday weekend and you need the team to get it back up. People are going to bitch in this situation no matter what, but they know that they aren’t doing this because you are lazy or don’t care. You have shown them already that you wouldn’t be asking for help if you didn’t truly need it.

The concept of Leaders eat last will permeate through your organization and get noticed, but especially building your team culture. It is the simple step that you can take that doesn’t cost you anything. You will not starve, I have learned that too. Over the course of 4 days I trained with zero food except for a handful of rice, literally. I am not saying fast all the time, but you can certainly wait at the end of the line to make sure there is enough to go around for your subordinates before you dive in. If there isn’t enough, then there is always tomorrow.

Having a strong team culture is always your ally in a battle. You don’t have to go out for happy hour every week week or do forced team outings, but when people show interest in getting together, then let it happen. These actions will encourage camaraderie (huge plus!), candor (always helpful), and friendship. If you don’t want to be in the trenches with the guy next to you, then it might be time to step away from the project, team, or company.

Take the small steps up front to show your team that you can be exemplary of what you expect. Small selfless sacrifices can pay you dividends when needed.

BLUF (Bottom Line Up Front)

A common term that I always see in the military is “BLUF”; Bottom Line Up Front.  A synonym for this you find on the internet is “TL;DR”; Too Long; Didn’t Read.  These terms are used when you want to tell people the main point of a long diatribe.  People don’t have time to waste on reading your reasons and insight into an issue or an informational email.  Sometimes all of that filler information is not necessary for a leader to make a decision.  They just want to know cause and effect, or they are looking for the exact issue and don’t want to parse it out from a long email.

Always start your emails with a BLUF.  Give people the meat and potatoes of the information up front and if they decide to dig in beyond that, then they can, but the less than 30 seconds that it takes you to  write the BLUF will save everyone anywhere from 1-5 minutes of reading the entire email and extracting the information that they need out of it.  Beyond the BLUF emails should be short.  Don’t waste more time writing a book that no one wants to read.

Start inserting this into your emails and you will soon receive questions about what BLUF means.  Instill this culture into your company to save time.  There are other small actions you can take in emails to make sure people are getting the most out of your emails.  Prefix your email subject or email body with the following:

  • ACTION – The receiver needs to do something.
  • RESPONSE – You need an answer from the receiver

When the email protocol was originally created it was not meant to be a fulfilling system, but we expect so much more out of it in today’s businesses.  I have seen people expecting magic out of it.  “Well, I sent you an email about it…” If you put me on the CC or BCC line, then that email was not meant for me.  Make sure you are providing accurate details in your email to ensure the best response from the receivers.

Tactics vs. Strategy

Recently I have been talking about how vision, mission, and intent are all important pieces to helping you as a team leader.  All of these can be wrapped up into one concept – strategy.  Strategy is your conceptual plan to “attack” a problem.  If you are a collective organization, then understanding why you are doing something is to understand strategy.

The difference between tactics and strategy is short game vs. the long game.  The strategy is the route to get to the end, and tactics are the instantaneous changes that are inputs to keep the strategy on the correct route.  There is a common phrase used with planning in military – “The plan goes out the window when the first bullet flies”.  You don’t have the ability to dictate what the enemy is going to do so that your strategy maintains the planned route.  Tactics are the inputs that can be injected in order to maintain somewhat of the planned route.  Servers will go down, code will be late, tests will fail, customers will complain, but you don’t know when or where, but you have to be able to flex with the change.


Over a decade ago I read a book on Bruce Lee’s Jeet Kune Do and he talks about how to be like water.  Water adjusts to the object instead of being a rigid, unchanging thing.  You have to have a very dynamic and flexible character in order to not get frustrated with the all that can occur.

Be like water making its way through cracks. Do not be assertive, but adjust to the object, and you shall find a way around or through it. If nothing within you stays rigid, outward things will disclose themselves. – Bruce Lee

Okay, tactics without strategy will produce crap.  Tactics are not rigid processes.  They are guidelines that allow creative and flexible people to make tactics fit the strategy.  Very elementary tactics in software are the coding standards that you employ within a code base, maintaining code reviews, continuous development pipeline, and documentation mandates.  These are all tactics to provide a better development experience, but how you apply these tactics to a strategy for a project could make the project more enjoyable.

How do you measure strategy?  There are plenty of mechanisms to collect metrics.  You have to be able to collect measurable metrics in order to help define if your strategy is working.  Another name you might know is Key Performance Indicators (KPIs).  Somewhere in your code you must capture and/or log actions that are occurring.  You can opt for the third party option and use easily implemented tools like New Relic.  Based on your collected data you can make decisions and implement tactics to mitigate any changes that might effect your strategy.

Strategy and tactics are some of the baseline functions of team culture.  Team culture has to be your main goal as a leader.  If your team culture is firing on all cylinders, then you will turn people into a machine of productivity on tasks and happier employees.  If the team culture is on the bad side of life, then you will have higher turnover of employees, reduced productivity, and a daily grudge of going into work.

Proactive Decisions

Last blog post I talked about the MDMP process in the military and how you can apply it to everyday problems.  I want to expand on this process just a bit and show you how to get your team involved in the process…

During MDMP there is a big chunk of the process that is completed without your input or decisions.  These are really mini decision points, but the big take away is that those decisions cannot be made without your guidance.  It all goes back to your mission statement and intent.  With these key pieces of information and confirmation that there is understanding and collaboration amongst the team, then you might as well micromanage the entire project and treat everyone like school kids.  Having someone lurking over your should every couple hours to make sure you are doing it their way is a sure fire way to make everyone on your team quit the project or even the company.  The best way to think about it is to become an enabler for your team and your teammates will hopefully reciprocate that love and enable you to accomplish your mission and goals.

There is a method to the madness of exposing your “vision” in a project.  When you let your teammates know what you see for the future of the project, then you empower them to help make decisions, add tasks, remove tasks from the board, and be creative!  What you really are looking for is for team members to step up and be proactive about what comes next in your project.  This enables you to worry about the nuances of being a manager: interviews, timesheets, and meetings (just to name a few). Yes, that’s the life of a manager role.  You have to keep the machine turning.

What does it mean to be proactive?  Well there is the definition, but my version is doing things that progress the betterment of the team.  This means to do the design up front, write the unit tests, and create some resemblance of common documentation.  I will admit, this is my order of priorities too.  I always leave documentation until last, but that also means that the team has to communicate in order to know what is going on in the architecture and system.  Therefore it really foster’s collaboration, right?  No, that is an excuse.  I hate writing documentation as much as the next person, but that is why they have a technical documentation profession separate from software engineers.  However fostering your team to be proactive when it comes to solving problems means that there is good communication and understanding amongst the group.  Your vision is being absorbed!

Now.  What is a proactive decision?  Simply put it is the pairing of someone being proactive that helps the team make decisions.  Trusting teammates to make decisions allows them to bring solutions to the table.  This eliminates you from the input to the solution.  All your job is to do is say execute what you have told me or tweak these things and then execute.  For example, recently I was having a conversation with a team member about how to execute and data reduction problem.  We had the option to write SQL to find the result set, or we filtered the problem through a structure procedure in a Storm pipeline.  After discussing both sides, ultimately the decision was to go either way.  “But that’s not a decision!”  Well, it is because I knew what the team member wanted to do, but I didn’t want to make that decision for him.  He just wanted my input.  I wanted to layout my concerns and priorities, and let him decide which way was better.  I give that mad props for coming to me with a solution already concocted and an explanation behind it.  Now I had to play devil’s advocate and find the shortfalls in the solution.  Eventually there is a pro and con to both solutions.  One of the solutions works really well now, but might not scale well in the future.  Do we really need to pre-optimize?  Never!

Foster your team to be proactive and create solutions.  Give them leeway to flourish  and don’t smother them by micromanaging their every process or decision.  Build a team that will be able to work without you.  If you aren’t needed anymore, then you’re doing the right thing.  It isn’t job security to keep so much on your plate that you fail at half of the tasks.

Decision Process

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.

MDMP Steps

  1. Receipt of Mission (What is the problem?)
  2. Mission Analysis (What needs to be done and what are factors that are effecting the solution?)
  3. Course of Action (COA) Development (What are the viable solutions to solve the problem?)
  4. COA Analysis (What is the result and overall effects of each COA?)
  5. COA Comparison (What are the compromises or pros and cons  to each COA?)
  6. COA Approval (Which COA is the final one to execute?)
    1. 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.