Listening to Users
I recall Tom Limoncelli giving a presentation called “Time Management for System Administrators” and he explained how, as part of his routine, he would walk over by his customers–his users within the company he worked at–and check in at a regular time. Some days, they might ask questions that would reveal to him potential improvements in the systems architecture, and other times they might ask simple technical support questions. Either way, by dropping in at regular intervals, the users came to feel good about their Systems staff. This can be damned handy when, as they occasionally do, the systems go down hard, staff scramble to fight fires, and users are left out in the cold with little more to work with than their innate feelings about the Systems staff. If they like you, they will feel sympathetic in your hours of stress. If they don’t like you, they hope the present outage may be a nail in the coffin of your tenure.
I was put in mind of this by the story presented in today’s Daily WTF . . . the user, who could be described as “dim” had been following a really complicated, error-prone process. She had no idea that a trivial change to the system could be made to make her life easier. The hero of the story happened to be walking by, hear her frustration, politely inquire, and five minutes later, make betterness happen:
Still, there’s a good lesson here that’s often missed; pay attention to what users are doing with the provided system and by unblocking minor bottlenecks you can become the hero.
Amen. Amen. Amen.
Another point . . . a while back I was interviewing for a Lead SysAdmin job. The boss wanted to know how I might figure out initial priorities, were I to walk in and find myself the lone guy charged with a bajillion responsibilities. My answer is along the lines of “make your own list, get a list from everyone else, triage the items into buckets, and review the priorities with stakeholders.” I also offered, “and, ideally, if you can identify some ‘low-hanging fruit’ . . . one or a few ‘easy fixes’ that have high visibility, you win a lot of support early on, and people are happy to trust that you are working on more long-term stuff that won’t show immediate rewards.”
I have an interview tomorrow for a Release Engineer type position. Possibly a neat hybrid between being a harried Systems Administrator and being an amateur Programmer, helping various groups in the company get the software tools working in their favor. Such a gig might be an interesting change of pace, and it is the “customer service” aspect that appeals to me the most. We’ll see.
