I believe that, given any type of technical problem, there exists a finite and achievable set of actions you can perform to find the root cause of a problem. From there, you can eliminate or improve that problem.
This is true in any field. Yes, the list of steps might be too long for a single page. Or maybe there’s multiple sets of problems, each with “sub-problems” or ancillary problems. But across all domains of IT, software, engineering, or non-tech fields, I believe that this is true.
I maintain that it’s the philosophy of approach that matters the most. This isn’t the “I have a hammer, let’s find some nails” approach, but the “I have the world’s greatest toolbox, let’s see what’s going on” approach. You already know what that toolbox is, right?
(It’s your brain.)
By solidifying your general problem-solving skills, you’ll enable yourself to solve anything, and move beyond where you are now. Not just professionally, but in any aspect of your life. But hey, maybe you just want to get better at figuring out what happened to that SMTP server and why it’s suddenly gone silent.
Why You Should Trust Me
I don’t have extensive professional experience in this field.
In fact, I spent just under two years working as a “Technical Support Analyst.” Really it was on-call software support. Before that, the longest I’d held a job was three or so months — as IT helpdesk — and before that, I spent a whole lot of time unemployed.
Five years ago I was unemployed with no real prospects, thinking of going back to school. Now I’m a professional software developer. In that time I taught myself how to code in several languages, I have helped start new products, I have worked on and improved enterprise-level applications. By certain measures I do consider myself successful.
Unlike most other people with any measure of success, I am completely aware of the role luck had to play in everything. However, it’s important to realize that luck wasn’t everything. Without my willingness and ability to tackle any problem head-on, and without my ability to teach myself new things, I would have never moved past first-level support.
So while I don’t have multiple years of varying levels of software support under my belt, I do believe I can share what worked for me and what continues to work: my philosophy of approach, my self-teaching abilities, and my attitude.
Who This Series Is For
Because most of my experience comes from B2B Software Support, most of my posts will be written from this perspective and for this demographic. If you’re just starting out in Support, or looking to get a leg up on your previous self, or wondering, “how did this idiot get out so quickly?” then this series is for you.
Each week1 I’ll deliver a new post covering a specific topic. I’ll alternative between topics. This way I won’t spend two months writing about one subject. We’ll cover things like the OSI Model, or how to write a good defect report. Sometimes the post may be quite vague or not immediately applicable.
The goal of this series is not to provide a list of How To Listicles; it’s to provide you with the ability and forethought to build your own knowledge base out so you have a wider platform from which to spring from. A lot of posts will cover generalizations or abstractions, because I can’t pretend to know your specific business and I can’t write about that, and because I’m more interested in writing about fundamentals and inductive reasoning.
As of this post’s publication, there isn’t yet much written overall on the subject for this blog. Below, I’ll outline the general concepts and topics I’m going to be covering. This is subject to change. But for now, consider it The Plan.
- How to Solve a Problem
- How to Write Documentation
- How to Be the Best
- Product Ownership
- Customer Advocacy
- You Are Who You’re With
- Time Management
- How to Teach Yourself
- Finding a Mentor
- Finding Good Resources
- Applied Learning