Introduction
Sometimes decisions comes out of nowhere and sweep execution in a random direction.
You know what I'm talking about.
You have a plan that outlines a path from A to B to C to D and suddenly midway through B, a leader comes in and declares you are now going to P. It does not seem that the leader has new data. To the contrary, the decision is often made in spite of a more informed decision.
This is a HiPPO born decision – or a decision made via the Highest Paid Person's Opinion.
The effect of this is a culture that feels rudderless, constantly spun around at the whims of the HiPPO. This is due to these invisible decisions where others in the organization do not understand where the decisions come from.
Often HiPPO cultures are extra stressful because they are very reactionary – almost emergency driven.
Even worse, HiPPO leaders often breed distrust. When the leader presents a strong opinion that others cannot understand, employees cannot easily challenge the decision from a logical stance. When they attempt to question the decision, even to just understand them, they are often labeled as problems, or not being "on board".
All this makes it near impossible for employees to drive in the same direction as the leader. In fact, they come to expect a reverse card to be played any moment so they can’t think long term. And putting in 100% effort on the current plan of action will just be a waste of effort because we are not going to finish that work anyways.
All of this cultivates quite quitting and absenteeism.
Warnings
The only way to deal with the HiPPO decision is to become a culture based on evidence, data, validation, and autonomy. Evidence and data are required to inform the right direction and perform tests to validate your assumptions. If you capture the right information you can make educated decisions, but you still need to define your hypothesis and measure your results against your expectations.
For example, in a typical agile world you are aiming to get usable software in the hands of customers as quickly as possible so that you can iterate off of the feedback. Commonly as soon as minimally viable feature X is put into production the team is then tasked to develop new feature Y. This means that your product is constantly in a state of minimally viable.
In this case, feature X is purposefully unoptimized in terms of performance. We wanted to ensure that we nailed the customer expectations for that feature before doubling down on optimizing the experience. As such implementation decisions were made to simplify execution, not for scalability.
If we never return to optimize feature X then eventually we may run into a performance bottleneck with that feature. In fact, what commonly happens is that we build a new feature on top of feature X’s base, creating a more widespread bottleneck.
So how do we know when we need to come back an optimize feature X instead of moving onto create feature Z?
Well, let’s say that you are logging and monitoring database execution times so that you can clearly identify what queries are taking the most amount of time. However, some queries are going to take longer than others by the nature of the work it is performing. So you can’t just scan down a list of execution times to know which queries need to be optimized.
To illustrate this, let’s say that you have two suspect queries and you only have time to optimize one. The first is a query that runs on every page load and it takes 4 seconds. The second is a search query and it takes 40 seconds.
Which query performance is satisfactory? Which is a problem?
It depends. Of course, queries that run on every page load are likely bigger candidates for optimization so you could decide to invest there. Yet at the same time, if the search query is locking tables and causing deadlocks then it may be the more important query to optimize.
So what is the answer.
It depends on your situation. The trick is to define performance expectations pre-implantation that the first query should run in 2 seconds and the second must run in 60 seconds. Then set automated operational trip wires for each query operation and monitor actual execution with expected execution.
In this case the "what should we optimize" is crystal clear, the first query is exceeding within the 2 second threshold while the second query is not exceeding the 60 second threshold. There is no debate as the data speaks for itself. Thus, no opportunity for a HiPPO decision.
But, what about non-programmatic decisions?
While code execution is easy to instrument to monitor decision performance, other decisions can be harder to trace to data driven performance monitoring.
In fact, product prioritization often feels like a dark art.
“Should we create a feature that will resonate with fortune 100 prospects, create features that will open up mid-market opportunities, or should we optimize a cumbersome administrative flow?”
While diving deep into goal decomposition and cascading metric systems is a topic that I’ll discuss in a future article, in short, when you are making a strategic decision you need to think “what business needle am I trying to move”. Then ask yourself if that needle is a leading or lagging indicator. If lagging then try to think of lower level leading metrics that could be monitored to show directional improvement.
For example, let’s say that you decide to invest to improve an administrative flow to boost your current North Star metric – NPS (note: unadvised). It will be very difficult to directly map this project to moving the NPS needle. Even if it does it will not show up on NPS measurements for 6-12 months from project kickoff.
So was it a good decision to invest in that feature?
Well, instead of measuring the effectiveness of that initiative on NPS movement alone, you should be looking for needle movement that is closer to the implementation.
For example, let’s say that the administrative process took clients 4 hours weekly and is estimated that it will soon take 1 day per week due to rapidly growing database table size.
You believe that the designed revisions will consistently reduce the process to 30 minutes monthly. And the impact of this for your clients is that they will not need to try to find budget to hire an additional administrator, or look for a competitive product to replace yours.
In this case it would be very hard to justify overall NPS to rise, but we can expect administrator cohort CSAT to boost due to the significant time-on-task reduction.
Yes, there will always be subjectivity to product prioritization – a perfect prioritization system does not exist. Yet comparing various investments against tangible results removes the invisibility factor for decisions. A list of “invest X resources to deliver Y measured results” makes for more fruitful decisions than “Courtney the complainer said they could not continue to use our product if we didn’t do XYZ”. (Yes, customers can be HiPPO’s too!)
QUESTION: So who should define the success criteria for decisions?
ANSWER: The person closest to the problem.
Who is that? It depends. In some organizations the product owner is the one who is closest to the problem, working daily with customers to fine tune the execution. Other times it is a PM, VP, or CEO who is the closest to the customer and validating the problem.
Getting on the HiPPO diet
What should you do if you fear that YOU are acting like a HiPPO?
First, soften your opinion by not stating it as "matter of fact". This opens up room for the conversation.
Second, elicit dissenting opinions by asking questions like "How will this end in disaster?" Openly seeking negating opinions will often allow others to feel comfortable with disagreeing with you.
Another way is to ensure that you are providing an environment where autonomy is truly delegated. A great tool for this is called Commander's Intent. With Commander's Intent you are providing enough context to ensure that the team ends up delivering the proper outcome without having to dictate the specifics of how to get there. I often use it with clients because it provides more of a paint by numbers approach to delegation.
LEADERSHIP TIP
Using a tool like the Commander's Intent is a great way to offer directional autonomy, which will energize your talented team of professionals.Do not hire chess players and treat them like pawns!
Let's take a closer look at how and why this works.
Commander’s Intent
Imagine you are a 3 star general during World War I. You have a military offensive that you need to lead. You command thousands of troops, all on different missions that fit together as perfectly crafted pieces of your strategic puzzle. You are running all of the decisions from the war room thousands of miles away from the action. You simply cannot be in every fox hole providing instructions to the front line. Yet you need every front line soldier to understand the mission with split second clarity so that they could make the right decisions in the heat of battle. As such, they need to understand the decision making directionality that the top brass would have made if they were in the same situation.
In other words, they needed to understand the commander’s intent.
The below model is a way to fill in the plan with enough detail to be informative and allow for autonomy to be delegated to the rest of the organization. Each bolded section is a prompt for you to fill in to document your mission.
Initial Situation
- Initial State – Here we must explain the initial state and the reason for action. This helps establish a landmark to evaluate progress and continually reflect on the reason for the project in the first place.
Outcome
- Mission/Goal – This defines what the mission is. It should answer in as few words as possible the “who, what, when, where, & why”.
- End-State – This is to paint a picture of what “success” looks like. The what/outcome, not the how.
- Key Results – This outlines how we are going to measure success of reaching the end-state. Often this comes in the form of checkbox style “yes accomplished” or KPI metrics that progress can be tracked against.
- Antigoals – This is used to eliminate potential future states or perspectives that are invalid due to leading execution in the wrong direction.
Execution
- Sequence – Once everyone understands the goals, we need to know how we are going to get there. This should be very high level sequence that allows for milestone project monitoring. This is generally used for high level resource planning and cross team coordination. Often this will come in the form of Quarterly goals or Project Milestones.
- Key Decisions – This is an ongoing register of key decisions that have been made. These decisions will define what subsequent options are available and which ones have been eliminated.
- Constraints – This identifies what boundaries the execution must stay within. This includes things such as resource constraints and regulatory limitations. Among other things, this can be timeline/deadline, available time/people, money.
Tools like this, as well as clear goal decomposition, provide general guidance for the execution while giving maximum flexibility for innovation. This tool is helpful for solopreneurs and large enterprises alike.
EMPLOYEE TIP
If your leaders are barking directions that you are being asked to follow blindly, you can use this same tool to be able to illicit the details you need to decloak the invisible decision making process. Then, if you do not agree with the decision after understanding the foundations, you will have the necessary knowledge to be able to offer alternative options. On the other hand, even if your alternative is not adopted then you are sure to learn why the original path is deemed optimal by leadership, which will provide you with additional context required for executing on the decisions.
Corrective Advice Recap
- Seek ways to get your team involved in decision making.
- Establish corporate and product principles to provide decision making ideals.
- Eliminate invisible decisions by being clear with the team on why these decisions were made.
- Provide space for allowing members to understand and challenge pre-committed decisions.
- Illuminate the underlying hypothesis and force yourself to document what result that you expect from the decision.
- Developing a learning organization culture requires everyone to be ready to be wrong.
- Establish how to measure if key decisions will move the needle or not.
- Define how long you are going to measure before you pivot from the results.
- Ensure that success is defined and owned by those closest to the action.
- Provide your team with autonomy by using a form of goal decomposition.