The Difference between being a manager and a leader

Friday, January 22nd, 2010

There are several key differences between being a manager and a leader. For people running their own business or acting as parts of a management structure in a larger business it is important to recognize the differences between managing and leading and use these different methods appropriately. The biggest difference between managing and leading is that managers push groups to achieve specific goals while leaders pull groups in a general direction, letting the group decide on the specific goals.

When you are managing a group you are looked at for direction and answers, you are the driving force or push behind your team. Managers are focused on individual contributions and making sure that everyone on the team is doing exactly what they need to be doing to achieve the specified goal. At critical junctures in the process the team will defer to the manager to steer them in the right direction. All major decisions are made by the manager of a team.

Leaders on the other hand let the team make their own decisions. Instead of pushing the team into specific solutions, a leader pulls the team toward the goal, letting the team figure out the best way to get there. As a leader your role is not to provide the answers but to facilitate the team in coming up with their own answers. Leaders are more concerned with the overall functioning of the team and the relations between team members then the individual tasks of each member of the team.

Clearly each of these styles has its place and it is important as a team lead to recognize when you need to manage your team and when you need to lead them. Typically as employees grow more accustomed to the business they need less management and more leading. As an employee grows comfortable with her daily tasks she no longer needs someone looking over her shoulder, however she does need someone motivating her and this is where a great leader will excel. On the other side new employees don’t need motivation and leadership as much as they need someone there telling them how to do their new job.

This is not to say that only new employees need management, or that experienced employees will always excel with great leadership. As a team lead it is up to you to figure out what the members of your team need from you, and typically this means walking a line somewhere in between managing and leading. At times it will be important to be the task master and manage the members of your team, however if you default to this mode you will stifle the creativity of your team members and will not be allowing them to achieve their best. So at time is it important to take on the role of the leader and let the team figure out the solution, again though it is important to not go too far in this direction. If left completely to their own devices employees may wind up off track or pursuing ideas that are not practical for the current situation, it is your job to step in and make sure this doesn’t happen.

I encourage you to take a look at your current management practices and skills and see where you fall, are you more of a manager or a leader, and then examine the effects this may be having on your team. Considering trying the opposite approach from how you typically interact with your team and see how they respond. It may be that some of your employees have been waiting for an opportunity to be more creative, or have needed more direction in the workplace. The important thing to remember is that, as a team lead, you need to always be monitoring your team members and tailoring your interactions with them to help them achieve their best. This is the true goal of any leader, whether she is managing or leading, she is always trying to bring out the best in those around her.

Add to Del.cio.us RSS Feed Add to Technorati Favorites Stumble It! Digg It!
    www.sajithmr.com

Technorati Tags: , , ,

Delegation Resources

Tuesday, May 26th, 2009

Earlier this month we talked about “dividing and conquering” your to-do list. The very next week I received my Mind Tools newsletter, titled “Delegate and Thrive”. The newsletter article goes into detail on the what, why, how, and when to delegate. There’s also a free downloadable Delegation Worksheet and a quick “How Well do you Delegate” quiz.

I scored a 36, which indicates I’m making progress on my delegation skills. How about you? What challenges do you face with delegation?

Add to Del.cio.us RSS Feed Add to Technorati Favorites Stumble It! Digg It!
    www.sajithmr.com

Technorati Tags: , , , , , , ,

Back to Work

Friday, May 8th, 2009

Now, after two posts on the importance of taking “time outs” for thinking and re-charging the mental batteries, it’s time to discuss the dirty habit that lies just on the other side of productive time off-task and task avoidance. Yes, I’m talking about procrastination.

According to Dr. Piers Steel, an expert in the study of procrastination, at least 95% of people procrastinate and for 15-20% of us it is a consistent problem. (http://www.procrastinus.com/)

There are many theories on the causes of procrastination, and much debate over the validity of these theories. There are even more people and companies with websites and programs offering advice on how to overcome procrastination. In fact, I was overwhelmed (and intrigued) at all the info out there. You can count on hearing more on this topic in future posts. In the meantime, I ask you, “Why (or what) do you procrastinate?“

To get the ball rolling, I’ll admit to procrastinating on getting my car serviced.

At first there was just the engine light, which was explained to me as a secondary sensor being out, and that it was not crucial to be fixed immediately. Next the brake light came on, of which I was told the brake pads need to be replaced soon, but I could get by until my next payday. The third warning was the add coolant light – which I would never ignore, although I have been able to postpone repair by periodically adding water. The final straw for me was when the display read “SERVICE!” with an accompanying high pitched beep. So now, the car is screaming at me for attention. And just yesterday, I noticed the A/C not blowing as cold as usual. Finally, I’ve made the appointment to bring my car in. The main reason I didn’t do it before was simply the inconvenience of having to arrange for alternate transportation. I am sure I’ll pay for this when it’s time to pay the service bill!

Add to Del.cio.us RSS Feed Add to Technorati Favorites Stumble It! Digg It!
    www.sajithmr.com

Technorati Tags: , ,

Eliminating Defects - Part Four

Wednesday, February 11th, 2009

OK, quick recap:  In part one we talked about definition; in part two we discussed data identification and collection, and interim containment; part three discussed identifying the root cause.  Now we’ll discuss what to do once we know the true causes of the problem.  It sounds pretty simple and straightforward, really - eliminate the root causes.  But we find out that it’s not as straightforward as it may seem….

When eliminating the true root cause, you want to ensure that you will follow the advice given to doctors — “First, do no harm”.  Implementing an effective corrective action means fixing the problem, without causing new problems.  This may involve ensuring that the fix can be implemented fully; that the fix corrects the problem; and that (here’s the tricky part) if you remove the fix, the problem comes back.  Why is this the tricky part?  Imagine this:  “Ummm, boss, I think I’ve found the cause, and so I ran a test and the defect disappeared.  Now, I’m going to remove the fix and produce bad parts again, just to be sure…”  Yah, that conversation will really happen…

So, you take your data, analysis, pilot studies, etc. and select and implement the best fix for the situation.  The ‘best fix’ may involve some other analysis, like down time, training, costs, resources, etc. to get the best fix for your organization, so remember to be aware of other factors that can impact implementation.

Once this fix is in place, monitor results to ensure that the fix worked, and that there were no adverse results.  If so, congratulations!

Add to Del.cio.us RSS Feed Add to Technorati Favorites Stumble It! Digg It!
    www.sajithmr.com

Technorati Tags: , ,

Eliminating Defects - Part Three

Tuesday, February 3rd, 2009

In part one we talked about definition; in part two we discussed data identification and collection, and interim containment; now we’ll discuss identifying the root cause.

Identifying root cause isn’t as easy as it sounds, since sometimes we confuse symptoms with cause. Here’s an example:

When you go to the doctor, you tell him/her your symptoms, and the doctor may diagnose you right there, or may run additional tests before diagnosing the problem, and recommending the solution.

The additional tests, in our case, are to narrow down the possible causes, or to validate the chosen causes, before taking action to eliminate the cause. We don’t want the doctor to treat the sore throat and fever, we want the doctor to diagnose WHY we have the sore throat/fever, and help us eliminate the cause - permanently.

So for identifying the root causes, we want to make a list of possible root causes, and then determine which causes are the reason we have the problem this time.

There are several tools to help us make this differential diagnosis – some of them include the Ishikawa or Fishbone Diagram (because of its structure) or Cause-and-Effect Diagram (because of its results); Affinity Diagram; Fault Tree Analysis; Kepner-Tregoe Problem Analysis; Process Mapping; and Failure Mode and Effects Analysis.

Each of these tools strives to take data from different sources and place them all in one place. Both the Affinity Diagram and Fishbone Diagram then ‘cluster’ the data into larger similar groups. For Affinity Diagram, the data is clustered by the team, with major topics selected based on available data. For example, if the group is trying to save time in morning routines, they may cluster events around location (bathroom, kitchen, etc.), around who does tasks (myself, myself plus family/pets, etc.) or around events (get ready, eat breakfast, exercise, etc.) based on what will give the team the best chance of identifying root cause of long morning prep time.

For Fishbone Diagram, the data is clustered around known fields. In Fishbone, for a production process we typically use the “5 M’s” – manpower, materials, methods, machinery, and measurements (and a newer, sixth, M is “mother nature”, or environment); for administration in service either the 8 P’s (Price, Promotion, People, Processes, Place / Plant, Policies, Procedures, and Product (or Service) or the 4 S’s (Surroundings, Suppliers, Systems, Skills). Each of these is structured to a) make it easy to remember the categories when a fishbone needs to be derived, and b) allow additional brainstorming of possible causes when filling in.

The benefits to each of these methods is in the details. Too often, I find that an Ishikawa diagram has been done, but the team didn’t save it for future use. Or, the diagram was done, but didn’t go into enough detail to make the tool worthwhile. For example, a major cause may be manpower… so we look at all the ways that we can have the incorrect person in the job. This would be the major cause, or first ‘bone’ on the skeleton. The minor causes might include lack of training, lack of expertise, lack of knowledge (although they all sound related, there are different sub-causes, so we list them separately)… and from there we list sub-causes, and sub-sub-causes, until we get down to the true root cause for that particular area.

Other techniques and tools may analyze each step in a process or service to determine where errors can be made (Failure Mode and Effects Analysis) or follow a process to identify areas of error (mapping, Fault Tree, etc.) The important point here is to do the root cause analysis correctly, and fully; don’t stop before you get the to true root cause.

In part four we’ll discuss what to do once you’ve determined true root causes… stay tuned!

Add to Del.cio.us RSS Feed Add to Technorati Favorites Stumble It! Digg It!
    www.sajithmr.com

Technorati Tags: , , , , , , , , , , , , , ,




Bad Behavior has blocked 86 access attempts in the last 7 days.