Problem Solver to Priority Setter
A billion-dollar organization brought me in to work with a leader who had been moved out of a business unit to become Chief Information Officer. He knew the business. The executive team had confidence in him.
He was not converting either one into decisions.
He gathered information thoroughly and understood each issue completely. Then he kept gathering. Decisions that could have been made on solid but imperfect information sat waiting for information that was never going to arrive.
From the outside it looked like diligence. Fear of failure and analysis paralysis were doing the work.
Why problems multiply faster than any executive can solve them
Engineering executives are usually excellent problem solvers. They see issues quickly. Often they can identify the solution before anyone else fully understands the problem.
That speed is a big part of why they got promoted.
As responsibility grows, the number of problems grows with it. A regional leader now sees problems across every office and every major project. Nobody can personally solve all of them, and the leaders who try become the reason the region moves slowly.
The more important job becomes deciding which problems deserve attention at all. That means knowing which issues are most consequential and which decisions require the executive. It means knowing which risks can be accepted, which problems someone else can solve and where the firm's limited time, talent and capital should go.
A future enterprise leader has to create focus for the people around them. That means separating what is urgent from what is important, and what is important from what is decisive.
Telling someone to be more strategic does not give them that discipline.
Prioritization and decisiveness are the same problem
Development plans often list these as two separate items. Work on prioritization. Work on decisiveness.
In the CIO's case we treated them as one, because in practice they are. Every priority is a decision to leave something else undone. A leader who cannot decide cannot prioritize.
When decisions stall, everything stays on the list. Nothing gets dropped, because dropping something is a decision too. The team sees a leader with a long list of priorities and concludes they have none.
Capable leaders get stuck here for an understandable reason. Every decision carries some risk of being wrong. For someone whose reputation rests on being right, waiting for one more piece of information feels like responsible engineering. Sometimes it is. At the executive level it is often a way of avoiding the call.
The CIO's work had two other threads. He needed to become more decisive, especially on issues that did not require broad consensus. He also needed to know when to stay the course and when to acknowledge that a path was not working.
Gather, process, decide, with a stopping point on each
We retooled his decision making into a loop he could run on any decision that mattered.
Gather enough data to reduce the risk. The stopping point is when the risk has come down enough to act. Solid but imperfect information is the standard.
Process the data by prioritizing it. Not everything gathered bears on the decision.
Make the decision.
Then monitor progress. This is where staying the course or changing direction gets decided, based on what is happening rather than on more analysis up front.
The stopping point on gathering is the one that matters most. Without it, gathering expands to fill whatever time is available.
We added one more tool. A simple grid separated decisions that required consensus from decisions he could make alone. When consensus was required, he had permission to slow down in order to speed up and take the time to get stakeholders on board.
He put more points on the scoreboard, which is exactly what his CEO wanted. In the CEO's words:
"He is doing a much better job of making tough decisions and following through until they are complete. He stays engaged on tough problems and works hard to get touchdowns instead of settling for a field goal. He has reduced the friction with his colleagues by listening and responding to their concerns."
Six questions for evaluating priorities
The loop handles a single decision. A leader carrying an enterprise workload also needs a way to decide which decisions deserve their time.
These six questions do that:
What outcome matters most?
What are the two or three variables driving it?
What will happen if we do nothing?
Which decision has the greatest leverage?
What can only I do?
What should another leader own?
The second question is the discipline engineers already use on technical problems. A few variables drive most outcomes. Find them and the rest of the list gets easier to rank.
The third question clears ground fast. If the honest answer is that not much will happen, the item can wait.
The fifth usually produces the shortest list on the page. For a regional president that means the top client relationships and the strategy for the region. Nearly everything else belongs to somebody else.
The sixth connects this transition to delegation. Every item that belongs to another leader is a decision the executive no longer has to make, as long as the ownership moves.
What a slow decision actually costs a project and a client
The cost of a slow decision rarely shows up as a line item. It shows up as time.
McKinsey surveyed 1,259 people across industries about how their organizations make decisions. Just over half said they spend more than 30 percent of their working time on decision making. On average, 61 percent said most of that time is used ineffectively. For managers at an average Fortune 500 company, McKinsey estimated that could mean more than 530,000 days of lost working time and roughly $250 million of wasted labor costs a year.
The same research found that organizations that make decisions quickly are twice as likely to make high-quality decisions as the slow ones. Speed and quality moved together.
That data is cross-industry. In a consulting engineering firm the cost is easier to see, because the work runs on schedules and clients.
A design decision that sits for a week leaves a team of engineers waiting on it. A client waiting on a scope decision notices too, and starts to wonder who is running the project.
When the CIO's CEO described the change, he talked about tough decisions made and followed through to completion.
Is one of your leaders over-gathering?
If a capable leader keeps asking for one more data point, more data will not fix it.
A short conversation can map how that leader gathers, processes and decides today. It can also show where the gathering should stop. From there we build the loop around the decisions on their desk right now.
Comments