Limit Stupidity in Business Decision Making

Earlier today I posted this on my Facebook wall (follow me, I’m hilarious):

Allow me to offer you some background.

We were sitting around discussing changes and additions to a new software product. We’re primarily a server and web services software company and in the past haven’t spent too much time dealing with this type of a product so clearly it was a scene straight out of 2001 Space Odyssey.

Here were our issues in no particular order of importance:

1. We don’t know the best way to solve the problem.
2. We don’t know the typical user case scenario: Who will install this, what will they want to do with it?
3. We don’t know if to aim for simplicity or for flexibility (next few points explain this)
4. Option A: Do we rovide a simple interface with flexibility underneath?
5. Option B: Do we rovide a flexible interface that manages simple actions?
6. Either option requires redesign of the solution (from DB schema to software)
7. The way options are loaded into the system and then distributed to the client could either be expensive now or require reengineering later.

Business As Usual

This type of a problem is encountered in every business of nearly every type every day.

You have too many questions, too few resources and far too much uncertainty. There are two paths:

Path 1: Do something quick and dirty, get the solution out there and perfect it when you have sufficient reason to do so (lots of sales, lots of users)

Path 2: Only do something basic that you can do well and push off the complex stuff until you have a sufficient amount of reason (sales, $) to develop it.

Of course, the correct answer is: Pause. Breathe. Do more research and only act when you have sufficient information to make the correct call. While this answer is the only correct one, it’s not really a valid one because in business you either do shit and get paid or you get a job as the professor (or try to share your wisdom from a broken chair in your basement in between job applications).

I typically take Path 1 or Path 2 (and sometimes just say we’re not going to do anything at all). This makes my team furious. For a long period of time there was actually an interoffice joke that I made decisions based on which way my @#^$ leaned when I got up in the morning. Considering that’s the one they shared with me I’m sure their private opinions are far worse. So for their benefit (or for yours, in case you work for someone like me) here is a point of reference.

Terrible Business Decision Making Illustrated

If I don’t know about the demand but need to have a solution, we’re taking Path 1 (Quick and Dirty). If there is enough demand, we’ll perfect it.

If we know there is a lot of demand but do not know how quickly it will gain traction, we’re taking Path 2 (Basic, if they sell it we’ll write Complex 2.0)

If I know there is a ton of demand and that everyone will sell it, we’ll take Path 1 (Quick and Dirty) and we’ll put all the resources towards perfecting it as we release it. If someone needs a product and you don’t have it, they go elsewhere. It’s your job to earn it so even if it’s not perfect, effort compensates for quality.

If I know there is a ton of demand but no money in it, we’ll take Path 2 at first (Basic) and see if it brings in new clients we otherwise haven’t worked with. Sometimes solutions are simply a part of the whole picture and if we can get them to take a look at the picture maybe they’ll buy the frame, the hanging nail, the paint protection, the insurance and the commemorative personalized brick on our Hall of Fame Walkway outside our office. But I can’t sell them a brick until I get them to look at it.

The only truly random part of decision making is when Path 1 has a nearly equivalent cost to Path 2 and happens in the same amount of time. For example, let’s assume that the cost of getting something done quick and dirty is just slightly less than doing it right and can be done right in just a little bit of time. At that point I have to guess how busy you are (and you’re not busy at all; if you were busy you wouldn’t be talking to me you’d be pulling your hair out at your desk) and if I want to make you delay all the other stuff now or if I can wait to do it later.

The Fourth Path

People who don’t do your job have no respect for how difficult it is and will always expect it to take far less than it really should.

People who actually do the work are terrible at understanding the business strategy and how the product will be positioned.

The job of decision makers is to make a decision that maximizes the dollar amount and minimizes the time to get paid. The job of the person doing the work is to make sure any shortcuts taken in order to meet an unrealistic goal do not explode immediately. At this point the two play the software architect Russian roulette.

{ This part gets ugly and we’re trying to trademark it right now so I can’t blog it }

Needless to say, there is a better way that doesn’t involve crime scene cleanup showing up to mop up the shells from the conference room floor.

Shortcut to Possible: Compromise on completing things that are easy, attainable and will not result in a lot of change regardless which path is taken.

This gives you the time to think of a better way to solve the problem or to eliminate the problem entirely.

Sometimes we get preoccupied at solving the problem by staring at it from the top “It needs to do this!” as opposed to looking at all the components that lead to it being a problem in the first place. The amount of guess work and assumptions is also broad – yet what matters most is not the solution but the strategy of getting to that solution. Before you can solve a problem you must make people aware of it, concerned enough that they understand it’s impact, substantiate it with some actual data points, sell, schedule – and only then try to implement a solution. By taking problems apart and understanding who does what, when and how things do get simpler.

Today we decided to take care of what we know how to do, solve the chunks of the problem that won’t need to be reengineered and we decided to revisit the elephant on the table in a few days and weeks when we’ve had some time to think about the best way to lift it. Because no matter which path we took in lifting the elephant off the table today, we’d still have to figure out how to get him through the door, onto the elevator, down the street and so on and so forth. Don’t attack your problems from the top.