up one level
A Support Engineer Following Procedure Every time is not Productive so to Add Value I Will Pursue the Realistic Custom Solution to Each Individual Case
I’ve always followed procedure. I’d say that I’ve been the type who follows procedure %85-95% of the time. I’ve not been “disrupting” the market. I haven’t been the type who follows procedure half of the time and then who the other half of the time directs their energy to work towards my software support group’s (or company’s) departmental (or company-wide) goals in “new and creative ways”.
Here’s the point- it’s not gotten me far. What I need is to add a huge dose of realism. Software Customer Support Engineer is an operational role like a police officer or a hospital nurse or a firefighter. I need to balance reality with procedure. In other words, in order to add value in a Software Customer Support Agent role, I need to do what is the real obvious solution for the current individual unique case.
In software customer support, the neat, amazing thing is that most of the cases *are* unique. Just as for a hospital nurse or police officer, while there are similarities across cases, in the end every single case is a bit different.
A support case is an instance of a mathematical equation with a numerical answer. Not only does each equation have different values, but furthermore each equation is slightly different. Therefore the operations and calculation used won’t be the same for each support case, and the answer won’t be the same for each case either.
(Gee now I suddenly want to study a mathematics textbook)
I got off topic. My main point is that I need to do the obvious solution quickly first. Then follow up and iterate as necessary, adjusting the proposed solution as the equation changes.
If software customer support is a mathematical equation, then it’s the Software Technician’s job not only to solve the equation, but to define the equation. In other words a user comes with an initial symptom saying that something’s broken, and the Software Support Engineer joins in and proceeds to define the problem and then solve the problem.
In conclusion, as a Software Support Engineer (Software Technician), rather than drawing on procedures and processes as one or more static mathematical equations where only the number values are different each time, I’m going to instead treat each case as the unique equation that it is, and pursue the realistic solution to each case, while drawing on procedures and processes as guidelines or rules.
[2019 edit: Moved to: https://investorworker.com/2015/... .html.]