Handling Hard Problems

Often in our respective industries, we are faced with hard problems. Where the team knows that wrangling a solution will be difficult. There are many ways to approach these hard problems. How would your team go about handling this problem? Is there one approach that is better than another?

It is common practice in the Software Engineering domain to plan spike or investigation activities. These are activities where a team member attempts to prototype a solution or further understand the areas of risk. Usually, the activity is time-boxed as the goal of the activity is not to solve the problem but to better understand. These are fine activities to take on to mitigate risk, but do they get any closer to a working solution? After the activity is completed feels like this was a step in the right direction, however, some of the context gained during these activities may be lost. It is rare to begin solving the initial problem right after the spike/investigation is completed. This path feels like a false sense of security for the team. Allowing the team to understand more, but at the cost of having to do some of the work again.

Another common practice is to go it alone. This is where one person takes the reins and rides off into the sunset. When they return to camp the problem is solved and everyone cheers. Or something like that, right? As someone who has done this, I know it works. Not every time, but most times. This comes at a cost to the individual and the team. First, the amount of strain one person has to endure. The stress to succeed and get it right, the sole accountability to complete the work. We all know this will not go perfectly and that it will probably take longer than anticipated. But if the rest of the team can keep moving on other work all will work out in the end. How about the team when this approach is being acted on? They know that this other member is working on the hard problem. It comes to a point where the other team members will avoid conversing with the one team member, as to not disrupt their work. This is not healthy. Another approach along these lines is to give the hardest problem to the strongest teammate. This is taking it too far, removing the strongest player on the team? Isolating them to a role in which they have to carry the most difficult work. Removing them from the position of helping the team grow. This approach seems like the opposite of what makes a great team.

There is not one baseball team that goes and sends out one person to view the footage of the division rivals before they come into town. They review the footage together to get a group's perspective on the opposition. No team takes everyone off the field except the star player when the best team in the league is the day's challenge. They all go out on the field and give it all they have. That is the same mentality we should have on our teams. Everyone has a different perspective on these hard problems. Not one person can see it from all angles. This one large problem can and should be broken down into many small problems. Every time one of the smaller problems is solved, the team decides if the progress is in the right direction. If they are off the tracks it's time to communicate that and work together to get back on track. But, you may be asking yourself "What if we are not able to determine if we are headed in the right direction?". You and the team have work to do. If a general understanding of the target is not known, the team has to work toward defining the target before moving forward. Target may be defined by someone else, that person(s) need to be in that conversation as well. Everyone involved should have a general idea of where the target is.

Teamwork is how the hard problems get solved. Everyone on the team grows from these experiences. As the team continues with this working arrangement communication, trust, problem-solving skills, personal accountability all increase. Blossoming into a high-performing team that knows how to crush large, seemingly impossible problems.