how to develop someone’s troubleshooting skills

by Alison Green on April 16, 2015

A reader writes:

I wanted to get your advice on developing a team’s troubleshooting skills. I work with a group of analysts who do fine handling issues they’ve seen before, or when there’s a procedure that applies exactly, but have trouble troubleshooting less common situations. Unfortunately, the nature of our work means that it’s not possible to develop procedures for all possible things that could go wrong.

Often, they come to me for help. My impression is that they have all the facts they need to troubleshoot, but they don’t seem to be able to ask themselves the right questions. For example, if I ask things like, “Is it all the widgets, or just the green ones? What are the steps to build a a green widget? Where’s the last point in the process all the widgets looked right?” I can usually talk them through the process of finding the error. This says to me that it’s not a straightforward knowledge issue, but something more complex.

My concern isn’t about the impact on me (which is minimal, and providing advice is something I’m expected to do, although I’m not their manager), but about what this might indicate about the training and abilities of our analysts. I suspect I need to make changes in how I respond to their questions, as well as some changes in training. Do you have any suggestions as to what I could be doing differently?

It’s the old “teach a man to fish” adage; you’re right to think that you’ll be doing them and your company a service if you can coach them into develop the ability to troubleshoot on their own, rather than always needing to seek your help.

First, have you told this group directly that they should be building troubleshooting skills themselves? Or has their manager told them? If no one has explicitly told them that this is something they should be working towards, they might not even know it’s part of the expectations for their roles; they might think that the status quo is perfectly fine and there’s no reason to change it.

So start by telling them! I’d say something like this: “I’m always glad to help you think through these problems, but I’d also like you to work toward being able to troubleshoot problems yourself. You have enough experience under your belt now that if you step back and brainstorm a bit, I think you’ll start coming up with the same sorts of questions that I ask you when you come to me, and that will lead you toward starting to find solutions on your own. I want to stress that I’m not telling you to stop coming to me – not at all – but rather just that I’d like to see you actively working toward building this skill yourself. It’s really the next step for development in your role. What do you think about that?”

Then, the next time they come to you for help, be deliberate about coaching them the process you’re using. Try asking them questions like: “What do you think?”  “What principles from troubleshooting that we’ve done in the past might apply here?” “Where do you think would be good a place to look first?”

And when you do step in and guide them toward a solution, explain a bit about your thought process, so that they get an inside look at how you’re approaching the problem. Why are you starting where you’re starting? What makes you flag something as potentially the problem? How did youfigure this out back when you were more junior?

Beyond that, I’d also make sure that you’ve shared your impressions with their manager as well. She may have no idea that her team needs to build these skills unless you tell her. This isn’t about complaining or throwing her staff members under the bus; rather, it’s about looping her into what you’ve observed and letting her know how you’re trying to coach them.

I originally published this at Intuit QuickBase’s blog.

You may also like:
{ 79 comments }

{ 79 comments… read them below }

  1. La munieca*

    As a trainer, I agree that training could be part of the solution here. I also think clear management expectations and examining the hiring profile for analysts may be even stronger levers to address this since, as you point out, it may be more of a mindset issue than a knowledge gap. If folks are hired based, in part, on their ability to navigate ambiguity and solve complex issues creatively and then rewarded for those efforts by their manager, the problem may address itself.

  2. Sparrow*

    Thank you for addressing this! I’m currently going through a similiar situation. I’m an IT system analyst and have moved on to support a new software system, but I’m also responsible for doing knowledge transfer and training for my replacement. I’ve been working with my old system for 14 years so I take for granted that the things I know will automatically come to someone knew.

    Like mentioned in the article, it seems the best thing to do is explain and/or document the thought process. There have been times when there there is a time senstive issue that needs to be adressed and I just end up doing the work on my own. I’m trying to get away from this and helping my replacement to work through the process on his own. I also try to document as much as I can so he has something to reference before coming to me for assistance. This can be challenging at times because I’m so used to being in my own head, I have to slow down and actually think about what I’m thinking.

    On the flip side, I’m the one that doesn’t know much about my new system so that’s made me more sensitive to some of the challenges of learning something from scratch. Honestly, I think some of this just takes time and experience. It is a great feeling when you finally “get” something and that understanding falls into place.

    1. Kyrielle*

      I’ve done that sort of training under those circumstances – and when I have to do it myself, I find it helps after the time-sensitive issue is solved if I write up everything I can remember of what I did and why…including the dead ends. Dead ends are important, because NEXT time the reasoning that led me into them may help out with something.

      1. Sparrow*

        That’s a great suggestion about dead ends, thank you! I will definitely keep that in mind.

      2. Connie-Lynne*

        Yes! When we do Incident Analysis, it’s as important to document what the problem _wasn’t_ as what it was.

    2. Chuchundra*

      Yes, when I train new operators the best way for them to learn is to make them deal with actual faults, but I can only let them spin their wheels for so long before I have to offer help or just take over and get things back online. I have dozen of scientists waiting for the machine to come back so they can finish their experiments.

      I can only justify so much downtime for training purposes.

  3. jhhj*

    I wonder, too, what your company’s culture is about asking questions or making mistakes. It’s one thing to go to the person whose job it is and say “Here is a new problem we have never seen before, tell me what to do”: this clearly is acceptable practice. But does the company reward people who try to grow in their roles? What happens if they troubleshoot and do it wrong? Can they come to you halfway through a task and ask for help?

    1. NutellaNutterson*

      I was wondering this, too. They may have inadvertently been reinforced in asking for help earlier in the process than was necessary. If they have managers who want to be “kept in the loop” then this style of interacting proved their involvement.

    2. Cubicle Guy*

      I’m also wondering if it’s a company cultural thing. Where I work, we’re all encouraged to troubleshoot, brainstorm, find solutions ourselves, but a lot of the times there are so many rules and policies that prevent any real creative solutions. Most of the time it’s better to ask a supervisor or someone higher up what to do, than to waste time coming up with your own solution, only to discover policy XYZ won’t allow it.

    3. OP*

      I don’t think it’s a cultural thing – we’re pretty comfortable with the idea that sometimes there’s an issue that no one’s ever seen before, and that you may spend a few days looking at dead-ends before you find the issue. Good point about getting halfway and asking for help, though. I’ll be sure to emphasize that they shouldn’t feel bad about bringing me all the things they’ve already tried, even if they didn’t work.

      1. AnonEMoose*

        Maybe it would help them if you explain that sometimes the dead ends can be helpful? If you know that X didn’t work to resolve the issue, then you know the cause isn’t likely to be A or B, so you know to start looking at C instead.

    4. azvlr*

      I have been on the flip side of this. I really wanted to work independently, but was caught in a odd crossfire of “Why did you do that?!” “Why are you asking me again?! and “Feel free to ask any questions you feel you need to.”

      I came to the conclusion that I was asking questions which my team didn’t really know how to proceed and they were irritated for now having to investigate and make a decision, which they took out on me. I joined a team with someone who had been doing the work by themselves for years, understood all of the implications of their own decisions, and didn’t do things consistently because it didn’t matter because they were solo.

      The really frustrating thing for me was that I would research my question, state what I had done to try and answer the question, and still get pushback. One particular team member used a very Socratic method for answering questions. I had previously been a fan of this approach, but being on the receiving end, I realize it is not appropriate in every circumstance. Sometimes all I need is a simple and quick answer (and now having the appropriate context, I know I’ll remember it), but instead I got lots of “Why do you think you should it that way?” type of questions.

      Bottom line: make sure your processes are as consistent as possible, develop job aids or other resources, strike a balance between having folks think about the “why” and giving them an answer that will keep them productive.

    5. Jeanne*

      I was thinking maybe they have done it on their own before but then told it has to be run through OP. Or maybe they have been told to consult with OP any time they deviate from standard procedures. I think OP needs to make sure she is on the same page as management.

  4. Jennifer*

    Maybe making a flow chart of “things to check” might be good? Lord knows I’d love one for my job.

    1. Kyrielle*

      This! Or a “general case” list of questions that sort of generalize the questions you ask. So, for example, “Is it all the widgets, or just ones of a specific type?” “If it’s a specific type, what makes them different from the ones that are working?” etc.

      1. notfunny.*

        Maybe build this list together? So that you are all talking about what kinds of things to look for? And they are reminded that they can come up with lots of steps without involving you, the OP?

      2. OP*

        My first instinct is to claim that each problem is a special snowflake, but I strongly suspect that that’s not true, so I will do some thinking about how to generalize in a useful way!

        1. Jennifer*

          Well, it helps to have at least some idea of what the hell you are doing. Troubleshooting blind is exactly what I hate about my job, especially when my office also claims every problem is a special snowflake and there’s just nothing to be done but to be thrown in the deep end of the ocean. But I have the impression that there might be some kind of guidelines as to how to troubleshoot that might work in your industry, and that would help a lot.

        2. Emily, admin extraordinaire*

          A checklist or flow chart would be invaluable, IMO. Sometimes you just need to give people a framework for how to think through things. Once they’ve used the checklist for a while, they’ll start asking the same questions of the problem without needing the checklist, and troubleshooting will become more intuitive.

  5. tesyaa*

    I have a related problem. I have someone on my team with almost 4 years of experience who doesn’t use troubleshooting skills, even though he’s been coached to do so. He has the ability to find an issue, but lacks either the focus or attention to detail needed. He also seems to think that bringing my attention to an issue is an accomplishment in itself, instead of coming to me with an actual solution. His behavior would be fine for an entry-level person, but it’s very frustrating to deal with in someone with more years of experience.
    I don’t know how to improve his focus and attention to detail.

    1. Chuchundra*

      In my experience, some people just never get it. We had a guy like that and we kept him on because we needed the body, even though I advised against it.

    2. Artemesia*

      Do you fix it for him? If so, then stop. Instead watch him fix it — so he doesn’t use you rather than work it out. You might still have to help but if you force him to actually do the work, he may become less likely to take the lazy way out here.

      If you have been doing that — well then, time to get rid of him.

      1. tesyaa*

        Sometimes all I have to do is remind him to try for himself, or point him to one of the many tools that he’s already aware of. That’s why I think he’s just not even paying attention. I don’t have the authority to get rid of him, but he’s a bit of a drain.

        1. Snoskred*

          I worked with a girl who would constantly ask questions even though they were answered on the screen in front of her if she could just be bothered scrolling down.

          She was such a lovely person and everyone adored her, so everyone around her would answer the question, even though it took their attention away from what they were doing, or interrupted their phone call, or they had to get up from their desk and go over to her.

          The best manager I ever worked with approached this from a two prong attack. She took each of us aside privately and said we were no longer to be helpful because we were just enabling her, and we were to no longer answer her questions. Any questions were to be directed straight to the manager from then on, with a quick “Sorry I’m busy, ask Manager”.

          If the manager was busy or in a meeting, we were supposed to say “Give me a minute to finish X, but while I do that just scroll down and see if you can find it”

          Just giving her that extra time meant she could find the answer, and answer her own question. And after a couple of months of this, she stopped asking questions unless she was really stuck and couldn’t work it out.

          And now, she is actually the training manager at that company, and she is the one having to tell people where to find the answers that she actually knew where to find all along. ;)

      2. Connie-Lynne*

        One of the training techniques I use when training teams of troubleshooters is something I call shadow-and-narrate.

        The rule here is that the person learning to troubleshoot narrates every step they take and gets a “yes” from the more senior person shadowing them. I encourage them to use chat rather than voice because it keeps a record they can review later (and because, once you are comfortable with this method, it’s faster and more efficient).

        It’s great because it lets the shadower follow the trainee’s thought processes and procedure exactly, and it reinforces best practice (any troubleshooting should be recorded in detail for post-analysis).

        I’ll link to a great article about this by a colleague in the reply.

    3. Sparrow*

      I’m wondering if this is a situation where you need to be direct – meaning, tell him he can only come to you if he has a solution or has tired to formulate a solution. This would be frustrating, especially with someone who is past the entry level stage.

      1. Connie-Lynne*

        The above is the feedback I give to team members who have a tendency to pop up in chat with “QQ!” and then they ask the question, but only a portion of it, because they’re trying to make their question “quick.” It’s far less distracting to the rest of the team if they describe the problem fully, propose a solution, and then ask for validation of that solution.

        The extra bonus is that often the process of fully describing the problem reveals the solution. In tech, we call this the “Teddy Bear Method.” Stick a teddy bear in a room, and nobody gets to ask a question about a problem until they have fully described it to the teddy bear. It’s rumored to cut helpdesk tickets in half for one-person IT operations.

          1. Judy*

            My cats are very good code debuggers. They usually can find the issue when I’m walking through the code with them.

        2. Tau*

          I’m doing some software development for a hobby and I think I need a code bear in my life. (Not that I have anyone to ask questions other than Google, but it’s so true that talking through a problem in-depth often turns up the solution).

        3. Wanna-Alp*

          The name of I know for this technique is the Cardboard Guru technique, where you describe the problem fully to a cardboard cutout of someone.

          I used to think that it was a good name for the technique, until I started work at a place with someone called “Guru”.

    4. AE*

      Some people just don’t have the creativity or imagination to troubleshoot. They need guidance, like outlining specific steps, but as the OP said you can’t foresee every kind of problem.

      Hiring could be an issue too. Perhaps when interviewing the hiring officer can say something like “Tell use about a time when you solved a problem” to find people who have already developed the skillset.

    5. Windchime*

      We have this guy’s cousin at my job. When the problem is brought to his attention, he fixes that problem. So the program will now run and work for today, and that particular problem will be fixed. It usually causes another problem. And then we start the entire process over tomorrow.

  6. TalleySueNYC*

    My mother used to ask us, when we came to her with a problem we wanted her to solve for us: “What would you do if I wasn’t here?”

    The letter-writer might consider whether there’s a trend of “framing the problem” questions she asks people, and write them down. Then use that as the basis of her coaching, and do it as she goes along. Then she can start to say, as my IT does, “Have you done Those Basic Steps (for IT, “restart your computer”) yet? No? OK, go do those, and only come back to me when you’ve explored everything there.”

    I do a lot of training people on the publishing software we use, and I often preface it by saying, “I want you to be empowered to do this on your own, so I’m going to show you something.” It helps; I think it makes people feel invested in listening to the answer.

    1. Cath in Canada*

      “What would you do if I wasn’t here” – I like that! I wonder if a version of that might work for a colleague whose first instinct seems to be to ask for help, even when taking a moment or two to think about the problem first would usually be enough to come up with an answer.

    2. Eugenie*

      I started doing that with my team and it helped tremendously! It’s basically another way of asking them for their preferred solution that’s sometimes easier for them to process. Since I nearly always agree with what they’re proposing I’ve told them that if it’s something that could be dealt with when I’m not here they can go ahead and make the decision on their own. It’s really cut down on the number of trivial problems that cross my desk!

  7. nona*

    Have these people had training that was related to their problem-solving? I know it’s not possible to train for everything, but experience with something related can help.

    A while ago, I only had basic training on a program. There were simple problems that I was aware of but couldn’t fix because I didn’t have any framework for it.

    Eventually, someone from another office visited. I asked if she had a few minutes to talk to me about the program. I haven’t been unable to solve a problem on my own since then.

  8. Cath in Canada*

    I work with a professor who’s always complaining about the lost art of formal troubleshooting. He’s expressed interest in developing a short course on the subject, primarily for grad students but potentially for the whole organisation and beyond, via a webinar or something similar. This post is a good reminder that I should encourage him to develop that idea!

    1. Meg Murry*

      Not exactly the same topic, but along those lines:
      I worked with a math professor who worked with colleges and high schools to develop a problem solving based curriculum. It was originally developed because the school saw a strong correlation between students who had low SAT/ACT math scores and how poorly students would do in their first math class (even if it was technically a lower level math class). He hypothesized that it wasn’t that the students didn’t have the math skills (been taught Pythagorean theorem and the like) but rather that they didn’t have the problem solving skills, and they developed a new intro math course that was required for students below a certain SAT score (and recommended for anyone who wasn’t confident in math).

      The program has been expanded as a resource for all grade levels, and I highly recommend it. Link to follow (will probably be caught in moderation), or you can google “Stella’s Stunners”.

      For the OP – could you run some training on this type of thought process? Pick actual examples of problems employees have brought to you, and have the whole group brainstorm how to solve together (except the person who knows the answer). Then eventually you could expand to have individuals bring a problem to the group, and lead the group through the brainstorming and then present how the individual solved the problem? At a minimum, maybe this could teach them to go to each other when they are stuck, instead of always to you? Sometimes getting a second person involved and talking it through helps work over a problem, but that second person doesn’t always have to be you (or always have to be the next strongest person on the team).

      2. OP*

        I really like this idea of a group session to get practice brainstorming possible solutions, and we certainly have a whole archive of things that have broken over the years. I’ll talk to their manager to see if he’s interested in that.

        1. Not So NewReader*

          My husband was a tech for many years. They would have meetings once a month where people shared their questions and their successes. This was an opportunity to say “hey remember that problem we all were having, I think I figured it out.” It was never a boring meeting.

    2. Judy*

      Training on troubleshooting, or actually critical thinking, is very much alive in the Six Sigma community.

      3. Cath in Canada*

        Unfortunately, the proportion of six sigma stuff that isn’t particularly relevant to academic research is high enough to prohibit my employer paying for people to take the courses! The prof was talking more about how the increasing use of pre-made kits (for example to purify DNA), instead of the more labour-intensive DIY protocols of the past, means that research trainees don’t get the protocol trouble-shooting experience that they used to. On the plus side, more experiments actually work reliably these days, so you can get more done!

  9. puddin*

    I took a green belt six sigma class and it really boiled troubleshooting down to a (literal) science for me. Perhaps this is something you can recommend for the team? It will add value to the organization as well as to the teams’ career expertise.

    1. OP*

      Oh, I didn’t know they had formalized troubleshooting training! That’s definitely something I’ll pass on as a recommendation, then.

      1. puddin*

        Six Sigma is technically a way to isolate and eliminate defects. There are some powerful tools associated with it for brainstorming, problem solving, and analysis. A yellow or green belt are the entry level certifications. It is most often associated with manufacturing, but it can be beneficial in the type of transactional duties most office workers have. Good Luck!

        1. Judy*

          I’d look for a subset of six sigma, as the entire program even at the greenbelt level will emphasize things that might not be necessary, but if you can find the critical thought portion in a course by itself that would be most useful.

          The process involves starting with critical thought to define and explore the problem you need to solve.
          You use that learning to design experiments to understand it more. You may not need that part.

      2. Mike C.*

        Yeah, this is something I do frequently in my job, and it’s really just the scientific method applied to business situations.

        1. Mike C.*

          I just wanted to add that there are a million different flavors of these out there – Six Sigma, Lean/Lean+, RCCA, etc etc. For the most part they are all forms of the scientific method with different specific tools added in to deal with specific issues, statistical analysis and so on. So long as the method you happen to be looking at follows the basic scientific method you learned in school, you’ll be set.

    2. Judy*

      Yes, as I said above, the critical thought exercises as part of six sigma really lay out problem solving in a concrete way.

  10. Alistair*

    This is a very interesting discussion! For me, however, the troubleshooting trouble is myself. I feel as though I can puzzle through a problem and come up with a solution, but then it turns out my boss would have used a different answer (and or wants a different answer) and effectively, my troubleshooting time was wasted. I wind up taking problems to my boss because we’re going to use his solution anyway. Aside from learning to read his mind, how can I improve my skills?

    1. Partly Cloudy*

      It doesn’t sound like YOU need to improve your troubleshooting skills, it sounds like your boss needs to improve her communication skills. Is your boss a control freak that would rather you come to her with every issue vs. trying to solve it on your own?

      I learned troubleshooting pro-actively because I’d rather be self-reliant than be held up waiting for someone else, take someone else away from their work, etc. Many bosses appreciate when an employee comes to them with both the problem AND the solution, or at least a few options for solutions. I know I did when I was managing a team.

    2. Jillociraptor*

      Actually, I’d encourage you to learn to read his mind! :)

      Why does his solution end up being different from yours? Does he have additional context or knowledge about the product/process? Does he have different values or priorities in his work (e.g. for me, with budget questions, I always prioritize saving money and my boss always prioritizes saving relationships)? Does he get to a root solution while you tend to go for a more surface-level one?

      I’ve been able to answer yes to all of the questions I posed, and being able to understand why my boss and I were coming up with different answers helped make me a stronger problem solver, because I could see a problem as me, and as my manager, and eventually as her manager, and as our clients, etc.

    3. Not So NewReader*

      I have had that problem when I was new on a job. I had to learn the limitations that the group worked under.
      The way I broke out of that was to find out the reason why. Of course it is awkward to say “why?” all the time. So I would say, “What is preferred here?” or “If I encounter a similar situation again, what is the overall goal I should be aiming for?” In other situations I have directly said, “I want to spend less time asking you these questions, how do I decide this on my own? What do I look for?”

      You’re right though, sometimes it seems like the boss can just chose the answer opposite from yours simply because it is… well… opposite from yours. There is usually a logic behind it though. So ask, “What is the thinking behind this, so I can chose correctly the first time?”

  11. AnonEMoose*

    Thinking about it, I learned the basics of troubleshooting from my dad. Dad is a mechanic, plus my parents had a small farm when I was growing up. I didn’t have brothers, so ended up helping Dad when he needed an extra pair of hands for something.

    So I spent a fair amount of time with Dad when he was working on machinery, repairing fences, fixing something in the house, and so on. Dad’s a pretty patient guy, and good at explaining stuff, so he was very tolerant of my endless questions about “how does that work,” or “why do it this way,” “what does that do”?

    What I ended up getting out of it was learning how to start with the most common or obvious causes, and narrowing down from there. And learning to say to myself “Ok, so that didn’t work. So what if I try this…?” It’s come in handy quite a lot over the years.

    In terms of coaching, maybe sharing some of your thought process along with whatever solutions would help? Something like, “So the system did this, and you tried this, and it’s still doing it? That probably means it’s not an issue with this, but it could be this other thing, or maybe… Let’s try this first, because even if it doesn’t fix it, it will help narrow down the cause…”

  12. C Average*

    Almost everything I know about troubleshooting I learned from the archives of joelonsoftware.com. No exaggeration.

    He writes accessibly and eloquently about how to approach, define, and tackle technical problems, and his overall philosophy had a huge impact on my troubleshooting approach, which I’ve passed on to my team.

    In particular, his emphasis on the questions “what happened?” and “what did you expect to happen?” was key to my understanding. Teaching people to think along that binary rather than to throw up their hands and wail “it’s not wooooooorking!” is the first step in the direction of good troubleshooting.

    And the suggestion upthread about tracking what doesn’t work as well as what does work is key.

    So is having a well-defined approach to edge cases. If a team doesn’t have the vocabulary to set something aside as a weird one-off, they’re going to spend all their time hacking through the weeds unnecessarily.

    1. OP*

      ‘I ran the process and it didn’t work’ – definitely my least favorite kind of bug report!

  14. Mike C.*

    Unfortunately, the nature of our work means that it’s not possible to develop procedures for all possible things that could go wrong.

    I think the thing here is that you can develop strategies for taking on or anticipating these issues, even if they are unique. This is somewhat difficult because I can’t say what your business is exactly, but have your team build the following –

    A list of all the basic stuff that should be checked – sources of common problems, sources of internal/external documentation, places where updates are posted/notifications left/etc, forums where similar problems are being solved, important contacts of SMEs and the like. List model numbers, software versions, brand names and so on regarding whatever it is that you’re troubleshooting. This serves two purposes – it gives your team a start and serves to answer questions that you won’t have to.

    Have this posted in a public workspace, and ensure this is updated on a regular basis – maybe checked once a week during a regular staff meeting. Have team members prepare any information on updates, changes, new issues that others have seen and so on for this update meeting so everyone is up to speed. Over time, they’ll be able to change and customize this list to better suit their needs, serve as a way to get new members up to speed and ensures that if folks aren’t in the office others can take over.

    Then when something bad happens, the first steps of trouble shooting are already taken care of – you have info on common problems , who to contact for help, Google search terms and so on. Make this a process that people stick to rather than floundering around and asking you for help. If it doesn’t give you an answer that’s fine, but in many, many cases it will give people a direction to go in.

    OP, I do formalized problem solving and data analysis as my job, and it’s really all about taking a hard, analytical look at things. This isn’t a skill people are born with, it takes time and practice to develop.

    By the way, would you be comfortable mentioning what sort of industry you’re in or very generally what sorts of things your team troubleshoots?

    1. OP*

      The stuff they’re troubleshooting most often is a fairly complex ETL system with a lot of varying inputs – a problem is almost always caused by one of those inputs, but tracking it back to the specific one in order to make a correction is challenging because of the complexity. Like any internal software project, it’s under-documented, which frankly is probably part of the problem.

      Thanks for this comment. I’ll do some thinking about how to translate it to our situation.

      1. Artemesia*

        I would assume that it is ‘hard’ and therefore there are a fair number of people who don’t WANT to do rather than can’t do it and thus want someone else to do it. Thus coaching them as they trouble shoot would help.

  15. AW*

    I find that trying to ask a question on a Stack Exchange site is actually a very good way to troubleshoot a problem. The rules for how to ask a good question (http://stackoverflow.com/help/how-to-ask) and how to create an MCVE (Minimal, Complete, and Verifiable example – http://stackoverflow.com/help/mcve) are all about narrowing the problem down as much as possible, being specific, and being able to reproduce it. Those links are specifically for StackOverflow but the same principles apply to all the sites in the network.

    I have started on a question for one of their sites before only to figure it out on my own by the time I’ve finished doing enough work to ask a good question. I think part of that is because you’re trying to get help with something *you can’t show the person you’re getting help from*. I think if your analysts can try to imagine the problem that way, “How do I narrow this down to a small enough, specific issue that someone can help me without being able to see it”, that might help them ask themselves the right questions to start troubleshooting.

  16. TCO*

    Lots of good advice here. I wonder if your coworker’s personality type is also playing a role. I am a big extrovert, and it’s never more apparent than when I’m trying to solve a problem. For me, describing the problem and potential solutions out loud really helps me think things through. I often solve my own problems while I’m explaining them to other people.

    Because of this, my first instinct when I encounter a challenge is often to go talk to someone else. I get rewarded in two ways: I get better solutions by talking things out, and I also get a hit of social interaction if I’ve been holed up in my office for too long. It sometimes takes active, willful resistance to stay at my desk and try a little harder to figure things out on my own before seeking out someone else.

    I manage this in a few ways:
    – I remind myself that solving my own problems makes me look good.
    – I try talking through the problem with myself (in my head) in the same way I would explain it to someone else.
    – When I do seek out someone’s help, I often open with something like, “I just need to talk something through because I’m stuck. Do you have a moment to help me puzzle it out?”
    – I try to vary the “target” of my questions so it doesn’t become disruptive (and I usually pick people at/below my own level, not bosses). When possible, I seek out the other extroverts since I know they’ll understand and will probably need me to return the favor sometime. (We’re big on MBTI in my office.)

    I don’t know if this applies to your coworker or not, but if it rings true, you can guide them to developing their own “coping” strategies.

  17. LBK*

    My sister recently shared this great article about writing good bug reports; it seems like these might be good questions for you to pose to your team members when they come to you for assistance (what did you do? what did you expect? what did you get? what did you try?): http://offbeatempire.com/2015/03/perfect-bug-report

    That will push them to be specific about their issues, which I think is the first step in being able to troubleshoot for yourself. What exactly is broken? When you say “the green widget came out wrong,” was it the wrong size? The wrong shade of green? Took twice as long to be produced? Narrowing down the actual problem to something less vague than “it’s not working” allows you to more specifically test out the parts of the process that could feed into that problem.

  18. Jill 2*

    I understand the thinking behind this, and I definitely agree in concept.

    But here’s something I’ve found — many times when I’m unclear but feel I should be finding out the solutions myself, I take the initiative — and find out my manager or management prefers a different method. It’s not that I’m necessarily wrong; they just have a different preference. I end up feeling like my intuition is always wrong, or at least, not in step with the organization. I don’t mind implementing what they prefer, but my worry is — how can I get to the next level where I would be a decision-maker, if I always seem to choose the wrong method now?

    1. Anon369*

      Yes. This. This is my perennial problem in my current role. I don’t think it’s an imposter syndrome thing.

  19. Lizard*

    The 3rd and 4th year of medical school and most of medical residency is all about learning these skills. You have to be able to get information (from a patient’s description of symptoms, from their physical exam, and from lab/study data) and then put it together into a reasonable set of possibilities and choose additional appropriate diagnostic tests (if needed to identify the problem) as well as treatment choices.

    In medicine, there is a very formalized way of learning this–medical students just starting out are learning to gather information and no one expects them to be able to put it all together, but then in their 3rd or 4th year they’re expected to contribute to the “assessment and plan”–basically, to be able to lay out an argument for what they think is going on and what should be done. Typically this is done in a brief (5 minutes or so) oral presentation to someone more senior on the team, usually the attending physician. Feedback is immediate and often focuses as much or more on the reasoning skills displayed by the student as on the data they’re presenting.

    The things that are probably the most applicable in this process is that 1) there is an explicit expectation that part of the diagnostic process is to come up with a range of possibilities and a plan for testing those possibilities, and 2) regular and immediate feedback about the thought process that went into formulating a diagnosis and a treatment plan.

    1. Jean*

      Yes! I saw this in play recently when accompanying a family member to the emergency room at a teaching hospital. (Thankfully, we left with a diagnosis of Everything Is Fine.) The 4th-year med student gave my patient a marvelous exam, with stops along the way to engage the 1st-year med student observing. “See how that looks there?” “Do you remember how the ABC bone connects with the XYZ muscle?” “What do you think is happening?”
      No desire to enter medicine myself, but it was fascinating to watch.

      1. Jean*

        make that “I have no desire to enter medicine myself…” Apparently, I have trouble writing a clear sentence after 9:55 p.m.!

  20. Cassie*

    For me, the person needing the help troubleshooting is the manager of the unit – she has the least amount of experience and was the last one hired, but the highest on the totem pole. It was one thing when she first joined our office – I was happy to train her and help her figure stuff out. Except that I used to have to spend 30 minutes to an hour every day standing there in her office as she talked through her process. After about 3 years, she stopped asking me as much. But there are still times where she will come to my desk to tell me about an issue and explain what she thinks will be a good solution. I guess she lacks confidence? Plus her micromanager of a boss wants to be updated on everything so I guess it’s ingrained in her mind.

    I firmly believe in teaching people how to fish but I’m not so good in telling people this. I tend to start being a little less nice and end up giving them half-answers to the point where they learn to go ask someone else.

  21. Indy Rox*

    I have run into this before, and am dealing with this now. There are

    1. Person is not motivated. They know that asking X person will provide a quicker answer with less effort.
    2. Person has a lack of confidence in themselves. It could be bad management trauma, imposter syndrome, handling a high doller project, and a variety of other issues.
    3. Person does not possess the basic knowledge to navigate the problem. I am facing this now with an employee that does not have the basic knowledge to troubleshoot. Employee X does not understand inbound scripts for Teapot Orders, so when it comes time to implement new Teapot Orders for a customer, Employee X is lost. They sit stagnant unless someone else does the job out of pity or frustration.

    In the 3rd situation, we have deeper issues. Hopefully you are dealing with 1 or 2.

  22. Thomas W*

    Communicating expectations is something I’ve struggled to do better as a manager. It’s so easy to let yourself assume that your team knows what you expect of them — but they cannot read your mind. I had a guy make the same mistakes over and over, which really frustrated me. I’d walk him through the same fixes every time, and assumed that he was too lazy to learn them for himself. When I finally made it clear that he needed to learn them for himself, he panicked a bit about how it would slow him down. That was no problem for me — but he’d been assuming all along that I needed speed at all costs. His speed took a hit at first, but now he delivers good results, quickly. Never assume that your team will know your expectations without your telling them explicitly.

  23. Vicki*

    Not everyone is skilled at troubleshooting. Not everyone is able to learn to be skilled at troubleshooting. Not every skill os teachable.

Comments are closed.