Why Decision Latency Matters in Performance Management
There were studies done by the Standish Group where they looked at decision latency and its impact on success. Failure happens less often when we focus on decision latency and with agile it's about problem-solving by using decision latency.
Decision Latency is,
“the time it takes for us to make a decision.”
Looking at statistics for unsuccessful projects in 2018, the Standish Group looked at decision latency and what they found out was people, on average, took five hours or more to make a decision. However, for the projects that were successful, they found out that team members made decisions in an hour or less. Here’s the idea, when we make decisions at a faster rate, we can implement those decisions (faster) so my team can get more work done. Yet, when decisions are made at a slower rate, what we do is debate, analyze, and talk about how to make the decision but fail to assemble whatever needs built and in time, fail to produce the product itself.
How To Avoid Analysis Paralysis in Performance Management
Unfortunately, when we make decisions at a slower rate, on a regular basis, we permit analysis paralysis, a state with a desire for confidence in our decisions. Instead, we discuss our decisions rather than implement them and when we talk more than we implement, our implementation is ultimately delayed and we permit paralysis. Agile is designed to flee us from analysis paralysis, to help us make faster decisions. When we make those faster decisions, the goal is to have a bias towards action. In other words, I would rather do something than talk about it; even if the decision ends up failing and I need to correct it later on. In other words, I make decisions all the time and instead of talking about it, I learn by looking at what I did and the metrics associated with it to see whether or not I’ve gotten closer or farther away from my goal/future state.
“Whosoever desires constant success must change his conduct with the times.” -
Niccolo Machiavelli
Agile in Action of Everyday Life
Let me tell you about my wife’s work, she’s an anesthesiologist. She works at a local hospital. When a patient goes to the hospital and ends up in the emergency room, what do the doctors do first?
They gather information about the patient.
Their current state which includes:
a name, age, ethnicity, and medical history.
The doctors gather all this information to figure out what the patient's current state is (what brought the patient to the ER).
Next, the doctor acknowledges the patient’s current state, including medical history/background for their age and a forecast of what the future state or goal should be. Then, they run tests like checking the oxygen in blood or blood pressure according to age, medical history, and active level. Following this, doctor’s will have a recommendation for what the patient’s blood pressure should be (ex. 120/80mmHg) or what their oxygen level should be (ex. 95%). Afterwards, the doctor takes the patient’s blood pressure to see if it matches the number the doctor said it should be; or they measure the oxygen in the patient’s blood to see if it matches what the doctors forecasted. Hence, doctors run tests to see how much the patient matches the future state forecast.
The information doctors receive from running tests is the info they need to help them diagnose their patients and treat them accordingly. It begs the question, what do they treat first? For example, if someone goes to the ER after a motorcycle accident, they’ve had a heart attack and they have a paper cut. Doctors will treat the most critical of any patient’s injuries first. And so, despite the motorcycle accident and the physical injuries, treating a heart after a heart attack is the most critical because if left untreated, it could lead to death.
Doctors treat things in the order of highest priority, agile uses the same concept. GAP analysis, triage, and treating the issue that is most essential (imposing the biggest risk), it’s about repeating this process over again until we reach the future state. The most important part is running tests and completing an inspection process to see how close we are to the future state and how we will know when we’ve reached it.
“Don’t tell people how to do things, tell them what to do and let them surprise you with their results.” - George S. Patton Jr.
The Components of Strategy in Performance Management
Organizations should spend most of their time discussing the goals. Still, in many organizations people spend their time discussing the tasks employees do. There are steps to take, before we reach our goal, that deserve more predominance than the tasks. As soon as I make a goal, I think about how to reach it and I base my logic on assumptions (the things we act on as if they’re true). For example, if I had a goal to go to Los Angeles, I would automatically make assumptions on how I’d get there; which may include the mode of transportation, how long it will take, and how much it will cost. Based on those assumptions, (whether or not they’re true, I act upon them as if they are) I will form hypotheses (also known as conclusions) about the actions I want to take and how close they will lead me to the goal. Next, I think about the output that I need to produce and the tasks I need to complete to produce outputs and test my hypothesis.
We call goals, assumptions, hypotheses, and outputs the components of strategy at Bridgeport Digital and we use them daily. These components exist in every level of every organization. The tough part is when we make decisions and form our hypotheses based on assumptions that aren't true. If we want to make better decisions, what we need to do is make sure to throw away the assumptions that are not true. How do you know what assumptions are true or not? The reason we call this component an assumption is because we think about them tentatively.
Most people think they make decisions based on facts but facts can vary depending on the person and the circumstance; even so, they can’t be facts because facts don’t change. So, how do I know whether or not something is a fact?
A fact, by definition, is something I can independently verify, it should exist somewhere so I can test and/or confirm it.
I should be able to test and corroborate that it is true.
In scrum, what we do is create assumptions and we make an effort to construct those assumptions explicitly by writing them down and testing them out. The ones we figure out are incorrect, we revisit the decision it’s tied to. It’s better to verify the assumptions we use than to have an entire process where decisions are delayed and assumptions aren’t verified until the end. This is because if our assumption is wrong, our decision is wrong and we’ve left no wiggle room to pivot. Although, if we can verify our assumptions quickly, establish which assumptions are true or not, it makes it possible to reverse or change course (decisions) to produce a different outcome.
“In most cases being a good boss means hiring talented people and then getting out of their way.” - Tina Fey