When it comes to moving up the professional ladder, the ability to identify problems and offer up solutions can be a game-changer for you.  Let’s explore how this is done.

If you’re an engineer or right-brain thinker, you’re probably familiar with systems and processes. In the workplace, instead of thinking about systems and processes, think about your frustrations. What are the events or occurrences that keep you from being productive in the workplace? What things could be done more efficiently?  Are these things part of a system or process?  It may be tempting to jump immediately to a solution, but let’s first consider some general troubleshooting rules that I have realized over the years.

11 Tips for Troubleshooting Your Workplace Problems

  1. When it comes to troubleshooting systems, you need to understand how the system works. Depending on system complexity, this can take days, months, or even years. The more you know about the system, the more effectively you will be able to identify issues and increase efficiency. The converse of this one is, if you don’t know much about a system, learn more about it before you suggest improvements. Just keep your ideas in your back pocket as you learn. First impressions are often correct.
  2. Important processes and systems require redundancy, particularly for aspects of the process or components that are prone to failure.
  3. Isolation is a great troubleshooting technique – can you isolate a system failure to either just the hardware, software, or network? Determining where the problem isn’t helps you to narrow down the location of the actual problem.
  4. Here is one that developed just in the last 10 years or so: When you get an obscure error code or problem, Google it. Taking this further, these days you can do an internet search on most system problems and review what others have done to correct the problem. Your goal in troubleshooting is to quickly isolate and resolve.  With that in mind, if you can resolve a situation more quickly by going to the Internet, then do it.
  5. Once you get good at identifying problems and providing solutions, don’t worry when someone else takes the credit. You can also share your ideas with a team and let the team take credit. You will be known as a real solutions provider. Besides, you will have another idea tomorrow.  The person who had to take credit for your idea?  Not so much…
  6. A person or group of people within a process will be the number one thing that breaks or slows down that process. If you must have a person as part of a process, make sure that the individual is both responsive and responsible. Avoid inserting people into a process if possible.
  7. If your system has a problem, that comes and goes, it is an intermittent problem. If you don’t know what caused it, then it will most likely happen again, so look into it. Hoping that something will not reoccur is not the best of strategies.
  8. Monitoring is your friend. Set up monitoring so that you get notified before a problem happens. For example, “Drive 0 is at 95%.” Years ago, one of my favorites was a critical system that was a remote part of our mission system. The problem was, we did not own it, so we could not put any monitoring scripts on it.  One of the guys came up with a simple script that ran a ping on the remote server.  If that ever failed, the script would generate ‘ Call out the dogs, server (name withheld) is not responding to pings.”
  9. The ‘Deming principle’ applies: those closest to a problem are most likely to come up with effective solutions.
  10. The end goal is typically quick resolution. The steps you take need to keep that in mind. If you can quickly rule out all of the software, all of the hardware, or the network, then do it. Have a method to your troubleshooting that is designed to narrow down the problem as fast as possible.
  11. Bonus tip: what changed? Those of you who troubleshoot problems know all about this one. Was some software recently added or upgraded? Did a feeder system get modified? Is the network team doing any work in the area? Is the communications center doing anything that would impact your system? Do a quick survey of the area before you tear into your system and potentially introduce new problems.

In the first part of my career, I was technical.  The systems problems that I identified and resolved were often the result of “troubleshooting.”  Both in the USAF and as a young contractor technician working in Operations and Maintenance (O&M), the hardware was much more expensive and valuable than the software.  There was a lot of hardware troubleshooting to go around. Before I could identify a problem, I had to have a good understanding of the system(s) involved. If your job is to maintain systems, then spend your time learning everything about the systems, including all inputs and outputs. The more you know, the more likely you will be able to provide improvements and reduce downtime. Take notes and keep a digital log of what you do. Identify system names, errors and actions taken. Over time, this will become a valuable resource and one of your troubleshooting tools. (I know I have seen this before. What did I do to fix it?)

How do you apply this to your own situation in the field, in the office, in the SCIF?  What are your sources of frustration?  A big reason why frustration arises is because the system or process does not work as efficiently as it should. It breaks down and provides no result, a wrong result, or a delayed result.  What exactly is the problem?  What would you do to fix it?  Write it up.  Identify the system or process owner and discus your suggestions for improvement.

A Real Intelligence community Problem

Let’s examine a current Intelligence Community problem. The Agency Program Executive Officer for a new program identifies the required labor categories (LCATs).  They then identify the required skills, experience and training of each LCAT and level, from junior to expert.  The program is put out to bid. Teams price each LCAT and level based on the requirements of the LCAT. The program gets awarded, kicked off, and the prime PMO meets with the Ops customer who explains the type of skills and experience contractors really need. (For example, a Senior Software Engineer with Python, Docker, Ruby, Gradle, Jenkins, and Groovy). The contractor program manager looks at the Sr. SWE LCAT and it is as if the two do not match other than degree and years of experience. Contractors MUST meet the LCAT requirements that may or may not match what the Ops customer actually requires to accomplish the mission. Contractors are then forced to meet the LCAT requirements (because this is mandatory), and then also meet the Ops requirements. When you add both sets of requirements, it increases the cost and reduces the likelihood of finding what has become the famed “purple squirrel.”

Potential Solutions

Here are some potential solutions to this problem that is so common that 80-90% of contractor PMOs will recognize it.

  1. The contract could use the LCAT requirement as a guideline ONLY. By approving a resume for a labor category, the ops customer will verify that the contractor is at or equivalent to the contract LCAT. If need be, the PEO could approve each such change, but I would not want to add more time to a process that can take too long already. Also, remember what I said about people and process efficiency.
  2. Similarly, the ops customer could excuse some of the LCAT requirements that do not apply while adding additional requirements that are needed by the mission.
  3. Provide 5-10% cost flexibility so that as ops places new requirements from a specific LCAT, the contractor has a better chance of hiring the increasingly rare individual.

Give this problem some thought.  What is your solution?

Improve Your Workplace

Without doubt, being the kind of employee, supervisor, or manager who can identify process and system inefficiencies and provide solutions will enhance or even propel your career. The most important factor in being able to do this is understanding the system or process in question. You don’t have to be in an O&M position to develop an understanding of how the systems you use work, and what their inputs and outputs are. If you have an idea for improvement, work through it to ensure that it makes sense and would achieve desired results without introducing new problems, then bring it up with the system or process owner. Take action against the sources of frustration in the systems and processes you work with. Make a difference and improve your work environment, the mission, and the overall efficiency of the people you work with.

Related News

Todd Keys is a Program Manager at Cantada, Inc. He has been in the intelligence Community for 30 years, as a member of the military (USAF), and as a contractor for top 100, top 10, and small business federal defense contractors. He has held multiple roles, CONUS and OCONUS, ranging from technician to executive, providing site O&M, system administration, engineering, supervision, contract management, and Capture/BD for the DoD and multiple intelligence agencies.