Turning Problem-Explaining into Solutions

Are you a problem solver or a problem explainer? These are very different people.

Raising a problem does not guarantee progress. Your manager is unlikely to act on a problem alone: to give the go-ahead they will want to see solutions, costs, and delivery paths.

This article shows how to turn problem‑explaining into solution‑making.

Problem Explainer

Your development process is not working as you would like. You have noticed that work keeps stalling after it has successfully passed pre-production tests. However, work can wait weeks for sign-off before release.

You raise this with the CTO and she agrees. You leave the meeting feeling great: the issue has been highlighted with the right person.

But two months later, nothing has changed.

Why is this?

Identifying the problem is only half a solution

You have definitely identified an issue as the CTO agreed with you.

But why has nothing been done?

Because the CTO is extremely busy delivering initiatives that are high-priority for others in the business, such as the CEO.

The CTO simply does not have enough time day-to-day to dedicate to this issue. There is a fixed amount of time available, and that time is spent delivering projects that are seen as providing more value to the business.

What can you do?

Propose a number of solutions

In explaining the problem to the CTO, the assumption is that she will do something. Unfortunately, this has not been possible as their attention is elsewhere.

But the main issue with only presenting the problem is that the CTO has to find a solution, from scratch. This issue, although important, is not a concern to the CEO who is the CTO's manager. The CTO can safely move on to the delivery of high-profile issues that the CEO does care about.

In short, dropping this ball is safe for the CTO.

Before raising the issue

Once you have identified the issue, investigate some possible solutions, with outline costs and benefits, plus time to delivery, taking into account what your team and the company is already trying to achieve.

The issue: work stops after successful pre-production tests, waiting on sign-off for deployment.

Possible solutions:

1. Allow multiple people to sign-off the work into production
2. Replace sign-off with automation and for all work add feature-flags and roll-back

What is driving the situation?

The issue with the work having to be signed-off by the CTO is that one person is the bottleneck.

But the reason for sign-off is confidence. For work to be deployed, the CTO needs a number of questions answered:

1. Have all non-code changes been put into place and tested?
2. How will the effects of this deployment be rolled-back should we need to?
3. What other work being deployed could clash with this?
4. Are there any dependencies between this work and others?

Updating production entails risk. The CTO wants to reduce this as a mistake could lead to the company suffering a loss of revenue, or damage to its reputation, with customers looking elsewhere. Any of this will lead to the CTO having to answer to the CEO or board for the mistake.

Multiple people signing-off

This solution keeps the sign-off step but reduces the impact of a bottleneck.

Such a solution is required anyway as having only one person capable of sign-off means no work is deployed when that person is on holiday or off sick.

This solution keeps the human process of asking the four pre-deployment questions and requires a meeting to discuss what work meets the bar for deployment.

Costs, benefits, and time to deliver

The cost of this solution is the time it will take to train others to decide effectively whether work should be deployed.

Even after everyone has been trained, the CTO must accept that other people will approach this role differently to her, and that, eventually, work will be released that breaks production. When this happens, it is important to acknowledge that the failure is with the process and not the people.

The benefits are that multiple people can approve deployments, so a steady stream of work is released without over-burdening one person.

The time to deliver this is short-term. It should not take too long to train the other people how to make deployment decisions.

Your consideration of costs, benefits and timing do not need to be exhaustive. There needs to be enough information to enable a sufficiently realistic comparison between the various options. Your estimates should enable a choice to be made, not try to answer every conceivable question.

Deployment automation

The other identified solution is to replace sign-off with automation, feature-flags and roll-back.

One question for release is how to get production working again if a deployment fails.

Testing can only reduce risk, not eliminate it. Therefore, at some point, work will be released that breaks production.

A feature flag lets engineering control whether a deployed feature can be used in production. If the feature shows itself to be faulty, its feature flag can be set to false so that, even though the feature remains in production, the code can never be called. It is as if the feature had not been deployed.

Switching off a faulty feature stops it from inflicting more damage. Any damage already done may be to parts of the system that other code relies on.

For example, the new feature may update a value in a database with a negative quantity. Other code that has been stable for months reads this value and fails because the value should never be less than zero.

In this case, the feature should be removed from production, the issue fixed, and the updated feature released.

Costs, benefits, and time to deliver

The cost to put this solution into place is the design and implementation work necessary for an automated system with feature flags and roll-back.

The benefit is that no human needs to explicitly make a deployment decision. Work can be automatically deployed, safe in the knowledge that preventing further damage can be controlled, and any unwanted effects removed through either roll-back or manual inspection.

The time to deliver this is medium-term.

Meeting with the CTO

This time, you have identified the problem, understood what is driving it, and have two viable solutions to present. The CTO is going to ask about costs, benefits and time to delivery, and you have answers for these.

This turns the conversation from "I am informing you of a problem, can you please address it" to "Here is a problem, I know why it exists, and here are viable, costed solutions that will address the issue."

This turns the meeting from a dead-end problem discussion into a solution-focused approval.

It is much easier for a busy CTO to select from a number of solutions when they have already been thought through and communicated in terms the CTO will care about (costs, time to solution).

Picking the solution

This is a matter for the CTO based on the current context of the business.

One solution involves widening the set of people who can approve a release, the other automates deployment with the necessary technical support to decrease risk.

The first scales linearly with people. The second scales with automation.

Both solve the issue but they will not lead to the same outcome.

The first solution trains additional people who can make a deployment decision. This will ease the bottleneck but a meeting is still required to achieve agreement on what will be released. Others will be waiting on its outcome, and it will take the time of several people to prepare and attend.

The second solution automates deployment. No human need be involved. Work will be deployed as it becomes ready, without batching the work together as in the first solution.

If engineering head-count increases, the first solution will quickly cease to scale as the meeting becomes overwhelmed by the number of deployment candidates.

The automated pipeline will be able to absorb the effects of increased head-count.

For these reasons, the CTO chooses the second version.

Delivering the work

The CTO gives you the work to complete. It is a breath of fresh air to work on an initiative that is internal and which solves an issue that affects all of your engineering colleagues.

Three months later, the automated deployment is in place and it has enabled your company to deploy with ease, at pace, and with minimal risk. The features deployed start to earn revenue and you are promoted for identifying the issue, possible solutions and for being responsible for the delivery of the deployment engine.

The approach of identify-solutionize-discuss scales with seniority. It is your foundation of influence and career success. You will become known as someone who can not only spot a problem, but, crucially, as someone who also knows what to do about it, and how to get it done.

The general principle

In general, when presenting an issue to a leader, they will prioritise it based on value (to the business but also to them), and risk — to the business and to them.

Presenting just another problem creates yet another thing for the manager to be concerned about. It adds to their workload. It does not reduce it.

In presenting the complete picture of problem, driver, and costed solutions, you give your manager the space to be able to make a decision. You have reduced their workload to a level where a solution is the easiest path.

Therefore, a problem with a solution will likely lead to action. A problem alone will lead to business as usual.

How-to checklist

When a problem presents itself, subject it to this checklist:

1. Define the problem clearly
2. Identify root causes
3. Identify two or three viable solutions
4. Estimate cost, benefit and delivery time
5. Present options in business terms, not engineering terms

Read next: Bias, Metrics and Technical Debt
Technical debt is often ignored due to bias; using clear metrics turns it into a measurable business risk, improving predictability, reducing fragility and preventing future delivery slowdown.

Related Articles

• The Missing Structure Agile Cannot Fix
• Software Delivery Constraints and Pipeline Throughput
• When Urgency is High but Progress is Slow
• When Code Is Cheap, Judgement Matters More
• The Big AI Gains Come From Teams, Not Individuals