I was working for a company where I needed to use a set of scripts developed by another team whithin the same department, and I started encountering some difficulties using it. I thought at first that I didn’t have the knowledge and started looking for documentation that I couldn’t find. I emailed the person who sent me those scripts asking if he could help and while he agreed to provide some guidance, he had no time to write documentation or to help me troubleshoot the issues that I encountered.
I knew the person to be professional and rigorous and it felt odd that he wouldn’t want to help in a deeper manner so I talked to my manager about it who talked to his manager and scheduled a meeting where we would have a troubleshooting session that quickly became a blaming session about how we weren’t good enough to understand the technology and ended with : “we provide some scripts to help you, we’re not providing a framework or support”.
Of course I felt annoyed by this statement and I didn’t really want to continue using those scripts but apparently we were supposed to, which clearly was in contradiction with the previous statement. So I thought about it and other occurrences of the same issues and I realised something isn’t working in IT departments.
It’s common in our industry to either be the service provider or to be provided services, whether it be development, support, design, architecture, … And while there’s no doubt about the quality of the technical service provided, the customer relationship might benefit from some serious improvement.
While this might be more obvious when providing service to other companies as a business, this should absolutely not be neglected inside the same company. The IT department is usually the service provider for all the other departments and how often do we hear complains about the level of service provided. Even within the IT department, when a team is supporting another or developing something to be used by other teams, what do we usually hear if not complains?
This comes down to the fact that many times, we assume that the colleagues who will use what we created has all the knowledge needed or will come to us if there’s any issue but that is not always the case. Technical people sometimes have a hard times recognising when to interact or ask questions, not to mention the sheer terror of being perceived as not knowledgeable or independant enough.
What we need to do when we provide anything (be it a service, or a framework) we need to provide documentation. Where to get it, how to install it, how to use it in your application, etc. Assume that the person who will use it knows nothing about it because it’s actually the case.
Be available for support as well, like you would support an external client that generates 95% of your revenues. You need to cater to the needs of this client, to be good and available, to have a level of service on par with the quality you provide.
And if there’s no time or budget to provide support, how about informing the distressed user of your tech about it?
“Sorry, I understand your frustration but this was developed as a sample to help you getting started. How it was explained to me, there wouldn’t be any budget for support and it was more a starting block than a framework. I’ll inform my manager about your issues and I encourage you to do the same so these scripts can become more than was anticipated in the beginning.”
Communication is ever important and explaining what are the issues you’re facing in a constructive manner goes a long way in getting your issues resolved.