Consulting is an interesting business. You don't always get to see the full lifecycle of the project you architected. You move around companies and tech stacks and constantly change the role you're playing on a given team.
But what's surprisingly consistent, are the problems you encounter. I've written before that most technical problems turn out to be people problems. But a large part of that is due to communication. So let's talk through some of the most common issues.
Poor problem definition
The first thing we see is that people are proposing solutions without defining and refining the problem they're trying to solve. This can be a challenging thing to do!
Defining a problem involves decoupling all of the related issues and focusing on the root cause. It means recognizing all of the different stakeholders and prioritizing the pain points the solution needs to address.
If important pieces of the puzzle are missed, the solution won't adequately address the issue.
Wishful thinking
Problem definition is tightly coupled with wishful thinking. This is when the team members find themselves trying to oversimplify a problem so the solution is comfortable for them. We can "just" do this. We only need to add this. It's really not that big a deal, we can get around it with this new tool. In some cases, it can go so far as saying "we don't have a problem at all".
Often, they're ignoring the messy, people parts of the problem.
Adding Complexity
The flip side to this is when team members want things to be complicated. There are various reasons for this. Either they have trouble separating the concerns in their head. Or they want to own a bigger problem and solution for some sense of job security.
Whatever the reason, this is just as common as wishful thinking. Like I said earlier, defining a problem is incredibly important, and there is a reason a lot of teams skip over this step.
Lack of broad knowledge
Once a problem is defined, the instinct is to solve it. But chiming in with a solution right away is rarely the right course of action. That's because your response is always going to be based on your existing knowledge. Sometimes that's sufficient, but often it's better to do some research.
Perhaps you're well versed in all the potential solutions, but are their newer ones? Have existing technologies made changes that no longer make them a fit? Are any of your options improving their community support or other positive changes that would put them into consideration?
Overly opinionated contributors
This is the point at which everyone comes back to the table and starts making recommendations. And in most every team there will be one person who did slanted research. They may have checked out the options, but they did so with the determination that their favorite tech was the clear answer.
You need people besides those voices. Your most valuable contributions will be those presenting options, listing pros and cons, potential risks, etc. You can get spin from marketing sites, or product representatives, you need a real-world solution and that's what you're looking for from your team members.
Ignoring situational considerations
Another thing that may come up when examining solutions is team members who consider technical purity only. Real-world solutions require a lot of different inputs.
You want to pick a path that accounts for existing team knowledge, time and cost limitations, available community support, etc. Discounting these considerations means the solution won't be viable.
What can we do?
Asking a question without the full scope is problematic. Getting the wrong answer and running with it causes more problems.
Define your problem, take the time to actually consider your options with real-world constraints. Then figure out the best way forward for your team. Not the team you wish you had!
I'm confident in saying that avoiding these pitfalls will have a dramatic effect on the success of the technology you build.
Top comments (4)
To me, it seems that if you suggest a solution that you later realize doesn’t work then you would seem more intelligent admitting its wrong rather than asserting it isn’t. It’s ok to be wrong sometimes but admitting when you are is what truly matters.
Absolutely. And the title is a bit tongue in cheek. You can't guarantee a correct answer, but some of these behaviors ensure a wrong one. And others help make the possibility more likely.
This is quiet cool defining th problem is really important. Im heading in to do more kind of stuff like this and i can see its important to get stakeholders to know what you are doing and if it should be done.. will a good explanation of what will be affected beyond just a technical definition (that i would understand). I will see how i will have to step back. I've tried to see how other developers or rather senior developers do it and talk to people invovled.
Excellent points!
Related...
Please Don't Answer This Question
Jason C. McDonald ・ Jul 16 '18 ・ 6 min read