Every decision involves an element of risk; you might lose your job and not be able to pay back that mortgage that you’ve signed up for. The cascading effects of that are hard to imagine, so you may naturally veer away from the hard decisions but you can’t articulate why. Some decisions need to be emotionally led; but others aren’t or shouldn’t be.
You have to accept that any decision has a risk that needs to be balanced against the benefit. There is a risk we all rush, and that shouldn’t be done. Just because “something must be done” doesn’t mean that you should do the only thing that is available to you; you don’t want to shortcut your development process(es); and you don’t want the decision to backfire on you in a big way.
Understanding risk then is a big part of your decision making toolbox. We’re naturally biased when we try and understand risk; if a doctor says to you that you have an 2% chance of having a stroke, your reaction might be : “I’m fit, I don’t smoke, it’s probably lower than that”. In all likelihood that isn’t the case, the risk has already been adjusted from what they know about your lifestyle. An unfamiliarity with the problem domain or unit of measure can also lead to different perceived level of risk.
Take, for instance, the typical estimate that something will take 5 man-days. It’s a standard unit used in a lot of software development estimates. How long is it? What affects it? Your answers to these questions will be different to mine. It’s a standard frame of reference that means different things to different people. We might broadly agree, but we’re unlikely to exactly agree; and therein lies the problem.
You need to consider your frames of reference when you’re interacting with the rest of the business. Provide them with contextual information, highlighting where your assumptions will be markedly different to theirs. The ultimate decision is theirs, but the responsibility for making them understand the risks inherent in any decision is yours.
originally posted on medium