How to solve problems too early

Provide a solution before the problem is fully stated for extra credit

As we have discussed, engineers are meant to solve problems. The nature of the work is that you are asked to solve problems all the time, even if the ask isn’t explicit.

If you work in support, customers expect a resolution. If you work in research or product development, your customers expect you to build something to solve their problems. As an engineer, the fastest way to end a conversation and get back to playing Ghost Recon: Wildlands is to offer a solution, no matter how good.

Problem Definition

Documenting a problem is Very Hard, and people don’t write things down. You will often hear about a problem during a meeting and need to ask questions to help them narrow and better define it. They will often devise a half-backed solution, which they will tell you in the first 5 minutes of the conversation.

Here are some examples:

1. When we run the morning reports, they time out on Mondays and a few times on other days. Solution: We should increase the server capacity on Mondays to solve it.

2. Some customers have invalid configuration data, so about once a month, we load those customers in our web UX and hit “Save” on their profiles to fix it. Solution: When a customer hits an invalid configuration, we should auto-save their account to fix it.

3. When people onboard new accounts, they never know that the name of their tenant is case-sensitive. So many times, we end up creating two tenants, one called TenantX and one called tenant. Solution: To handle this operationally, we should create a tenent-merge script that Ops can run when this happens.

What is wrong with these solutions? Nothing.¹ These solutions are great.

Garbage-in, garbage out

It isn’t your job to help a customer define the problem; you are just the solution provider, right? If they ask for something, shouldn’t you give it to them?

In your role as an engineer, you don’t always see the process of figuring out the problem. This is more of an art than a science, so it’s hard to learn about it in traditional ways. There is no manual for analyzing requirements, interviewing customers, or building creative ways to get information on how external processes work. It is a crossroads between formal system analysis, psychology, interview technique, high-level communication, empathy, and systems theory. It’s messy. Best avoid it at all costs.

Problems without Solutions

If a half-baked solution isn’t present², you need to create one. As someone is speaking, ideally while mid-sentence, you should offer a half-baked solution. Think of yourself as on a trivia show in which there is no penalty for wrong answers but a great reward for answering quickly. Like the trivia system at Chili’s. You are paid to solve, so solve it and solve it quickly.

Besides, understanding the problem is probably a bunch of extra information that won’t matter about the types of people that use your system, how they communicate, what their other problems are, or what they expect. Certainly, knowing about the industry and what other systems do isn’t relevant to your system and where the industry might be going. Focus! All that extra context won’t help you. It’s information overload!

First, Do not Offend

Besides, they came to you with questions, so asking more questions is rude. They don’t seem to like it when you ask questions anyway; it feels like maybe you are stalling or don’t have any solutions. I mean, even if it might be simpler, wouldn’t it be a little embarrassing if you asked many questions and realized that a solution to their problem already exists, and it isn’t something you don’t get to build? And then what if you suggested that they use something like Google Sheets and some off-the-shelf API to do it? I mean, wouldn’t that mean you are a joke? A software engineer that isn’t engineering any software by writing it fresh³?

If you don’t fully understand the problem, you can offer a few solutions to make it better but not solve it, and then they will have to come back to you for more solve credits. See, it is like a video game in which you need to get as many hit points as possible, not as many kills as possible. Get some knocks, but few kills. You should cultivate a farm of easy-to-solve problems and develop a reliance on yourself as the only one who can provide solutions rather than truly solving the problems.

If you miss important information about the problem, the customer will probably ask again, and you can resolve it then. That way, you get credit for two solutions, and maybe you can get your Solutions Architect merit badge in time for summer.

1

1. Why just Mondays, and why “other days”? Ask some questions and look at some logs - feels like some weekly or monthly report is running taking up resources perhaps?

2. Why are they becoming invalid? By resaving, are we overwriting anything?

3. What about preventing the ability to save with another case when the tenant is created?

2. Because you have somehow trained your non-engineers to focus only on the problem. If you keep giving them bad solutions, you will eventually train them to build their own solutions— any middleman eventually moves into manufacturing.

3. Pardon, I mean to say “bespoke” or “custom” or “tailored”