Problems that Matter

Good developers solve problems, great developers find problems.

My paraphrasing of a colleague.

Problem solving is a unique skill needed in our industry. Synthesizing complex inputs from business needs, log patterns, observability tools, and Jira tickets into code is challenging and fun. It's what drives many of us to excel at our jobs.

There is a unique skill, though, that is also necessary. Finding problems. Especially problems that matter.

In any code base, it is easy to find problems. There is old code that doesn't look great. There's a function call that isn't as fast as it could be, or syntax issues make code hard to read. Backlogs quickly stack up with "we should fix this" type tickets that are well-meaning and collecting dust.

Many of these problems are nuisances but don't carry enough weight to make it into active work.

In this post I'll explore how to find problems that matter.

Listen to Business Leaders

Every organization follows fundamental truths, which are intuitive to the founders and ingrained in the company's language. New employees can take years to understand these espoused beliefs, because they are rarely stated directly in any cultural artifact.

Understanding these beliefs and understanding how they manifest in the business's work will help you determine what matters to the company. To discover the espoused beliefs of your company, listen to non-technical and technical business leaders alike. Listen to how they discuss successes and failures, challenges, and the future.

I once worked for a company that had the value "Be a good person." Values can guide you in the right direction, but they don't tell you how the company acts. This company did want employees to be good people, but understanding what this meant required listening, seeing who was rewarded for their work, and determining how work was prioritized.

"Be a good person" at that company played out on the engineering team: "Be thoughtful, conscientious, and curious in code review." This was a delightful way to work because code review was collaborative.

It also meant that if you found an issue in code that might impact users negatively, it was prioritized without question.

However, when you encountered difficult-to-manage code from the scrappy early days, code that might seem like a good problem to solve, it was next to impossible to prioritize working on it.

I have bad news. Cleaning up messy code does not help the business. Even if you were following the "be a good person" value by cleaning up the code you see, you were not applying this value in a way that matters to the business.

"Be a good person" means "be a good person when shipping new features and taking care of our clients," not "be a good person and clean up old code code no one has looked at in a year (and might not look at for another year)."

My story here is not unique to this company. It happens over and over. Engineers who dream of working in a clean code base find an early-startup-style cruft and want to dive deep into cleaning it up. Stop yourself from doing this.

Old code is rarely a problem that matters.

Problems that matter are problems business leaders care about. Learn what your business leaders care about and look at your work through their eyes. Listen to their all-hands presentations, read their LinkedIn posts, and read their Slack messages, and start noting what they talk about and how they view the business.

Carefully studying how your company works will help you find problems that matter to the business.

Finding Problems

The art of finding a problem starts with understanding the system. As you work, build a mental model of the software and human systems. Identify choke-points and repeated stumbling blocks.

Complex problems are rarely a matter of "shipping" but shipping a human-system and software-system fix. The best problems are ones where the solution speeds up whole teams or departments.

Test what you've found with a circle of trusted people. Sharing ideas with a gradually broader group is a great way to get feedback and shape your solution. Start with people you trust who you know will give you actionable feedback. Treat ambiguous feedback as "this is a bad idea," and return to the drawing board.

When you look for feedback, focus on people who instinctively know the business's fundamental truths—people who will tell you if you have found a meaningful problem. These people will give you the most precise, actionable feedback.

Build your problem case into a solution and keep your solution close to what matters to the business.

Conclusion

There is no shortage of problems to identify. Discovering issues that matter to the business is the challenging part.

Understand the language of the business. Grasp the deeply held beliefs on which the company operates. Use these insights to help you identify problems that matter to the business.

Seek guidance from colleagues who understand the business and embody the company's espoused beliefs in their everyday work for feedback and to keep you on the right path.