[danurman]

I work in technical product support and I find this to be a useful framework that captures some important considerations I've dealt with.

When I interview candidates and give them a troubleshooting exercise to test their diagnostic skills, some candidates will use what I call the "shotgun" approach - list out a bunch of tests and things to check, but in such a way that the tests don't build on each other and could be performed in any order. This is the sort of approach that works for "tier 1" style support where you're just running down a checklist.

The best candidates will use what I call the "iterative" approach - try a test, understand what the outcome implies, and then try another test based on that new knowledge in an act-learn-repeat loop. This shows me that they will be able to handle novel product issues that haven't been seen before and aren't on any checklist.

I knew that the latter approach required a stronger mental model, but now I think a more useful framing is that the shotgun approach is about Recognizing and the iterative approach is about Generating. Having this framing is likely to improve my candidate review process and reports.

Also, because we only hire folks who demonstrate the capability to use the iterative approach, when I find someone on my team using the shotgun approach with real customers, my assumption is that their mental model of the product/tech involved is insufficient and my response is to help them build up their understanding. I think now I'm also going to try framing this to them as upgrading from Recognizing to Generating and see if that helps.