I frequently work in support – I help a plethora of companies that have NetWorker issues, and I enjoy doing that work because it’s about fixing their issues and either getting them up and running again (if it was a serious issue), or helping them with something they’d not done before.
In short, I like helping people.
One thing I’ve occasionally heard over the years goes along the lines of:
“I don’t care whose problem it is, I want you to fix it.“
This is normally directed by an exasperated IT manager at a bunch of one or more vendors/support providers during a long running issue where different groups believe that the problem originates from different locations outside of their contracted support realm. Thankfully any time I’ve been involved in this it’s been as integrated support provider who (like the customer) has been trying to get the disparate vendors to stop finger pointing. So I’ve got no doubt that there are times when people say this that it’s fully justified.
I’d like to suggest though that sometimes it’s not fully justified; sometimes it’s not my problem – sometimes it’s not someone else’s problem. Sometimes it’s your problem.
This is a bitter pill to swallow. Let me sum up where it ceases to become someone else’s problem with a mangled quote:
The joy of a cheap price will have long faded when the realisation of a poor choice sets in.
I am sorry; I’ve searched high and wide for the original form of this quote, but I’ve not been able to find the original writer, or the original exact words, so I’m hoping I haven’t stretched it too far beyond its original meaning.
So where does the above quote come into play when someone has just pulled out the “I don’t care whose problem it is, I want you to fix it” card?
It comes into play in situations where:
- Critical components of your production environment aren’t under a support contract. (E.g., operating systems, databases.)
- Staff are not sent on or otherwise given access to critically important training.
- Staff are assigned tasks outside of their skillset without mentoring to help them reach that point.
- Against all advice, a bleeding edge solution was purchased.
- Without checking compatibility guides, disparate software/hardware/components were purchased.
I’d argue that in each of those situations, there is a good chance that some leeway should be given when various partners and vendors start finer pointing. Let’s go through each of those items:
Critical components aren’t under a support contract
It doesn’t matter if you’ve got storage support contracts, and hardware support contracts and individual application support contracts if core components, such as operating systems don’t have support contracts. Support isn’t a “shade of grey”; it’s binary. You either have it or you don’t. Choosing not to have part of it implicitly reduces the effectiveness of other parts of it. If an application or hardware support provider says to you “we think it would be wise to escalate this to <your OS vendor> as well for their feedback”, it’s not necessarily their fault if your response is “we don’t have support for <OS>”. Even more so, if they know that there’s a known issue with the unsupported component, it’s usually unrealistic to expect them to provide a workaround/solution beyond that.
Untrained staff
This is something I make a big point on in my book, and I want to be clear that I’m not talking about magical certifications but honest to goodness training. Needless training is wasteful, but consider this: if someone is escalating issues that any person with adequate training would already know the answer to, then not sending them on training is a false economy. I.e., they spend time not knowing what to do, then they spend time escalating the issue, then they spend time working with the vendor to fix the issue. It doesn’t take many of these incidents to actually eclipse the time it would take to send them on training.
Unskilled staff
There’s an old UI and system design principle:
The system should be as simple as possible, and no simpler.
This means that the system should be designed for the target audience or users. It doesn’t mean that a nuclear power plant’s control systems should be so simple that a janitor or lunch-room worker can fully operate it. (In actual fact, when you break this rule and start designing systems to be simpler than they should be, you start making the system more complex and harder for experienced user interaction, and more susceptible to “black box” failure.)
The net result of this is that staff who are assigned particular roles either should have the skills for those roles, or have someone available to mentor them to help them get their skill levels up to the required level.
My core case in point in this is that in situations where backup administration is done by system administrators, it’s very common to see the “newbie” or the most junior person get that task. I know, I’ve been there – it’s how I started in backup.
It’s also entirely, ahem, “ass-backwards”. A junior person is least likely to understand the potentially complex interrelationships between operating systems, applications, storage systems, performance tuning and networking requirements of the average backup system. This is a natural fit for the most senior staff rather than the most junior staff.
To put it bluntly: if you put the wrong person in the job without suitable mentoring provisions in place and they make a serious mistake, it’s not their fault, nor is it the fault of your support vendors, it’s your fault.
Bleeding Edge Solutions
In any competitive bidding process, it’s highly likely that at least one solution proposed will be bleeding edge. Sometimes it will be because the only potential way of achieving everything you want to do is by going bleeding edge. Equally as often it will be because it’s a common sales strategy: sell the thing with the most shiny bits.
Bleeding edge is thusly named for a good reason: if you slip up, it’ll cut you.
Now, if you’re demanding that everyone involved in the sale of a bleeding edge solution drop the finger pointing and start resolving the issue, that’s likely to be perfectly valid. But spare a thought for vendors on the periphery who weren’t involved in the sale but somehow have to continue to support the bleeding edge solution. And spare a thought for the people who explicitly told you that it was a risky solution.
Incompatible Systems
There’s nothing wrong with having policies to, or simply deciding to purchase different components for a solution from a variety of suppliers and vendors.
However, as I mention in my book, when you do this, it pushes the onus of responsibility onto you to do one of the following:
- Explicitly confirm compatibility of all disparate components.
- Explicitly tell all vendors the overall solution and components to be deployed, and explicitly state that what they sell must be known to be compatible.
The enterprise IT realm in particular is not plug and play. Just because X works with Y doesn’t mean that X works with Y2, and it doesn’t mean that just because X works with Y and Y works with Z that X will work with Z as well.
Why do I care? Why should you care?
Why do I care about this, and why should you care about this? Business is evolving. It’s no longer about traditional vendor/vendee or supplier/customer relationships. It’s about building business partnerships based on trust and a mutual desire for common success. As we know from our personal lives, partnerships that are entirely one sided don’t work.
The old business model confidently maintained that “the customer is always right”. This however loses relevancy in a true partnership. In a business partnership as well as a personal one, we know that true strength comes from each side acknowledging the needs and goals of the other side and working out how to mutually satisfy those goals without detriment to either.
