This post is part of my SIGUCCS 2024 conference reflection series. To learn more, check out my other posts tagged with SIGUCCS 2024.
One of the sessions I attended at SIGUCCS 2024 was Be a Tech Detective, presented by Lisa Brown and Victoria Waldron, which focused on a different way of approaching and resolving issues with technology. While the session seemed mostly geared towards those working in technical support roles, I found value in the session as a technology trainer, as I also need to put on my tech training detective hat at times when developing training content.
The session started out by talking about specific skills necessary for a tech detective, including technological proficiency, analytical thinking skills, communication/documentation skills, a willingness to always learn new things, and collaboration skills. Tools a tech detective might use included knowledge management systems, customer relationship management (CRM) systems, remote support tools, and other technical tools to help with troubleshooting. As a tech training detective, I feel that all the skills necessary for a tech detective are also beneficial when trying to create training, especially when I’m developing custom content for a special request. However, the tools I’d use are a little different – while I often use IU’s Knowledge Base when looking for information specific to IU’s technology systems, I also make use of help documentation from software developers like Adobe and Microsoft, and I’ll even refer to other training content that my co-workers and I created previously to help craft a training session. I’ll also use a variety of authoring tools to actually create my content, including Microsoft Word, Scrivener, and IU’s Web Content Management System (Cascade CMS).
When it comes to solving the cases a tech detective might encounter, Lisa and Victora shared four steps a tech detective can take to resolve a problem:
- Document the case: determine what the problem is
- Explore the facts: get more information on the problem and create a hypothesis as to what the solution might be
- Troubleshoot the case: determine and execute a plan for fixing the problem, and if the plan doesn’t work out, adjust as needed and try again
- Close the case: communicate and document the resolution to the problem, and follow up with whoever reported the issue if needed
For me, breaking things down into smaller steps is always helpful, and I like how Lisa and Victoria framed these steps from the perspective of an investigating detective. I thought of a way to reframe these steps for tech training detectives like myself when addressing the needs of a requestor for a training session:
- Document the case: Determine exactly what the requestor wants covered in the session. Talking with the requestor to make sure we’re both on the same page is especially helpful here.
- Explore the facts: Research the content to cover in the session. This might involve going through help documentation to find answers to specific questions, or looking through previously written training content to see what might be reused in the session I’m working on.
- Troubleshoot the case: Outline the training session content. Sometimes this is easier said than done, especially when trying to determine a good flow for the session’s content.
- Close the case: Deliver the session!
I like the idea of approaching problems in IT from the perspective of a detective, and treating them as mysteries to be solved. I’ll be approaching the process of creating content for requested sessions as a tech training detective from here on out!
Leave a Reply