Don’t solve problems that you don’t have!

Don’t you hate that? When you are working on something, and people start raising problems that we don’t actually have. In traditional projects, this is disguised under the term “risk”.

Raise it, acknowledge it, maybe have one person spend 5 minutes thinking about it, then shelve it.

My mother is a sucker for this when she knows I am coming over for dinner. With my family, there is only a total of 6 of us. But my mother has a tendency to cook for twice as many people. So what is the problem she is trying to solve? Firstly, being of European background, she would be embarrassed if her own son walked out hungry. Secondly, she wants to be prepared if someone else knocks on the door unexpectedly.

But wait a minute! She’s my mum, so she has a pretty good gauge of how much we’ll eat, and in my entire life, I think people have unexpectedly knocked on the door less than half a dozen times. And it would have pretty easy just to whip something up to feed them.

The net effect, is she creates more problems than she actually solves EVERY time she cooks. What to do with the extra food? We are carrying the stuff home in droves, some gets thrown outetc etc.

I have waffled on, but I think you get my point. How many times do I sit in meetings and roll my eyes when you get people start debating about scaling issues, and we haven’t written one line of code or have one customer. WHO CARES!!!

Work on the problems you have, not the ones you don’t have. Why think about scaling issues, when you are only expecting to have less than a hundred customers for the next 6 months? Why think about a licensing server when you haven’t even launched a Beta?

In an engagement with a client some years back, the customer was so hung up on how the product would scale, that they sent a small team to go off and prototype a scalability solution. This piece of work took 3 people 2 weeks. Consequently their findings were implemented into the product and added at least 10% of complexity to writing the product. Here was a product that was yet to have any functionality developed. Ultimately, the product was launched, never succeeded, and never got beyond a handful of customers. The scaling was useless. Instead of using the resources and reducing the complexity to implement richer features that could have led to a more successful product, the time was wasted on code that was redundant.

I am not suggesting that if the team had not done this work and concentrated on the features that it would have been a success, but at least there would be a better chance of success.

Contrast this with another product that I worked on last year, where I debated whether scalability was a problem, and forced the team to just ignore it in the short term. When we finally DID have that problem (which was 12 months later), we basically used an off the shelf product, and 1 week of 2 developers times to implement, andWhoila! We were scaling!!!

So how do you do this? How do you avoid solving problems you don’t have?

Firstly, accept that people are going to raise non-existent problems. Then agree that if it doesn’t matter, the item will be acknowledged and logged. In a meeting, if someone raises a potential issue, first thing you do is ask the question “Is this a problem today?”, if it isn’t, don’t spend more than 5 minutes discussing it, and make sure a scribe logs it. That’s it! let it go!

If anyone objects to this, it is their responsibility to demonstrate why the problem is an issue today. If they fail to do that, move on!

I hope that helps with you non-problem solving. I have talked about the problem of scaling in this article, but there are many examples of this non-existent problem solving, and I would love to hear stories of problems that you may have solved that you never even had!