A Great Software Support Engineer Controls Their Empathy and Curiosity
A greaat software support engineer needs empathy, curiosity and the ability to turn their empathy and curiosity on or off.
What I mean is that these two essential qualities of empathy and curiosity are used every day, multiple times per day, and throughout the months and years of their job and career, however in order to be the best possible Software Customer Support Engineer, it’s necessary to be able to self-regulate the times when one applies their empathy and/or curiosity.
For example in the case of empathy, a customer support agent needs empathy to feel what the customer is feeling, take the customer’s side, help the customer, spend time caring about the customer’s needs and advocating on the customer’s behalf back to the company. That’s a good customer support engineer, but a great customer support engineer will also be able to turn this empathy off, for example (three examples actually) in order to do the following things: 1. not spend too long helping a customer, 2. be able to politely tell the customer that what they’re asking for is not a feature 3. not helping a customer excessively with questions that are not about the company’s software product and 4. not personally writing up duplicate instructions for a customer when the same instructions have already been written up before and can just be linked to along with a friendly note. In being able to turn on/off their empathy, the customer support engineer will still be able to empathize with and to help the customer, but
will also add value to their company by not wasting time nor dwelling on impossible ideas nor duplicating effort.
For example in the case of curiosity, a customer support representative needs curiosity to drive themselves to find the answer to a question, to find the cause of a problem, to find the solution to a problem or to learn a new technology. That is a good customer support engineer, but a great customer support engineer will also be able to turn this curiosity off, for example in order to do the following things: 1. during work on a time-sensitive problem, not spend time to speculate or guess about possible causes to a problem(in other words, to not be too curious to spend time just to prove that something’s *not* the cause of a problem!), 2. to not spend career development time learning about topics that are not directly applicable to one’s job 3. not need to know the details of every case that every other support engineer is working on (as opposed to just reviewing one or two of their peers’ cases per day) In being able to turn on/off their curiosity, the customer support engineer will still be able to use
their curiosity to drive their analytical troubleshooting and problem-solving efforts to close customer issues, but will also add value to their company by not inefficiently investigating irrelevant case details nor studying non-applicable technologies/concepts.
In conclusion, empathy and curiosity are great tools for a software customer support engineer, but in order to simultaneously serve the customer and add value to their company, the best software support engineers need to be able to control these abilities.
*2014-12-05 edit: previously published at http://w̶i̶e̶l̶d̶l̶i̶n̶u̶x̶.̶c̶o̶m̶/?p=58
Ramblings on Whether There Will Ever be a Standard Job Title for a Software Support Engineer
I usually describe myself as a Software Support Engineer or a Technical Support Engineer. But I see a huge number of other job titles for those who are essentially performing almost identical roles. Thus lately I can’t stop thinking of the lack of a standard job title for Support Engineer professionals. Here are a couple of characteristics I’ve noticed about the roles performed by Support Engineers and the titles that correspond to the roles:
-Sometimes the job title for a Support Engineer doesn’t have an occupation word at the end — I mean sometimes the noun is missing that should be there to describe the person’s profession or occupation.
-Sometimes the job title has the word “Customer” near the beginning, instead of “Product”.
-Sometimes the job title has the word “Product” near the beginning, instead of the word “Customer”.
-Sometimes the job title has the company’s actual product name at the beginning.
-Most job titles have the word “support” in them, usually near the middle. But the nouns before and after it vary hugely.
-Technical Support Engineer is a common job title to describe a Support Engineer, but, “Technical” and “Engineer” are redundant.
-Often the role of a Support Engineer is assumed to be one who works alongside other team members, all of whom have the same job title and who perform an identical job function. Like an infantry in an army. The idea being that the more support team members available in the team, the stronger the team will be or the larger amount of work the team will be able to do. Implied is that the role scales “out” (linearly) so that adding more person-power corresponds to, via a fixed proportion/ratio, the ability to support more customers.
It even occurred to me at one point that since there are so many different possibilities to be the ending noun in the job title (engineer, analyst, representative, etc. etc.) that why not put one’s own name there instead?
“Hi there! This is Morgan, and I’m your Technical Support Morgan. I have a few questions for you…”
But I haven’t actually seen that. And that would certainly be moving away from standardizing the job title and towards more individualized job titles.
Maybe some of these phenomena have to do with the fact that the role of Support Engineer spans not only across multiple Industries but across multiple roles. And that any given Support Engineer position usually requires extremely specialized knowledge of a niche product and often requires specific knowledge of a proprietary technology. And thus the Job title tends to vary widely.
Maybe these phenomena have to do with the fact that often a Support Engineer is tasked with a dozen different roles, and in any given Engineer’s case different roles are primary and different roles are secondary, and therefore we see such wide variation on the ‘occupation noun’ at the end of the job title (for example engineer, representative, specialist, etc. etc.)
Finally, here are a list of job titles for Support Engineer that I’ve seen in the industry, all of which were for someone performing very similar job roles:
Post-sales Application Engineer
Support (no noun ending)
Tech Support (no noun ending)
Customer Support (no noun ending)
(product-name-here) Support Engineer
IT Support Engineer
Customer Care Representative
Technical Account Manager
Level II Helpdesk
Customer Support Specialist
Customer Support Representative ( because you’re supporting the customer not the product?… )
Product Support Engineer ( because you’re supporting the product not the customer?…)
Service Desk Support Administrator (because you’re supporting the service desk? … )
*2014-12-05 edit: previously published at http://w̶i̶e̶l̶d̶l̶i̶n̶u̶x̶.̶c̶o̶m̶/?p=53
A Software Customer Support Engineer Team’s Five Essential Tools
Here are five tools that are essential to supporting a product to
customers in a software support team:
– Software documentation
– Software documentation bug tracker
– A ticket/case tracking system integrated with email
– A knowledge base or "kb" of articles. This could be
both in "troubleshooter"/"tree" form and in
directly searchable(searchable by a keyword search) form.
– Software bug tracker
*2014-12-05 edit: previously published at
Regarding Committing to do Software Customer Support Within the WordPress.org Forums Community
I’m pledging to do software customer support within the wordpress.org forums community. Each week, I’ll pledge my commitment for the next week by updating this blog post here. To begin, I’m striving to contribute on a daily basis to the support forum, and to attend the weekly #wordpress-sfd IRC meeting as well.
2013-12-08 – 14, contribute to wordpress.org support forum, attend #wordpress-sfd IRC meeting, and update this commitment.
2013-12-12 Weekly Update:
2013-12-15 – 21, contribute to wordpress.org support forum, attend #wordpress-sfd IRC meeting, and update this commitment.
2013-12-20 Weekly Update:
2013-12-22 – 28, attend #wordpress-sfd IRC meeting, and update this commitment.
2013-12-26 Weekly Update:
2013-12-29 – 2013-12-04, contribute to wordpress.org support forum, attend #wordpress-sfd IRC meeting, and update this commitment.
2014-01-02 Weekly Update:
No planned future commitment.
*2014-12-05 edit: previously published at http://w̶i̶e̶l̶d̶l̶i̶n̶u̶x̶.̶c̶o̶m̶/?p=41
Whereby I will describe a Software Customer Support Engineer tool that I call the “Resolution Tree”
This tool could be used alongside other tools, namely it will be used alongside the case ticket system and alongside the documentation manual.
The Software Customer Support Engineer Resolution Tree is a tool whereby every single question/problem, and its answer/action-to-resolution, are written down (and thus are quantified) in the form of a single tree structure.
The value of this tool is that for any current or future support engineers, and possibly for customers if it is published, there is a documented answer to every question that has been asked, and furthermore that in most cases once the tree has become comprehensive, this will actually be the same thing as there being a documented, indexed answer to every question that *will* be asked!
More specs/details of the Resolution Tree:
It starts with categories of questions/problems on the top level, representing every top level category or type of question that can be asked or that can happen. Then under each top level category of question/problem, sub-questions and sub-problems are documented. at the end of each branch of sub-questions and sub-problems is written the answer or the action-to-resolution. Another way of saying that the *leaf* at the end of each branch contains the answer/action-to-solution to the question/problem. When the tree is new, it will be editable by the Software Support Engineers. and indeed will need to be written-to upon almost every case to begin with. But then as the tree grows, and more cases are documented, it will naturally be that a growing number of cases will already have the solution as an existing leaf in the tree.
As for consideration of how this compares to a knowledgebase. Thinking on it, this resolution tree pretty much is a knowledgebase. It is a knowledgebase that can be searched by traversing its branched structure. So if the feature can be added: text searching on key words through the resolution tree, then it will be a combination resolution tree and searchable knowledge base.
So that is the “Resolution Tree”. And recap that the value in it, is that it enables every single question and its resolution to be written-down/recorded. And best-case scenario, reused.
Update!: Gmail made a resolution tree -> https://support.google.com/mail/troubleshooter/2935079 <--google made this tool to troubleshoot gmail, in this case this page troubleshoots why an email message isn't arriving in the gmail inbox! They made the resolution tree.... *2014-12-05 edit: previously published at http://w̶i̶e̶l̶d̶l̶i̶n̶u̶x̶.̶c̶o̶m̶/?p=37
It’s Important for a Tech Support Person to Write Down the Answer for the Customer
There is a pattern in the field of Tech Support. The pattern is also seen in some other professions where a clients come to the support provider for support. I’m mentioning this because it is because I saw this pattern outside of Software Tech Support, that I realized that it existed. The pattern is of a Tech Support taking pains to analyze a customer’s concern, define the problem it represents, and produce a solution, and even communicate the solution to the customer, but then fail to spend the last, needed efforts to: Check if the customer recieved the solution, and furthermore repeat, reiterate and write down the answer for the customer.
I have gone along on visits in the past few years where I was able to see about a dozen different health care professionals diagnose and give advice to a patient. One time in particular, I listened to the health care professional as they spoke the diagnosis and the prescription. I didn’t immediately understand the diagnosis or the prescription. It may have been because they spoke quickly, or because they used medical terminology that I wasn’t familiar with, or maybe I thought they would repeat it or write it down, so I wouldn’t have to remember each word they had just said. But as they started to leave the room, I despaired and thought “…wait! I still don’t understand what the problem is, and I don’t know what to do about it! Don’t leave yet, Can you help me some more!?…”
This feeling of despair triggered a memory of something I had experienced not long before, but where I had been on the other end. There was a time when I had, on the phone, listened to the customer describe a common symptom, quickly analyzed it in my head, told a customer what the problem was, and had then told them on the phone a few specific instructions of what exactly to do to fix the problem. And as I was preparing to end the call, the customer said, with exasperation and despair, pretty much exactly what I wanted to say to that health care professional. “…wait! I don’t understand…!”
In the case of my own visit with the health care provider, I ended up asking them to please repeat themself (twice actually), and asked them a few follow-up questions, the answers to all of which I successfully commited to memory before they left the room. Then I wrote them down on a scrap of paper as soon as I could afterwards. In the case of my call with my software customer, I ended up hearing the customer’s despair and promised to write them, and then did immediately write them, an email with a recap of the concern, the recap of the definition of the problem, and the recap of the exact steps to remedy the problem. So I’m saying that in these two stories, the customer expressed concern that they weren’t clear on the details, in the end the details/solution did eventually become written down, and both stories ended well (the case was solved).
Back to the pattern in Tech Support, that was illustrated by the above stories. In the profession of Tech Support, of course the Tech Support person needs to take the effort to analyze the concern, define the problem that the concern represents and create a solution to the problem. Those can be covered at length another time. As a Tech Support person, there is a way to avoid despair or exasperation from the customer — some final efforts may need to be followed through. Today’s story’s main point is this: It’s often necessary for the Tech Support person to spend some final effort to confirm whether the tech support customer recieved the solution or not, and if not, it’s necessary for the Tech Support person to repeat, reiterate and write down the answer for the customer.
*2014-12-05 edit: previously published at http://w̶i̶e̶l̶d̶l̶i̶n̶u̶x̶.̶c̶o̶m̶/?p=38
*2015-08-08 edit: edited whitespace to improve this post’s readability
Notes on either Needing Automatic Software Updates or Needing the Software to not be Updated
Reflecting on two recent software technology meetings, I found they had some similarities and differences. Both had to do with the importance of software updates. And these two unrelated meetings they touched on a spectrum of needs, all the way from the need to have software update automatically to the need for the software to never become automatically updated.
One meeting was: I Got 99 Problems But CPAN Ain’t One.
Software developers, in this case Perl developers, build new software using existing software packages. These existing software packages may themselves be currently under development or may become patched or updated. The main point the speaker made at this meeting was that it’s important for a software developer to control when software updates happen to the packages upon which their software depends. And the speaker talked on points such as the Pinto system’s ability to set a flag to prevent updates or the ability to allow updates by typing in a specific version number when issuing the update command.
One meeting was: WordPress Support and Documentation Engineers team meetup from 2013-10-10.
Software admins and developers, in this case WordPress software developers and admins, benefit from automatic updates to keep the software up-to-date and secure. So wordpress now has an automatic updates feature. In this meeting it was further discussed that there are situations where admins and devs don’t want the software to be updated automatically, or only want parts of it to be updated automatically. So it was discussed how WordPress’ automatic updates have logic that prevents the updates in many cases. It was also discussed how there are numerous flags that either an admin or a dev can set to prevent the automatic updates from even happening.
One meeting proposed the idea that updates should never be allowed to happen automatically. One meeting discussed how to work with the reality that automatic software updates happen. Both of these meetings realized that it’s important to be able to tell the software to not update automatically. And of course both meetings treated software updates as a topic worth discussing.
Thank you to all the people who made the meetings, and the recording and posting of the meetings, happen.
*2014-12-05 edit: previously published at http://w̶i̶e̶l̶d̶l̶i̶n̶u̶x̶.̶c̶o̶m̶/?p=35
The Importance of Regrouping after 30 Minutes When Working on an Involved Tech Support Case
The other day when working on a tech support case, I realized that I had just started to think in circles about the question at hand. I was reading a forum post of a concern that a customer had. And in reading, researching, looking through documentation and doing testing, I had started to overthink things.
But then I realized after about 30 minutes what was happening — i was in danger of starting to speculate in regards to the problem definition, cause and solution. I stopped working on the problem right away.
Then what? The problem hadn’t been defined, its cause hadn’t been found and the solution was not yet in sight. In this case, no colleague was available to consult. That is usually my first choice at this point in a case. Luckily in this particular case it was an acceptable point to break for a longer period of time. I put the case aside and went on to my next urgent task.
So what happened to this case? A few hours later, when in a more relaxed state, I realized what defined that problem and what caused the customers’s concern in the case. And I knew what the immediate next step was. In this case the next step required was to make an initial suggestion directly back to the customer.
The conclusion is that after 30 minutes of working on an involved Tech Support case without progressing, it’s time to regroup and either get input from a colleague, set the case aside for a while, or contact the customer back for more information, or otherwise pause the case temporarily. This will prevent one from overthinking the case, will prevent one from beginning to wastefully speculate about the case.
*2014-12-05 edit: previously published at http://w̶i̶e̶l̶d̶l̶i̶n̶u̶x̶.̶c̶o̶m̶/?p=21
What I learned from Sitting in on (observing) a WordPress.org Software Development Engineers Meeting
I sat in on (observed really) an online virtual (IRC) meeting of WordPress.org Software Developers ( http://irclogs.wordpress.org/chanlog.php?channel=wordpress-dev&day=2013-10-02&sort=asc ), and learned about three valuable tools and one valuable process surrounding software development. The three valuable tools are subversion version control system, trac-bot & svn-bot IRC system integration and the trac bug tracker system. The valuable process is the process of changing the state of a ticket in the bug tracker system.
Let me go into more detail:
In the meeting some of the wordpress devs were talking about using svn, including what command does what. They were also using svn. So while chatting on the IRC, wordpress team members were commiting changes and updates from their end via their svn, which was obvious from the “svn-bot” messages also appearing in the IRC channel. It really turned into a working meeting. Thus I learned that svn is a valuable tool for software development.
This leads into the next thing I noticed — automated messages were being posted to the IRC channel by a user called svn-bot and a user called trac-bot. It became apparent to me that a program was integrating the svn and bug tracking systems with the IRC channel. The bots were posting notification messages in the IRC channel corresponding to notable events in those two integrated systems. And the wordpress developers were thus able to see immediately what significant actions other team members were doing in either of those two systems, just by monitoring the IRC channel. This in turn triggered more dialog between the team members in the meeting. Thus I learned that trac-bot & svn-bot IRC system integration is a valuable tool for software development.
Another tool I observed in action during the wordpress software developer meeting was the trac bug tracking system. Team members discussed the importance of manipulating tickets and closing their statuses. Team members posted links to specific tickets or ticket lists on the http://core.trac.wordpress.org/ site. The automated trac-bot also posted messages when something significant happened in the trac system. Thus I learned that a bug tracker ticket system is a valuable tool for software development.
This leads to a process that I observed. The team stressed the importance of the act of updating the status of tickets in the trac bug tracker system. Without explicitly mentioning writing code at all, the team discussed the importance of updating tickets to the appropriate status. For example some appropriate states for the ticket in order to progress it properly would be to mark it as closed, ready to be closed, or reverted back to a previous state. I saw that this discussion was important independent of the act of actually writing code (which is what I usually think of when i think of software development) So the act of writing code may have been implied by the whole of the process itself, but writing code was not actually discussed in this part of the meeting, which was brilliant. Thus I learned that the process of changing the state of a ticket in the bug tracker system is a valuable process for software development.
From observing this meeting of the wordpress software developers, I learned much about software development. I learned about the value of tools including subversion, trac-bot & svn-bot IRC integraions and the trac bug tracker system, as well as the value added by the process of using a bug tracker.
Lastly, thanks to the worpress dev team for having this open infrastructure that allows me to observe and learn from them in the software development working meeting.
*2014-12-05 edit: previously published at http://w̶i̶e̶l̶d̶l̶i̶n̶u̶x̶.̶c̶o̶m̶/?p=17
Conference Keynote Speaker Accurately Describes the role of a Vendor’s Software Support in the Overall Software Customer Experience
In the recent Oracle OpenWorld keynote, “Modern Customer Experience: Welcome to the Age of the Customer” ( http://medianetwork.oracle.com/video/player/2695413057001 ), the speaker had a slide of the customer life cycle for a software customer. Coming from a software support background I found it brilliantly accurate — the half of the diagram that represented owning the software product (the other half of the diagram represented buying the software product)
The speaker indicated that the software support starts, or should start, with the customer receiving the software and end with the customer recommending the software (for further use)(or to others for further use). And indicated that at the heart of owning the software or IT product was the act of using and maintaining it.
Indeed, in my experience as a Software Support Engineer, the first time a customer contacts me is when they have just purchased the software product. And then subsequent calls by the same customer are usually when they need to know how to use or how to maintain the solution. Lastly, I consider it a victory that aligns with my job role when a customer tells me that in part because of my support, that they like my company’s software product and are recommending it to another person.
In conclusion, that recent OpenWorld Conference keynote speaker was accurate in the part of his description that told how a vendor’s software support fits into the overall software customer experience.
*2014-12-05 edit: previously published at http://w̶i̶e̶l̶d̶l̶i̶n̶u̶x̶.̶c̶o̶m̶/?p=15
Testing Whether the Web Application Login Form is Secure Despite
not seeing "https://" in the Web Browser’s Address Bar
A few weeks ago, after a dialog with a colleague (
https://twitter.com/KO6YQ ), I was curious whether meetup.com (and
the question is the same for other similar sites which do login
(encrypted) login or not. I actually suspected the login was unsecure
(unencrypted) because at no point during the login did I see
"https://" appear in my web browser’s address bar. So I did
a "developer tools inspection" as well as a wireshark
Here’s a bullet-point list with the steps that I took with a
little more detail, along with what I found:
+ I used Firefox’s "Tools->Web Developer->Inspector"
and found that the form that comes up is an html POST form with the
+ To see what was happening behind the scenes, I captured a
Wireshark trace on my local workstation’s network interface during my
login. It confirmed that the web page was making calls to the
meetup.com’s server (220.127.116.11) via "https" protocol.
+ In a subsequent search of the Wireshark trace’s contents, my
cleartext password wasn’t present.
So a summary of what I found is that the developer tools inspector
revealed that the form that appeared when you click on the Login link
at the top of the main (non-https) page is an html post form, the
action of which is "https://secure.meetup.com/login".
Furthermore, in my wireshark capture my password was not present in
My conclusion is that yes, it is secure auth using "https://",
and that as supported by the two main pieces of evidence above, my
credentials are being passed encrypted starting at my web browser.
My initial suspicsion was wrong. I’m now confident that it is
secure — from now on I’m going to just login like normal and rest
assured that my credentials are being encrypted by the time they
leave my web browser.
*2014-12-05 edit: previously published at
w̶i̶e̶l̶d̶l̶i̶n̶u̶x̶.̶c̶o̶m̶ Inaugural Post
w̶i̶e̶l̶d̶l̶i̶n̶u̶x̶.̶c̶o̶m̶ Inaugural Post
w̶i̶e̶l̶d̶l̶i̶n̶u̶x̶.̶c̶o̶m̶ is born as a blog focusing on
IT-software-support-and-development-engineering topics. The
inspiration for this blog comes from my current twitter (
"Talk to a colleague, wield Linux to solve a job, write it
down and then tweet it."
*2014-12-05 edit: previously published at