Solving the Problem, Not the Solution

Raise your hand if you’ve ever been told how to do your job… Yep. It’s happened more than once - and I’m sure you already had a flash of red and maybe some warmth come to your face even hearing that phrase. In my current position, I run into scenarios where people seem to think they have the best solution for the problem. And, you know, they may be right, but it’s not their job. This is generally a problem that either technically minded stake holders or completely ill-informed users have. Let’s dig deeper, however.

First we’ll cover stakeholders, business owners, and project planners. Let’s identify what we’re doing when we pitch a project to the executors. Let me define the problem with this approach. Then, we’ll move on to technical executors and discuss how to combat and effectively resolve these types of propositions.

Stakeholder - You know your business

As a business owner or project lead, you know your business better than any single other person involved in the project. No one can deny that you’ve spent countless hours deep in the heart of it. You’re the one who is pitching this project because you’ve noticed a problem or defined a new feature that will make your baby even better. It can be frustrating hearing others who haven’t been eyeballs deep in this realm try to solve your problems for you. However, it’s time to let go…

The most valuable thing about you is your ‘domain’ knowledge. In other words, the intelligent human knowledge, process and reasoning that has been developed for your process is your greatest asset. This is what you should be proud of. This is the area that you’re going to be continuing to hone your skills. But, this is where you need to draw the line. Its physically impossible for a single person to know all of the business, and all of the technical requirements needed to execute it, all of the sales, marketing, etc. Allow yourself to start offloading this. Recognize that your job is to define the process and share the problem.

Let me restate that. Your job is to define and state the problem. Your job is NOT to solve the problem. That is why you’ve hired the people you have to solve your problem, the executors, if you will. These people will flourish at solving this problem. They will do it faster, and better, than you ever can. Why? Because that is where they are trained. And conversely, you can trust that your skill lies in managing your product and ideas - they are no competition for this. The deep knowledge you have completely and utterly trumps them in this realm. So, yes, share the problem, and wait for the solution.

That isn’t to say that you can’t suggest solutions that you’ve heard others have been successful with. Matter of fact, any good executor will be thankful for any ideas and proven scenarios you can provide where others may have solved this problem. Or if you have a great idea, share it! But, this is where the important distinct line comes: Suggest solutions, don’t demand them. You may find that while your solution you came up with is 90% better than any competitor, your executors might come up with one that is 95% better still! Let them do what you hired them for.

You will find that you now have more time to concentrate on your project, develop more enhancements and think of more problem’s solutions - Let them solve the problem - you just need to define it.

Executors, creators, programmers - Be Confident in your skill, communicate your understanding

While asking for programmers and designers to be confident seems like a no-brain-er, sometimes it needs to be reiterated. And then, I would tack on this: communicate this confidence in measurable means. Simply saying “I’m the best, this is why you hired me” is not good enough. You know you’re the best, and the hiring personnel know you are… now its time to remind them that they picked you for a reason. Since you are ’the best’, you are ready to solve any problem they can pose. Remember, the business needs to propose the problems. It is your job to creatively solve them.

Now, sometimes the stakeholders will come with just solutions. “I need feature A and B done. I want you to use Flash to build it.” This is where the programmer or designer has to take on an extra burden. Learn a bit about the business. Understand why the stake holder is asking for feature A and B. Then, understand (or ask) why they think “Flash” may be the best tool to solve it. Have they had good experiences with it in the past or have they heard of other teams successfully solving the problem with this tool. Be prepared when you disagree with a solution for two things: a) to immediately prove how you would solve the problem (in some instances, you may need to be able to manage this expectation, and suggest a followup meetup to suggest alternatives after you’ve researched) and b) to be willing to put the time in to understand what the root of the request is.

Any programmer can program. Anyone can solve problems in just the bare minimum way. However, understanding ‘why’ helps you use your experience to leverage better quality solutions, more efficiently. It can be difficult to separate requirements from suggestions, but this is the true sign of an amazing executor, a rockstar programmer. Your job is not just to make what the boss asks for, but to exceed those expectations and build something truly amazing. I bet 95% of you can agree: you almost always know of a more cool, exciting, and efficient way to make a feature than what is suggested. Take this time to learn the root of the request so you can bring those amazing ideas into fruition.

It’s no one’s fault - and it’s a long road

Often when I bring up these two points, I hear comments like “Oh well now you’re just making excuse for side XX.” That’s completely untrue. I think it would be completely irresponsible to recognize that the success of any project or organization rests fully on short term as well as long term goals. What I am addressing here is short term solutions. Adapt to the other party’s communication style and goal orientation. By doing so, you help move the project forward baby steps. But, moving forward comfortable baby steps - is still forward motion. Now, the long term of this is to recognize when certain behaviors are repeated over and over - and start to correct them.

There is good news. I’ve noticed that there are a number of times when these short term fixes prompt each party to adopt long term solutions. Whether its either suggesting a different way of communicating or self-identifying some traits after watching the other party constantly make concessions, there usually is a gradual, but measurable change that happens. Put in the time to continually allow for flexibility, and you’ll notice how the situation will end up morphing to something that fits better permanently.