Motley says: "Human Performance Technology? Do I need a profiler for that?" (HPT Part 2)

Summary

 

Motley:  Human performance technology is about behavioral psychology? I have no background in that, so I can't use it!

 

Maven: Leverage a very simple model that encourages root cause analysis and problem solving along 6 primary dimensions - expectations and feedback, tools and processes, incentives, knowledge and skills, capacity, and motivation.

______________________________

 

[Context: A continuing conversation about Human Performance Technology and how to use it to identify and solve problems in the workplace]

 

Motley: Ok, get to the point. We talked about this weird "Human Performance Technology" to identify and solve problems, but you haven't gotten to the details of how to identify different types of problems and come up with non-obvious solutions! I'm not seeing the value!

 

Maven: Patience, my friend. Patience. We talked about identifying the business needs for a given situation, the "to be" state, and current state, and doing gap analysis. The next step of the process is to help figure out the root causes of those gaps. One way to do that is break the problem down into six dimensions that come from behavioral psychology:

  1. Expectations and Feedback
  2. Tools and Processes
  3. Incentives
  4. Knowledge and Skills
  5. Capacity
  6. Motivation

 

These dimensions allow us to put a framework around our thinking. Notice that 1-3 have to do with the environment and 4-6 have to do with an individual. We need to look at problems systemically and consider all of these axes.

 

Motley: This sounds complicated! Behavioral psychology? I have no background there!

 

Maven: No problem. The core concepts are really quite easy to understand and anyone can do it. Let's start by tackling the first three categories on the list above. These three focus on environmental and team factors - things that affect the team overall and much less the individual. The first is expectations and feedback.

 

Motley: Well, since this is all about getting to root causes and finding solutions, I'm assuming there are some questions that we should be asking. What kind of questions apply to a category like expectations and feedback? I'm expected to write great software and if I don't someone is going to tell me about it.

 

Maven: You're right on the questions! With expectations you want to make sure that everyone is on the same page with respect to what is required to get the job done. This is important to getting the right results. In your example, what does "great software" really mean? Different people may have different definitions. You really want to get to the bottom of whether people know what the expectations are. And when people are not meeting expectations, they should know about it and be given concrete actions on how to correct the behavior. Here are a few questions to ask:

  • How are performance expectations communicated to employees? Make sure they are not dictated and that employees are clear on expectations. Perhaps everyone writes a set of commitments in your organization?
  • Are employees given timely feedback regarding their performance? Waiting for the end of a software release to correct actions that occurred at the beginning is ineffective. Feedback needs to be early and often.
  • Do managers in the group support this direction? If the team is going in a direction that differs from the business, it may not matter if they do a great job. If a team wants to do unit testing to beef up quality, but management does not provide time in the schedule, it's a lost cause.

 

Motley: I bet this is probably the most important dimension. No matter what other solutions you put into place to solve problems, if management doesn't buy in and provide feedback on how you're doing, forget it.

 

Maven: Great observation! When you really get to root cause of many problems, you'll often find that expectations and feedback are at the source. The next dimension to talk about is tools and processes.

 

Motley: Something every developer is concerned with. Plus, I'm talking with the right person - a real-life living "tool"!

 

Maven: Another great colloquialism from Mr. Motley. Tools and processes are important ways to enable the right results. Tools that review code automatically or organizational processes that get in the way, such as build verification tests that are too comprehensive, are items to explore here. Here are some questions to ask:

  • What processes and tools are currently used? Is there a gap in our current inventory? Software teams, particularly large teams, always leverage tools and processes to get the job done. Determine if there is a gap in processes and what we can do to solve it.
  • Do these processes and tools meet team needs and/or solve the problems that the team is having? Why or why not? Find out if there are redundant processes in place or tools that do not fully solve a problem. Replacements may be in order. Learn from other teams what they are doing to solve the identified problem.

 

Motley: As a developer, I spend a lot of time with various software tools. As for process, you can have it. It just gets in the way!

 

Maven: It shouldn't. Process is necessary to make for repeatable high quality results, but if it is too formal or complicated that it gets in the way, well, that's a problem that needs addressing. The next dimension to discuss is around incentives, which is often grouped with consequences.

 

Motley: Ah, like our previous conversation on punishing people for build breaks!

 

Maven: Sort of. On the incentives side, if  an organization does not have suitable incentives in place to reward people for a job well done, it can be difficult to (a) find good people to do a great job; and (b) convince the people you have to do a great job. Some questions to ask here are:

  • Do the employees know what success looks like? Related to expectations, but what does success look like with respect to incentives?
  • How are employees rewarded for successful performance? Successful organizations reward employees for performing well and producing solid business results. Teams that are not rewarded in some way tend to crumble.
  • Are there opportunities for career development? Solving technical problems and producing great results is less significant if employees are in dead end jobs with no opportunity for advancement.

 

This dimension is usually less of a problem, but is one worth considering when examining human performance.

 

Motley: This all still sounds pretty complicated. I'm sure there are lots of details to each of these dimensions as well that we haven't covered!

 

Maven: Yes, there are. However, what these six areas do is help ensure that you examine a problem and think about solutions from various different aspects of human performance. Often people jump to one solution - often training - as the cure to all their woes, but in fact, there are other things that may be further up the root cause chain. For now we've only talked about the first three around environmental factors. Let's shift gears and talk about root cause analysis and solution identification of individual problems...

______________________________

 

Maven's Pointer:  Attend an International Society for Performance Improvement (ISPI) conference if you get the chance. Although the conference may not be specific to your organization's problems, it is useful to get yourself in an HPT mind frame for a few days and chat with people in other industries about how they apply HPT.  You will hear about other HPT processes and get more information about what was presented above. The conference may provide you with a logical frame around solving tough business problems, particularly for larger groups of people.

 

Maven's Resources: 

  • The Six Boxes: https://www.sixboxes.com
  • Human Competence: Engineering Worthy Performance, by Thomas F. Gilbert, Pfeiffer, ISBN: 0787996157, Reprinted March 2007.

Comments

  • Anonymous
    March 31, 2008
    i want to know three reasons why human try to ddevelop tools to solve problems