Be a problem solver

You automate the menial, complex, and repetitive tasks of the real world to drive efficiency via experience, algorithm, and architecture. To do so successfully you must be (and be seen as) an expert problem solver.

How do you become an expert problem solver? This framework might help.

Get Context

Often you are given specific tasks or problems to solve with little context of why. Your first job is to understand the why. You may get pushback when you ask for additional context. Power through it.

With context you can:

  • Implement a more elegant solution
  • Better handle edge cases
  • Realize the feature isn’t needed
  • Plan for future growth and enhancements

If you don’t understand the context around a problem, you do both yourself and your company a disservice.

Define the problem specifically

Often you will be given work in one of the following forms:

  • Observation: Data translation is failing too often (30%)
  • Solution: The Data Warehouse team has a new translation service that could improve accuracy
  • Directive: Fix the translation process

In any of these cases, your first job (besides understanding context) is to define the problem specifically.

You define the problem by finding facts using the scientific method:

  • Hypothesis: There is a bug in the code causing translation to fail
  • Experiment: Debugging, Logging, Analysis
  • Observation: A failure occurs when data from System A does not match System B in case Y

Observations can result in multiple problem statements, in this case, the problem statement is:

Faulty assumption that System A and System B data would always match. Case Y proves the discrepancy.

Create a menu

Once you understand the context and the problem specifically you can start thinking through options, how could this problem be solved?

  • Option 1: Ask the Reference Data team to adjust System A data to match System B
  • Option 2: Adjust the algorithm to avoid cross-referencing data between Systems A and B
  • Option 3: Call the new translation service to reconcile A and B
  • Option 4: …

Evaluate multiple potential solutions before you pick one. Each option presents trade-offs that are important to picking the better solution.

Try to solve it

It’s tempting to scour the internet for someone who has “solved” this problem before and demonstrate how efficient you are by applying the solution. Don’t assume that because someone else wrote a library or sells a product they are smarter or more capable. A library may solve a particular problem but it won’t help you understand how to solve that problem.

Try to solve the problem at its most basic level by yourself. This will help you better understand, evaluate and appreciate (or see holes in) that third-party solution.

The solution you create to solve the problem yourself is likely to be thrown away, the value is in what you learn from the process.

Mind the gap

Assuming you are solving the problem yourself and have a basic framework for how to solve it take a moment to ask yourself the following questions:

  • What haven’t I thought of?
  • What could cause unexpected behavior?
  • What responsibility does my solution have to handle that behavior?

The point of this exercise is to not anticipate every possible edge case. Rather you should spend enough time to be able to speak to edge cases, which you have solved and which you have differed.

Iterate

You came up with an algorithm that solves the problem. Nice. You can do better. Your first solution is hardly ever your best. Want proof?

Go look at a product you launched a few years ago. You probably see now how you could have done something cleaner or communicated it better. When you are solving a problem don’t get hung up on your first idea, give yourself the luxury of an iteration or two, maybe more.

Once you have a solution in place, see if you can optimize it.

You should continue iterating until you have stopped learning something new.

Sanity Check

While you are iterating before you call it a day, take a moment to run several real-world scenarios through your new feature from one end of the solution to the other. Yes, your feature works in theory, your tests may be passing, but as a point of professional pride double check. If you find a problem you are still in the right frame of mind to fix it quickly.

Case Study

Remember the scenario from the introduction?

You have been asked for the 3rd time to explain how a system is designed, how it functions, and its purpose. You have already explained the system to interested parties both verbally, and with the assistance of a diagram.

Let’s use the framework above to examine the problem.

Context

You have designed Communitron a new omni-channel customer contact system. You understand its function and purpose. The CRM team is delaying work citing a need to better understand Communitron.

Define the problem specifically

  • Hypothesis: The CRM team can’t remember the details of Communitron
  • Experiment: Interview The CRM team
  • Observation: The CRM team responds by asking why Communitron even exists
  • Hypothesis: The CRM team disagrees with the design of Communitron
  • Experiment: Revisit the design and decision process of Communitron with the CRM team
  • Observation: The CRM team comes to the same conclusion with minor tweaks to labels
  • Hypothesis: The CRM team does not feel heard
  • Experiment: Make an effort to acknowledge the team’s suggestions and thoughts
  • Observation: No appreciable change in engagement or alignment
  • Hypothesis: The CRM team did not feel comfortable sharing their thoughts during the design process of Communitron
  • Experiment: Ask the CRM team pointed questions to get feedback
  • Observation: No appreciable change in engagement or alignment
  • Hypothesis: The CRM team wants to play a bigger role in designing Communitron going forward
  • Experiment: Ask the CRM team to design a new version of Communitron based on learnings and design review
  • Observation: The CRM team de-prioritizes the design work and no longer wants to work on Communitron

After several rounds of testing hypotheses:

The CRM team is inherently biased toward Communitron

Create a menu

  • Option 1: Give The CRM team developmental feedback on teamwork and communication
  • Option 2: Move biased members of the CRM team to another part of the company
  • Option 3: Scrap Communitron
  • Option 4: Disband the CRM team

Mind the gap

  • Developmental feedback might alienate The CRM team if not handled correctly
  • Moving the most troublesome members of the CRM team might not remove the bias
  • Scrapping Communitron could be viewed unfavorably by leadership
  • Support and new work in the CRM space would be more difficult while forming a new team

Summary

Problems based on emotion and personality are always harder to solve. People don’t behave predictably. As a problem solver, you have to weigh multiple factors, their impacts and their potential effects. Typically you’d start with the least disruptive option but more disruption often means bigger results.