Why Discussing the Problem Matters More Than Choosing a Solution: Lessons from a Solution Architect

As a technology professional, I often find discussions devolving into endless debates over preferred technologies (JVM vs .NET, Java vs Kotlin, Go vs Rust, etc.) without addressing the underlying business problems.

Several years ago I worked as a "solution architect" (also called solution designer or solution engineer). The role’s sole goal is to find the "best" solution for a problem that is usually business‑oriented rather than purely technical.

The typical workflow consists of three steps:

Discuss the problem.

Evaluate alternative solutions.

Select the most appropriate one, sometimes requiring a business decision.

Many people skip the first step because it feels old‑fashioned, but the following anecdotes illustrate why it matters.

I Want a Drupal

While working at a public administration agency, a project manager demanded a Drupal system simply because a senior IT leader wanted it. The discussion never uncovered the real business need; the request was driven by political influence. I refused to approve the solution without a proper problem analysis.

Do We Need .env Files?

A Google engineer published an article urging developers to stop using .env files, advocating configuration servers instead. Another author responded, defending .env files for small teams. The debate highlighted that the choice of configuration management should be based on the specific pain points of the environment, not on hype.

Many Problems Do Not Require Microservices

Microservice hype is hard to ignore, yet few explain why they are needed. In most organizations, scaling teams leads to code‑base complexity, which is often managed with branching strategies (Git flow, GitHub flow) and dedicated release managers. When team size reaches around 70 developers, synchronization issues arise, suggesting that microservices may be a poor fit for many cases.

Technical Support Should Question the Problem Too

Support staff often jump straight to answering user questions with a solution, which can miss the root cause. For example, a StackOverflow post asked how to remove a repository from a pom.xml to build a Maven project. The answer focused on editing the XML, but the deeper issue was that the project referenced an inaccessible repository; a better solution would be to configure a mirror in Maven settings.

"I want to add a project pulled from Git and build it with Maven. Their pom.xml uses both private and public repositories; they told me to delete the private repository to build successfully." --- How to remove repo from pom.xml before building

The Five Whys

To avoid fixating on solutions without understanding problems, I recommend the "Five Whys" technique: iteratively ask "Why?" up to five times to uncover the root cause. Often fewer than five are sufficient, and the insight can even convince a business stakeholder to change their mind.

Remember, the best code is no code at all when the problem can be solved without software.

Conclusion

Engineers love debating their favorite solutions, but arguing about solutions without context is meaningless. Discussing the problem itself provides insight into its essence; spending more time understanding the problem increases the value you deliver.