Issue/solution process
Last updated
Was this helpful?
Last updated
Was this helpful?
Issue/Solution Proposal (ISP) is a tool for increasing clarity, speed, and output in teams.
Note: Special thanks to for the framework on which this system is based.
One of the core challenges in leadership is getting teams to buy into a decision intellectually and emotionally.
You create buy-in when you make people feel they're part of the decision, and that their input contributes to the final outcome. The more influence they feel they have on the outcome, the more they’ll be invested in the final result.
Broadly, there are three ways to make a decision. Each has a different time requirement, and creates a different level of buy-in. The methods that create the most buy-in also take the most amount of time.
For a decision where there's a clear decision maker based on Areas of Responsibility (see Type 1 vs Type 2 below), the decision maker announces a decision to the team, and answers questions. This is typical when a decision is within someone’s Area of Responsibility.
Example: A digital marketer who's responsible for managing the executing of advertising campaigns using different vendors would make a Method A decision on which vendors to choose, and let others know.
Pros:
Takes very little time.
Con:
Creates very little buy-in and gets no benefit from the team’s knowledge and experience.
A decision maker creates (or assigns someone to create) a written straw man (a hypothetical answer designed to inspire discussion), shares it with the team, invites team to give feedback (written and verbal), facilitates group discussion, makes everyone feel heard by repeating back their comments, and then makes a final decision.
Pros:
Creates more buy-in. Gets some minimal benefit from the collective wisdom of the team.
Con:
Takes more time.
A decision maker invites a team to a meeting where a dilemma is discussed from scratch with no straw man. The team shares ideas. The decision maker repeats back everyone’s ideas until they feel heard. The decision maker shares their own idea last (because theirs is the loudest voice in the room). Lastly, decision maker makes the decision.
Note that this is not a consensus decision. Buy-in is created by the decision maker confirming that they heard all ideas, not by accommodating all ideas.
Pros:
Creates the most buy-in. Gets a lot of benefit from the collective wisdom of the team.
Con:
Takes the most time.
Not surprisingly, the greatest benefits require the most work. If you want more buy-in and a better decision, you need to take more time in making the decision.
So, which method should you use? It depends on how significant the decision is, and how important buy-in is.
For everyday, low-impact issues (for example, entering a new reseller relationship), Method A is sufficient. For major, core issues (for example, Company 10-Year Vision), Method C is necessary. For everything in between (the vast majority of important decisions), Method B is optimal.
For Method B, we use the Issue/Proposed Solution method.
Team members will often want to bring up an issue and discuss it verbally. This is both inefficient (listening takes longer than reading) and ineffective (in verbal discussions the most vocal people often have the most influence).
Instead, we require that anyone who presents an issue at a team meeting do so in writing. The write-up should include both a detailed description of the Issue as well as their Proposed Solution. A team member asked to do a write-up might say “I don’t know the answer.” It doesn’t matter. They should take a guess and create a strawman. Even if they only have 10% confidence that their answer is the right one. And they should phrase the Proposed Solution in very bold, directive terms (“Do this ….”). This may seem aggressive, but it plants a flag in the sand which generates a much more productive discussion and a quicker decision-time, which is more important than appearing to be humble.
All Issues and Proposed Solutions are presented at the weekly Team Meeting, including a pre-recording that can be replayed asynchronously at high speed to save time.
Allow up to 5 minutes of discussion for each tactical (short-term) Proposed Solution and up to 20 minutes for each strategic (long-term) Proposed Solution. If in that time, the decision maker feels that they have enough context to make a decision, they announce and write the decision. The Solution is turned into one or more Next Actions with a DRI (Directly Responsible Individual) and Due Date for each.
We use an Issue/Solution Proposed (ISP) template to structure these issues, and typically include a recording of the issue so it can be explained quickly and concisely.
If the decision maker feels they don’t have enough context to make a decision, DO NOT spend more time talking about the Issue. Instead turn to the RAPID decision-making framework described below.
A Type 1 decision is a “one-way door”. Once it’s made, it’s very difficult to reverse. Acquiring a company, or discontinuing a product line are examples of Type 1 decisions.
As organizations get larger, there’s a tendency to use the heavy-weight Type 1 decision-making process on most decisions, including many Type 2 decisions. The end result of this is slowness, unthoughtful risk aversion, failure to experiment sufficiently, and consequently diminished invention. We need to fight that tendency.
Each time there is a decision to be made, rate it as Type 1 or Type 2.
Type 1 decisions should be made by the CEO.
Type 2 decisions should be made by someone who is not CEO, unless it impacts CEO-specific AORs.
Most decisions are Type 2.
When a decision is complex and can’t be reached efficiently even after a well-prepared ISP, we should use a RAPID framework. This is in specific cases when:
A team has become too large to easily get all of the needed voices in one room.
Consensus cannot be reached within 5-20 minutes of discussion.
Here is an Example of a RAPID. In an Issue/Proposed Solution using RAPID:
Someone identifies an issue or decision that needs to be made. They write up:
The Issue
The Proposed Solution
The list of people needed to make and implement the decision:
R (Recommend) = the one who first proposed the Issue and Solution.
A (Agree) = those people whose input must be incorporated in the decision. This is typically blank, unless is is the legal team to ensure no one is breaking the law. It should be very rare that anyone else's agreement is required for a decision.
P (Perform) = those people who will have to enact any decision and therefore should be heard.
I (Input) = those people whose input is worth considering.
D (Decide) = the one who will make the decision.
If Type 1, this should be the CEO.
If Type 2, this should be someone other than the CEO.
A section on the document for each person above to write their comments.
The R then reaches out to all the As, Ps, and Is to solicit their input. Once this input is received, the document is ready to be reviewed by the D. If the ISP involves an off-cycle budget change over $100K, R should work with finance team for their estimate of impact to financial plan.
The R schedules a Decision Meeting and invites the D, As, Is, and Ps.
If the issue is urgent, the R schedules this Decision Meeting as soon as it needs to be.
If the issue is non-urgent, the R can use the next Team Meeting as the Decision Meeting. This is much more efficient, and should be done whenever the issue is non-urgent.
At the Decision Meeting, the D reads through the document. If they have any questions, they asks them. If the questions can be fully answered in 5 minutes, they decide. If the questions can't be answered in 5 minutes, the D asks for another round of written responses on the document to answer the questions. At the next Team Meeting, the D reviews these responses, and decides.
Once the D decides, they write up the Decision (or asks the R to do so) along with all the Next Actions (each with a DRI and Due Date). The D then publishes this decision to the company via the appropriate ticketing system and/or other channels.