Motley says: "Human Performance Technology? I guess I better brush up on my robotics." (HPT Part 3)

  • Article

Summary

 

Motley: Training is the best solution to most problems. If a developer doesn't know how to do something, teach that person. Problem solved.

 

Maven: Training is only one solution, and may not be the best one. Consider Human Performance Technology and address the problem with a results focus from both an environmental/team perspective and an individual perspective.

______________________________

 

[Context: Maven is about to enlighten Motley on 3 dimensions of leveraging Human Performance Technology focusing on individuals]

 

Maven: Last time we were talking about Human Performance Technology (HPT) and how to use the technique for root cause analysis and problem solving. If you recall, there were six dimensions that we talked about when analyzing a current situation:

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

 

Previously we talked about the first three on the list, which identified areas to investigate in terms of the overall environment. Much of the time, those three are to blame for larger problems in an organization. However, to do a thorough analysis we have to consider individual factors as well.

 

Motley: You mean like when there are some obvious bugs in the system it is usually one of your individual code check-ins that's to blame?

 

Maven: Not quite like that. Let me explain. The first one we'll talk about is #4 on the list - knowledge and skills.

 

Motley: Isn't that the solution to most of our problems? If we knew how to solve them we would just solve them! Knowledge and skills acquired through training fixes everything!

 

Maven: Knowledge and skill in a particular area is important. For example, if you want to improve performance in an application, you may consider a multi-threaded design. If you have never written a multi-threaded application before, you may need some training in how to do it. However, if the schedule doesn't give you time or there are no tools to facilitate the job, no matter how much you know, the feasibility of that approach is limited. Lack of skill or knowledge is often a contributor to a problem, but not necessarily the root cause nor is training the key solution.

 

Motley: I guess that makes some sense. If my boss has the expectation that we cannot take time from the schedule for training, I cannot fill the skills gap via training - we have to reset the expectation first. Pretty smart, Mave.

 

Maven: Why thank you, Mot! Individual development plans for employees should be part of the equation, and that should include training. Training isn't usually THE answer, but it can help. The next dimension to look at is capacity.

 

Motley: Why are we talking about electronics concepts here??

 

Maven: That's capacitance!

 

Motley: Um, yeah. I knew that.

 

Maven: Capacity is all about having the right people in the right roles to get the job done effectively. If you want to tackle a concurrent multi-threaded design but your team is a group of students who don't even know what a thread is, well, perhaps the problem is better left to another team. Even beefing up the skills and knowledge side may (and perhaps will) still lead you to disaster.

 

Motley: So lack of capacity means fire the whole team and replace them.

 

Maven: Not exactly. In reality, capacity is generally not an issue, but it is an important dimension to look at when determining root cause and deriving solutions. You want to have the right people on your team and they need to be doing the right tasks for their skill set. The last area to discuss in the model above is motivation.

 

Motley: I'm motivated as long as the incentives are there!

 

Maven: That's an interesting statement. Motivation and incentives are often related and may be dealt with together. Motivation is all about creating a positive work environment and ensuring people feel appreciated for the work they do. As a senior developer, Mot, you must take extra strides to motivate people. Do your team members feel valued? If not, why not? Is there anything you can do to improve morale if it is low?

 

Motley: Alright. Let me take a crack at summarizing.

 

Maven: Awesome! Using active listening is a great practice to have - you validate what you just heard, make sure you heard correctly, it helps with memory retention, and it validates for the speaker what was said.

 

Motley: Thanks, Einstein. I know all that. That is why I'm summarizing! Anyway, using this Human Performance Technology (HPT) stuff is supposedly great for finding root causes to problems and identifying solutions you may not otherwise have thought of. You examine your business needs around the current situation, specify the details of that current state, identify the "to be" state that is your ideal future, determine the gap between the current state and future state trying to find root causes, and then apply these six dimensions - expectations and feedback, tools and processes, incentives (these from the environmental and team perspective), and skills and knowledge, capacity and motivation (these from the individual perspective) - to determine suitable solutions in some areas that may not have been obvious. That's it, right?

 

Maven: Very good! There is one last step though. As many of the other processes we have talked about, this one is iterative as well. Early on and also while deriving solutions, you want to come up with a way to determine in the future if your interventions (solutions) were successful. You do that by deriving some measurements that allow you to evaluate your solutions.

 

Motley: Won't it be intuitively obvious whether something worked or not? What's the point of all the extra effort?

 

Maven: You don't want to leave any question as to whether the solutions that addressed the problem caused an improvement. Remember: HPT is results-based. You want to have a concrete measurement as to whether your results are what you want. "Measurements" don't have to be purely quantitative, but you need something concrete to aim towards. For example, if we are addressing build breaks, we need to know the current state (e.g. 4 breaks per week) and the future state (e.g. zero build breaks per week). Just by examining the future state we have a measurement in this case. It's not always that obvious, and there may be interim measures, but you want something to track.

 

Motley: And I guess if quality is a problem, there are all sorts of metrics around that, such as defects found by the test team, defects found by the customer, defects after check-in, etc.

 

Maven: You got it.

 

Motley: Great. I am intrigued by this HPT thing. It really brings to light that training a team member in some area may not be the best way to address a problem. You have to look at the problem from other angles.

 

Maven: Yep. Feel like buying me lunch for all this great information?

 

Motley: I believe you already know the answer to that question. If I apply HPT here, the root cause to the stupidity of that question is probably your lack of skills and knowledge - and ultimately your capacity - in reading people.

______________________________

 

Maven's Pointer:  Human Performance Technology is in wide use at Microsoft in the Engineering Excellence Group (EEG). Microsoft's engineering central body used to be exclusively aimed at training, and was previously called Microsoft Training and Education. However, the current focus is much wider. EEG takes an HPT approach to solving engineering problems across the company. Training is still one part of it, as mentioned in the sixth dimension, but there are five other factors. Carl Binder built on the work of Thomas Gilbert and calls these dimensions the "Six Boxes". It is highly recommended that you explore this model when attempting positive organizational or team change.

 

Maven's Resources: