The Problem-Solving Gate

Part 1 of 2 in The Problem-Solving Gate · 4 min read

Most problems are not hard because the answer is hidden. They are hard because teams skip steps: they jump to a fix before agreeing on what is broken, treat symptoms as causes, or ship a solution nobody has tested or committed to maintain.

I first wrote these stages down in my early days running platform operations, where problem solving was not an occasional exercise but the daily work. Across many war-room calls, outages and system failures, the same mistakes kept repeating: fixing before agreeing on what was broken, treating the symptom, shipping a fix nobody owned. In firefighting mode, teams skip steps, and the skipped steps cost dearly.

A written list of stages keeps everyone focused on the big picture while dealing with the emergency. I have used them ever since, through high-performance infrastructure and site reliability engineering and now as an entrepreneur. Each stage has a clear purpose and a clear exit. Skip one and it tends to come back later, at a higher cost.

1. Acknowledge

Agree and accept that there is a problem.

This is the gate. Every stakeholder who owns, causes or is affected by the problem has to agree that it exists. Until that happens, any solution will be resisted, under-resourced or quietly ignored.

If this stage does not pass, stop. There is no solution to a problem that people do not accept they have.

It is also one of the most often skipped. Teams launch an expensive exercise only to discover later that nobody considered it worth solving. A solution with no takers is the most expensive kind.

Exit criteria:

• The problem is written down in one or two plain sentences
• The people who own and are affected by it agree it is real
• There is an accountable owner

2. Analyze

Understand it before you try to fix it.

Separate symptoms from the actual problem. Outages, complaints and missed targets are usually symptoms; the cause sits underneath them.

This is the other stage most often skipped. After an incident, the guidance is usually to avoid finger-pointing and move on. Avoiding blame is right; skipping the analysis is not. Without understanding why it happened, the problem is almost guaranteed to repeat.

Assess the risk, including the risk of doing nothing. Some problems do not need to be solved at all, or not now. Prioritize against everything else competing for the same people and money.

Sketch the possible paths to a solution. Occasionally the analysis shows that the problem is shared by many others, and the solution is a new product.

Exit criteria:

• Symptoms and root cause are listed separately
• Risk of acting and of not acting is understood
• Priority is set: does this need to be solved, and when?
• Possible paths are identified, including a product opportunity

3. Solution

Build a list of options, not a single answer.

Find out whether the problem has already been solved, internally or externally. Research it, use AI to widen the search and pressure-test ideas, and work it on a whiteboard. Document everything as you go.

Produce a list of candidate solutions. For each one, capture the risks, the costs and the effort required.

Every option must include how the solution will be maintained and how often it will be reviewed. A fix with no owner and no review cycle is a future problem.

Exit criteria:

• Prior internal and external solutions have been researched
• Two or more options are documented
• Each option shows risks, costs and effort
• Each option includes a maintenance plan and a periodic review

4. Decide

Review, brainstorm, decide, and get approval.

Bring the options to the people who will fund, build and live with the outcome. Review them openly, brainstorm improvements, and make a decision.

Secure the approvals required to proceed: budget, schedule, people and any compliance or security sign-offs. A decision without approval is only a proposal.

Exit criteria:

• Options were reviewed with the right stakeholders
• One solution is selected and the reasoning is recorded
• Required approvals are in hand

5. Verify

Prove it in a small set first.

Run the chosen solution in a limited scope: one team, one site, one customer segment or a subset of systems. Measure it against the problem defined in Stage 1.

If it does not work at small scale, it will not work at full scale. Go back to Stage 3 or 4 with what you learned rather than pushing forward.

Exit criteria:

• Pilot scope and success criteria were defined up front
• Results were measured against the original problem
• Go / no-go decision is made

6. Implement

Roll it out deliberately.

Implement the solution across the full scope using what the pilot taught you. Communicate the change, train the people affected, and keep a rollback plan ready.

Put the maintenance plan from Stage 3 into effect now: named owners, runbooks and the review schedule.

Exit criteria:

• Rollout plan and rollback plan exist
• Affected people are informed and trained
• Maintenance owners and review dates are assigned

7. Test & Sign Off

Confirm it is solved, then close it formally.

Test the implemented solution end to end and confirm that the original problem is gone, not just its symptoms. The stakeholders who agreed the problem existed in Stage 1 are the ones who sign off that it is solved.

Sign-off closes the project, not the responsibility. The periodic review keeps the solution honest over time.

Exit criteria:

• End-to-end testing is complete
• The Stage 1 stakeholders have signed off
• The first periodic review is on the calendar

---

The Problem-Solving Gate is simple on purpose. Its value comes from discipline: do not move to the next stage until the current one has passed. The stages most often skipped are Acknowledge and Analyze, and they are also the two that save the most time and money. Verify used to belong on that list too; today most teams know it gets skipped and make a conscious effort to protect it. The first two deserve the same discipline.

Gopa Sheppillayar is an entrepreneur: founder and CEO of Animbus, which builds secure multicloud for AI and HPC, and CEO of TaaS Systems, a managed technology services company. Before building companies, he spent his career in site reliability engineering and high-performance infrastructure, where a passion for solving hard problems became the habit behind this framework.

Companion post: The Problem-Solving Gate, at Home, the same seven stages applied to personal problems.