Building Capacity by Modeling Technical Skills

Building Capacity by Modeling Technical Skills

The student consultant's first goal is to build the community partner's capacity to use technology. Learning is at the core of building capacity, and there are more and less effective ways to achieve this learning. Just as you have seen that being an apprentice to your community partner is an effective way to learn about their organization, modeling technical skills such as troubleshooting, system design, or development, is a good way for your partner to learn technical skills from you. Making technical skills visible is an educational strategy that provides the community partner with access to what the consultant is doing, and why. It provides a favorable working relationship that allows the partner be part of the process and learn from it, without being "trained".

Throughout this class, you have been advised to be working with and not only for your community partner. There are multiple models you can use when working with your community partner, and how you do so determines how much they can learn from you.

Black Box Models

A black box model is one which can produce an answer to a problem, but in a way that is a mystery to the user. The intelligence that led to the answer is hidden inside the system. Consequently, the user is unlikely to be able to learn anything from it, or be able to troubleshoot it when it does not work. For example, a calculator can be considered a black box model of arithmetic, and while it may be useful for finding or checking an answer, it will not teach you how to multiply.

Similarly, community technology consultants can be "black box" experts, but in doing so, their community partner is unlikely to learn much from observing only the results. One way for the consultant to be a "black box" expert is to work when the community partner is not present. One student in the past, who was very unsuccessful as a consultant, thought he could help an organization by building a proxy server and then turn it over to his partner to use. The partner had no idea how the server was configured, so he could not change the configuration when he needed to, and could not troubleshoot problems when they arose (and they inevitably will). Another way to be a "black box" expert is to just remain silent as you work.

Similarly, a student consultant can create a black box model as a solution. If the problem is simple enough, and the technology is robust enough, the student consultant can create an application or implement a feature that the user will not need to understand, but will just work whenever used. For example, the student consultant can implement a button in a database that will run a query and create a report for the user, without the user needing to understand how the query was formulated and executed.

Glass Box Models

Glass box models make visible the steps used in solving a problem. By watching, the user can see, and perhaps later repeat, the steps necessary to reach a solution. But while the steps are visible, the reasoning that lead to taking each step is not. As a result, an observer sees a path to solving a singular problem, but not the general reasoning to solve a variety of problems. An example would be to watch a Khan Academy video (http://www.khanacademy.org), but with the sound off.

A consultant can act as a glass box expert by talking to his or her community partner in the following way:

"The document is not printing so I launch the Print Manager and check that the settings are correct, then check that the cables are attached, and then look at the printer configuration settings to see if they are right. Yep! That is it, the printer thinks it is connected via USB."

Notice that the consultant did not mention how the settings are correct, nor what the correct cable configuration is. What does the community partner learn from this? He or she can glean a set of steps to take:

1) check Print Manager,
2) check cable connections,
3) check printer configurations.

Having a set of instructions, documentation, or a screencast is a good fallback when the community partner does not remember how to do something, or to pass on knowledge to new employees or volunteers at the organization. Beyond just addressing normal working behavior and situations that succeed, good documentation tries to anticpate where problems can come in and provide ways to get around them.

Cognitive Problem Solving Model

A even more effective way to help community partners add to their technical skills is to make visible your own cognitive problem solving processes. This is actually quite easy ... as easy as verbalizing such things as the observations you are taking into account, the inferences you are making, and the options that are available. This is done in an informal conversational manner. As an example, consider troubleshooting the printing problem again:

"So if I create a simple document and print it.... <waiting>... nothing happens. The application creates a print file that is spooled, i.e. set aside, for the Print Manager to take care of sending to the printer. What is the Print Manager doing? If I launch the Print Manager, a-haa! There is my print file. Why ... and it says it is printing. To where? So we know that the application is able to create a print file. And we know that the Print Manager is at least basically working in that it is trying to send the file somewhere. We now need to figure out why, what the Print Manager thinks it is printing, is not being printed. The problems I can think of at this point are either the Print Manager is set up for the wrong type of printer, or it thinks the printer is local and not on the network, or the network cable is not corrected properly, or the printer itself is broken or misconfigured. Which would you bet on? The network cable is easy to check, so lets try that one first. That seems fine. The Print Manager thinks it is connected to an HP IIIp, and it is connected to it via USB. There are several ways to connect to a printer, one is directly by a USB cable, another is wirelessly by Bluetooth, and a third is via the network. That is the problem. The computer thinks the printer is connected by USB, and it is not. It is available on the network. This printer must have been connected directly to this computer at one time and set up for USB. Now that the printer is on the network, and not directly connected, the computer cannot find it. We need to reconfigure it to look for the printer on the network.

Troubleshooting in this way gives the community partner much more information about the troubleshooting process; much more information for them to learn from for future use. It also provides innumerable opportunities for community partners to step in and exercise their technical skills. There are plenty of questions to answer, next steps to suggest, or alternative paths for them to explore on their own.

This technique does not only apply to troubleshooting. It can apply to just about any technical skill, such as designing a database, evaluating a web site, networking a computer lab, installing a content management system, or specifying the components of a technology plan.

Cognitive problem solving can then be backed up with the other models. For example, by working with the community partner to develop instructions, user documentation, or screencasts on how to fix recurring problems. In this way, the community partner has the instructions to keep and share, and also their own experience of watching the problem solving to fall back on if the instructions don't apply.

Furthermore, if possible, all 3 models can be used. In some situations it may be possible to (a) have a black box button to do whatever operations are necessary, (b) leave blass box instructions in case the button does not work, and (c) demonstrate your cognitive problem solving for the community partner to draw from if the problem is slightly different than the instructions cover.

Modeling Technical Skills

To model technical skills, an excellent first step is to just articulate everything that comes to mind as you work. This technique of giving a verbal protocol has been demonstrated to be an excellent way to bring light to the reasoning that we do in all types of problem solving tasks. But beyond our own reasoning, it is also possible to add to what we verbalize so as to help our community partner learn from the experience.

Throughout a day, we have many experiences. We frequently read text, talk with people, and see a lot of things. It's obvious that we don't "learn" everything that there is to learn from these experiences. We can walk past and glance at the entrance of Doherty Hall several times a day, but never learn the number of windows it has, or what the current set of signs are advertising, or whether there are decorative light fixtures bookending the doors or not. We learn from our experiences when we reason with them: either as a reflex, or by choice (i.e. "studying"), or by surprise, or by any other way that brings us to do something else with the experience than just experience it.

Research into learning strategies employed by chance or choice have distilled a set of useful ways in which people work with experiences and learn from them. Briefly put, these learning strategies include:

  1. Add structure to what you are problem solving - look for relationships within the experience in order to form categories, hierarchies, common stories, or any other framework that adds structure to the experience.
  2. Put the problem in a context of what the community partner already knows - look for relationships between the experience and what has already been experienced and learned.
  3. Make inferences explicit - look for ramifications beyond the current experience, such as positing generalizations or describing implications.
  4. Give lots of examples
  5. Monitor what is known and what is not - take stock of what is currently known and what is unknown about the current situation.
  6. Use multiple representations - generate other ways of expressing the same ideas, such as in pictures, analogies, metaphors, or summaries.
  7. Manage attention - deliberately decide what details to focus on and what not to. What are likely to be the promising paths to investigate and what are the unlikely ones. Why?

Remember that the community partner is looking to learn from the consulting experience. If you can provide information not only about the successful steps you take to fix a problem, but about the reasoning process you used to arrive at the solution, and furthermore you elucidate that process in ways sympathetic to how they can learn from the experience, then you have provided a wonderful learning opportunity for your community partner.

What does this play out in concrete terms? Consider the earlier example:

"So if I create a simple document and print it.... <waiting>... nothing happens. Cues the context that you are troubleshooting
The application creates a print file which is spooled, set aside, for the Print Manager to take care of sending to the printer. Multiple representations - spooling can also be thought of as being set aside for the Print Manager to take care of.
What is the Print Manager doing? Monitors what is known and what is not
If I launch the Print Manager, a-haa! There is my print file. Why ... and it says it is printing. To where? An inference problem is raised because the Print Manager says it is printing, and the printer is not printing. Implies that the inference should hold, but is currently broken.
So we know that the application is able to create a print file. And we know that the Print Manager is at least basically working in that it is trying to send the file somewhere. We now need to figure out why, what the Print Manager thinks it is printing, is not being printed. Monitor what is known and not to review where they have come from and where they need to go.
The problems I can think of at this point are either the Print Manager is set up for the wrong type of printer, or it thinks the printer is local and not on the network, or the network cable is not corrected properly, or the printer itself is broken or misconfigured. Make inferences explicit of where problems could be located.
Which would you bet on? The network cable is easy to check, so lets try that Invitation for community partner to join in. Attention management.

That seems fine. The Print Manager thinks it is connected to an HP IIIp, and it is connected to it via USB. There are several ways to connect to a printer, one is directly by a USB cable, another is wirelessly by Bluetooth, and a third is via the network. That is the problem. The computer thinks the printer is connected by USB, and it is not. It is available on the network

 Adding structure - This describes the set of options that are available to connect a printer and shows that they provide a set of alternatives that must be considered.
This printer must have been connected directly to this computer at one time and set up for USB. Now that the printer is on the network, and not directly connected, the computer cannot find it. We need to reconfigure it to look for the printer on the network. Making inferences explicit.


To summarize, when working with your community organization, do it in the presence of your partner. While you are working, verbalize as much as you can about what your are thinking about. Try to give structure to what you are doing, and to what you are working with. Use plenty of examples. Articulate the inferences you are making. Try to use alternative ways to explain what you are doing, or how the device/software/whatever works. And give plenty of opportunities for your partner to join in and/or take over!