Emotional Responses from Decision Makers with no technical knowledge
-
From another conversation about upgrading an organization to support a future growth of up to 500+ employees, need HA (as it is described) etc.
From my own experience non-tech people bring up technical needs is a lot like a Medical Doctor trying to diagnose the sound your car is making. Then they insist that you need parts XYZ to fix the assumed problem of B.
Obviously this is all emotion, to address emotional responses to a technical question you've asked you need to change the question. For example lets say you ask the following.
How much down time can the business afford should our systems die today?Obviously this is an emotional question, it makes it very scary, and causes an emotional response. A better way to ask the question would be like this.
What kind of budget do we have to prevent downtime to our systems? Downtime is time it takes the IT department to rectify the problem so production can begin again.This is a financial question, asked to financial people, who will hopefully respond in a financial sense. If you don't pose a technical question, but a direct financial one, the only response can be one from a dollars and sense conversation.
If the response is less than what they pay you / your team as a department obviously downtime is not a priority. If the response is a matter of "Department X produces $/Hour, and we could survive without this department for # <timespan>" you have a very clear budget to begin with.
Force the financial people to do the math about what a department produces per hour. Not in raw material, but raw profit. From this you can work, and take as much emotion out of the conversation as possible.
-
Completely agree - how you present things, what words you use, your body language are all are extremely important when you're dealing with situations like this.
A well crafted Q&A or presentation can make the difference for an IT department with all of the brains and none of the people skills (and thus money).
-
Great insight here... thank you
-
@MattSpeller said:
Completely agree - how you present things, what words you use, your body language are all are extremely important when you're dealing with situations like this.
A well crafted Q&A or presentation can make the difference for an IT department with all of the brains and none of the people skills (and thus money).
Well presented? Like using a code tag to provide emphasis and losing half the text to a side scroll?
-
@DustinB3403 said:
What kind of budget do we have to prevent downtime to our systems? Downtime is time it takes the IT department to rectify the problem so production can begin again.I'm not really a fan of this proposed question either. It speaks to a budget.
Wouldn't something like
What is the cost to the business per min/hour/shift/day/week, etc? How much of that are we willing to spend to keep it from happening? -
While not directly related to this topic, we must remember to look at the wholistic situation, and not just the hardware for these outages.
Things like:
Flooding
lack of grid power
lightening strike
ISP outage
Update caused outageThe chances of my ISP having an outage is 10's of times if not 100's of greater than a hardware problem with my Tier 1 servers, so and spending I make needs to take that into mind first (assuming that's important to my business - which to me it is).
-
I don't believe in a specific budget for preventing downtime. Redundancy and disaster recovery is baked in to every single IT decision, so is a part of every IT budget. You can't separate it out. Preventing downtime is why we buy enterprise gear rather than consumer gear, for example. It's why we run RAID10 rather than RAID5. It's everywhere.
Secondly, "downtime" is too general a term. It's impossible to define. I've never experience a situation where an entire organisation is "down". It would happen in case of power loss or flooding or fire, but those are things generally covered by other department's budgets - they're not specific to IT.
What I experience is single systems being down, or being in a degraded state, such as e-mail, ERP, internet access. Availability for each component is treated on its own merits. For example, it's relatively easy to quantify the cost of an e-commerce website being down and mitigate against that. Put this wouldn't come under a general IT budget, it would be bundled in to the cost of running an e-commerce website.
So I would never ask either of the questions that the OP has listed. I don't think either are relevant or realistic in the real world. Yes, you can define the cost of providing certain HA solutions, but by definition HA doesn't prevent downtime, it only mitigates against it (hence the word "High" rather than, say, "Total"), so you'd still be asking "What kind of budget do we have to reduce our risk of downtime" and not "to prevent downtime".
-
@Carnival-Boy said:
I don't believe in a specific budget for preventing downtime.
I don't agree with budgets for much of anything. Everything has a cost for optimum effect for the specific business. Budgets make you typically overspend because you have money to burn, or under buy because you have an arbitrary cap.
-
@Carnival-Boy said:
I don't think either are relevant or realistic in the real world. Yes, you can define the cost of providing certain HA solutions, but by definition HA doesn't prevent downtime, it only mitigates against it (hence the word "High" rather than, say, "Total"), so you'd still be asking "What kind of budget do we have to reduce our risk of downtime" and not "to prevent downtime".
And it is specific to "layers". For example, most people in the SMB talk about HA only in terms of the platform layer and ignore the apps, OSes, storage, power, cooling, access, network, etc. It's a myopic view. They mitigate almost no risk yet feel that they have moved from "so risky I'd never do it" to "so safe I never have to think about it" and yet, almost nothing has changed.
The entire drive for HA is often an emotional response. We have been taught to fear a server failing, so we over compensate and try to fix that one, moderately small risk without addressing anything else.
