Let the Problem Scream
Writing code is the most expensive part of any development process.
One way to further increase cost whilst slashing motivation is to write code that is overly complex and unfit for purpose.
Over-engineering occurs for many reasons, but there is one reliable solution: let the problem scream.
This means getting as high-definition a picture of the problem as possible and then tracing its effects.
A Tech Lead I worked with would lead retros around ongoing technical headaches. At the start, the team would list all of the aspects of the problem as comprehensively as possible. We would then detail all the knock-on effects. For example:
- Pod regularly exceeds its allotted memory & crashes → Increasing dependency on DevOps for support
- Pipeline fails intermittently → Downstream delays cause regulatory issues for Finance & we spend more time in incident management.
The key restriction was that any discussion of solutions or proposals was banned until a later session.
The engineers struggled with this. Like all engineers, they were natural problem-solvers.
You know the feeling—the solution is on your lips before you’ve even finished hearing the problem. Your mind moves fast, but it often sells you short.
To focus on all the rough edges and nuances of the problem takes patience and curiosity. It also takes some nerve to feel the pain without running for the plaster.
But the result is that you understand the problem on a much deeper level. From there, you have a much better foundation upon which to propose solutions.
This approach also has unexpected benefits in communication, as I found out with a client recently.
My client was having trouble bringing stakeholders along for the ride with his proposed solutions. He thought they were good solutions, and I agreed.
Instead of selling the solutions, I asked him to make the case to me without reference to a solution.
He articulated the problem with care and, just as importantly, explained the impact: how it slowed him down, how frustrating it was, and how it kept him from other critical work.
Focusing on the pain created empathy. Instead of placing a demand on someone, my client was sharing a personal struggle that was also impacting product development.
The difference was night and day.
So next time you’re tempted to race toward the fix, pause.
Let the problem speak in full. Let its ripple effects be felt.
When you let the problem scream, the right solution will look a lot more like an obvious next step, and others will be more sympathetic to your proposals.