Mentor or Coach

Over lunch a couple of days ago, we were discussing the subject of mentors and coaches and started to highlight the difference in the roles. Sometimes people can seemlessly operate in both roles at once, so the roles do not seem distinctly different, but they are.

We discussed a few items that seem to differentiate the two roles:

One of the items was Blind Spots. Coaching is designed to identify blind spots, where mentorship is more designed to overcome blind spots once identified. Sometimes the coach can guide the coachee in ways to overcome the blind spot, while in other situations they might recommend they obtain training or a mentor.

Another item was Proximity. Coaches are generally involved with what they are coaching you on, whereas a mentor is someone you mostly meet with to discuss things with. Coaches tend to actively participate in the thing they are coaching you on so they can witness your actions and provide advice and direction if improvement is needed.

Another item was Selection and Appointment. Although some organizations have more formal mentorship programs, generally coaching relationships are formal and assigned for a specific reason. Mentors are normally sought out to discuss and close a gap.

When we were discussing the subject, we discussed two different types of coaches–Lean Six Sigma and Executive. Both of these are very specific roles where an individual is involved with what is going on in a coachee’s life. In Lean Six Sigma, for example, the coach is engaged with every step of a coachee’s project,  guiding them in the application of the skills they should have learned already. If the coach recognizes that the coachee has difficulty in running meetings or presentations, they might suggest that the coachee obtain additional training in those areas. If the coach notices that the coachee has trouble with time management, they might suggest establishing a mentorship relationship with someone that they know is particularly good at time management. If the coach is good at time management, they might quickly switch into that mentor role, but this is outside of the original coaching arrangement.

This is why people often see coaches and mentors as the same thing–they can cover more areas than what they are specifically coaching for. In the case of an executive coach, the coach might be able to provide all kinds of advice and assistance on leadership and employee motivation. However, they probably would suggest the executive have a mentor if the coachee is trying to learn how to navigate the company’s culture toward promotion.

When you think about the roles, this should help you better delineate what each does and which you need.


What’s best for who…Lean, Six Sigma, Design for Six Sigma

Lately this item has come up for discussion. What is the best approach to process improvement, should we teach all, how much of each should you employ?

From a practitioner’s point of view, this matters, but in reality, out on the floor, managers and workers need Common Process Sense. Recently, one of the managers I work with went through Lean Six Sigma Yellow Belt training which is much more Six Sigma than Lean. She had already taken Green Belt because that was all that was available, but that course overwhelmed her.

What she came back talking about we’re tools. That’s great, but I realized that she’s not going to be a practitioner, she needed real world ideas that she could apply immediately when she returned to her office.

I believe that true Lean has more common sense approaches, but they can be just as confusing, especially when they use odd names and such, like Huddleboards, Gemba Walks, Ohno Circle, 5S, A3, Hoshin Planning, etc. Let’s face it, true Lean requires a Rosetta Stone course to fully understand.

Long ago, the Air Force created the Air Force Quality Program. They had some very basic courses that focused on Awareness of the program, how to manage Teams and use Basic Tools. The Air Force program was around from about 1990 to 2000–about 10 years. The basic common sense training that I started with is what really got me involved. I understood it and was able to apply it every day.

These are the basic skills that people working on the front lines need to know…they need to be taught and then mentored through application.

Process Mapping. Everyone needs to know how to write down their step-by-step process so that anyone can pick it up and follow it. I’ve said it before that leaders tend to say “Map to X level,” but that’s based on a belief that process improvement practitioners are doing the mapping…no. Everyone that works in a repetitive process should have a process map that outlines every single step of the process written in narrative form and if it uses a computer, the narrative should include screen shots and file locations. If there are physical steps that need to occur, then photos of those physical activities should be included. In Lean you would call that Visual Work. No one can tell me that this is a waste of time for the person doing the work. Additionally’ no one but the people doing the work and the managers that manage the work need these process maps. You don’t need any special software to do this…you can write it down with paper and pencil or use a simple word editor.

Basic Workload Data. Now that I know exactly what I do, I can actually identify key workload data that I would like to capture. There are three things that I want to know…they never vary from process to process.

Time: What is the average time it takes to perform this process from start to finish. Every cell phone today has a stop watch, use it. Here is the very simple way that I recommend you time your process. Assign an individual that will time an individual that will perform the process. Don’t change these people until you’re done. Every day the process is performed, take three timings of the process every hour that the process is performed. Unless only one person does the process, collect timings from at least two people and a maximum of four if a lot of people perform the same process. Make sure the person timing is the same every time. This seems like a lot of work, but it really isn’t and if you don’t know the true average time it takes to do the process, you really have no idea what is happening. Add up all the timings and divide by the number of timings you have…simple average. Find someone that knows how to analyze data, preferably with Minitab, and have them analyze the data–they will provide you a great deal more information that you can use.

Volume: You need a way to collect the number of times that the process is completed. Also, you need to know by individual the number of times they performed the process if more then one person performs the process. Truly you want to know how many times the process is performed and the actual volume of the finished product that left the work center. The reason is to know how much rework occurred–in other words, they performed the process more times because of errors than the number of finished products that went out. But, for basics, you need to know how many times the process was performed or the total number of finished products from the process that went out. If you don’t know how much work you do every day, well, I really don’t know what to tell you. By combining the amount of work every day and the average time it takes to perform the process, you now know the productivity of your process. If you perform the process 1000 times in the day and it takes 1 minute to perform the process, then it takes 1000 minutes to perform that process. That’s 16.66 hours of work, which equates to just over 2 full time positions working 8 hours a day. If on Monday’s the volume doubles, then you know you need staffing that equates to about five people.

Defects: When you write down every single step in the process, you will probably run into this situation where there is an “if then” statement. If the product received is incomplete, then send it back; if the the paper printed is blank, reprint; if the expected block isn’t filled out, call so and so; etc. Normally, we just treat those things…those if thens…as part of the process. They are not. Those are “exceptions,” which are better known as defects. As you write down the steps, document these exceptions to your “clean” process and then create a way to collect the number of times that these exceptions occur. By simply looking at the totals for the various process defects over a period of time–maybe a month–you identify which ones are the most frequent. Common sense can tell you how much time each of these defects actually takes or how much impact these defects cause in your process. This gives you enough data to determine what you want to work on to improve your process. Otherwise, you might work on improving the wrong thing just because it’s easy or more glaring/visible.

Just think if everyone at the lowest level were doing this? Problems would be identified and solved at the lowest levels. Work would constantly be improved and everything would operate smoother in the work center.

Those experts in Lean and Six Sigma are there to help you analyze all this data you’ve collected around your process. They can help you build key charts to examine and analyze and they can recommend some just in time methods. If you run into a major process issue that spans multiple parts of the organization, they can develop a full blown process improvement effort and can facilitate everyone to solve the problem.

Bottom line, process improvement is simply business common sense with a fair amount of elbow grease thrown in. It’s the way you should act every day and you’ll take these basics to every job from here forward.

%d bloggers like this: