Garage support
Summary
The “SciComp garage” is our daily office hour, where people can come and ask us anything. Answering these questions is a quite demanding responsibility, and you need to be able to think on your feet and not get stressed when you don’t know something.
Garage is not just a time to help others, but the common time we can talk with each other, and most importantly learn from each others’ answers. When you see someone give an answer you aren’t familiar with, always take the time to ask “what did you just do?” so that you can learn more.
Main challenges/pitfalls
You will often be asked things you don’t know right away. (A broad solution is: ask for more info in the way you would debug. For example, start by asking to share the screen and show the exact problem).
You need to be able to know other people (ASC/RSE/ITS/research services/etc.), to be able to refer customers to them when appropriate.
A lot like the “planner” role, you need to be able to understand lots of different things and advise on the best solution trade-off for each customer individually, without the time to take a break to plan.
Helping people while still giving them confidence that they can and should keep trying themselves (and not over-playing your confidence).
“Too many cooks” problem when too many staff try to support the same person, simultaneously asking questions and giving instructions.
Expectations / checklists
Attend the garage whenever it’s convenient (usually we have plenty of people, so if something else comes up, do that instead). However, attend often enough to stay connected to the team.
Treat all customers with the highest level of respect, regardless of their background or current experience level.
Make sure someone greets all incoming customers.
For each support case, make sure that one person (and not more than one) is the primary communicator, to prevent the customer from getting overloaded.
Ensure that you understand the full scope of the customer’s request before diving in, especially the questions listed on Help (has it ever worked? what are you trying to accomplish? what did you do? what do you need?) (Avoid the XY problem.)
Recognize difficult communication situations and act to make it better.
When someone departs garage, give them encouragement to keep trying themselves, that “yes this is hard, but you can do it”.
You may ask people to come back another day (or schedule another meeting) if you need more time to figure it out, or you need a different person to be present.
Help as best you can and ask for help from others when needed.
Observe other answers so you can learn new things, and ask follow-up questions once the customers leave.
Record visits in the garage diary, but don’t make a big deal out of gathering this information.
External materials
How to help someone use a computer by Phil Agre
How to ask for help with supercomputers by Radovan Bast
Training program: materials
Exercises
Garage-1: Roleplay a fairly normal support request
Goal: run through a fairly normal support request.
You: roleplay answering a fairly typical garage customer. Figure out who they are (department/position), what their topic is, decide that you can handle it, exact details of the problem, solving the problem, telling them next steps and you know they can do it.
Your partner: roleplay coming to garage and asking some normal-ish question.
Garage-2: Roleplay a support request where you don’t know the answer
Goal: practice telling a customer that you can’t help them right now and giving other options (for example, coming back the next day, waiting a bit for someone else to be free, sending email to arrange a specific meeting, directing them to some other team)
You: roleplay the above. The script should go like the previous exercise but you can’t answer it directly. (you can also pretend you can’t answer it even if you can)
Your partner: roleplay coming to garage and asking something.
Example cases:
Some highly advanced multi-node GPU work.
It’s about data storage in ENG and needs their admin support (not general usage that we could do)
Garage-3: Roleplay with an insistent customer
Goal: practice your confidence when dealing with customers who won’t let go of specific misconceptions they have.
You: roleplay responding to the request below. Try to talk them down and at least have them leave on good terms, since they never seem to give it up.
Your partner: You are a customer is in the garage insisting you know the best way to do something or what is wrong.
Example cases:
Arguing that they should be able to “sudo apt-get install” something and make it just work on Triton, continually arguing when you try to explain why it doesn’t work.
Or why can’t they simply run their Python code, saying that batch isn’t needed. They keep insisting “just help me do X” and acting like we are the problem.
Garage-4: Roleplay someone in over their head
Goal: practice a frustrating situation where it seems, no matter what you do, you won’t be able to help the customer. Find a way to leave them at least a little bit motivated and with an idea for what to do next. (Note: if this happens and it needs to be escalated to the supervisor, contact one of the team leaders.)
You: roleplay responding to the request below. Try to leave them feeling encouraged somehow and with something to do next. Try to understand their background to make the next recommendation.
Your partner: You are a customer in over their head.
Example cases:
The customer only know how to use AI to do things, but they need to know more now.
A customer (new summer research assistant for a ML group) comes to the garage and is clearly in over their head and asking you to do very basic things (ssh, opening a file, editing a file even through Jupyter/OOD), things that even a new summer intern should be able to do. Take, for example, making a Python program run via the command line (they have never seen a command line before and they can’t even begin). This has been happening for several days with the same customer now. You think there may be some deeper problem and their supervisor needs to get involved.
Garage-5: Roleplay answering some recurrent students
Goal: practice telling students (or someone) that they need to use someone else as their primary support channel. Discuss what we do vs what others should do.
You: roleplay responding to the situation below.
Your partner: You are one of a group of students who has been coming each day working on a project. You have just learned this is a project for a course. The students have permission to use Triton (since this is a project with research data with a research PI theoretically supervising), but they have begun asking us about the analysis of their data.
Example cases:
The project is analyzing some social media data and the questions have been about the concepts of network analysis and using a database for the data.
(Note: We can help students in these cases, especially about the mechanics of using Triton. But we can’t replace TAs who should be the first line of support, since courses can direct large numbers of students to us at once, and only the course staff can scale that large.)
Garage-6: Explain some topic in progressively more depth
Roleplay: you have a garage customer, and you are not sure how in-depth they understand some topic. Explain the topic progressively from the big overview, to more and more detailed. Each explanation should be ~30-60 seconds. Can you manage 3-5 explanations on the same topic? Make sure that the customer understands that you always need to start big, even if you are pretty sure you understand
You can choose the topic. The purpose is that when working with a customer, you may not know how knowledgeable they are, so you should start wide (acknowledging they may know this, but you need to be on the same page), and then go deeper.
Sample topics: data storage and transfer. Connecting to Triton. Slurm batch jobs.
Other
Psychology of support
How to help someone use a computer
Roleplay: garage help
Exercise: comment on a simulated bad support session
Roleplay: suggest to a colleague that their support could have been improved
Finding the real problem within the question
Usability
Teamwork
Work together but one person in charge of each support session