Thursday, August 9, 2007

How to reprimand an employee



I know, but sometimes you have to criticize in order to make sure that the direct report gets the message and the problem does not occur in the future. I had problems with this early on and by speaking to people, I understand that this is a common problem. Refer to my earlier post on the One minute manager, one minute reprimands are part of the process.

According to the Wall Street Journal, here are 5 ways that you could do that.


  1. Examine your intentions. Before you sit down with the person, assess your own state of mind. Has his blunder left you feeling angry or betrayed? Do you feel compelled to get back at him? If so, take the time to cool down before you speak to him, otherwise your critique may be too emotionally charged to be effective.
  2. Pick your moment. If a problem arises that's likely to have an immediate impact on staff morale or the performance of the company, it's important to address the issue within 48 hours, Kohn and O'Connell caution. But remember, handling the problem expeditiously is no excuse to lose your head, so stay calm and try not to be reactive. Hint: Always deliver your criticisms in private to minimize emotional fallout.
  3. Pay attention. There may be more going on behind the scenes than you know. Rather than assume the mistake was the result of carelessness or laziness, try to put yourself in the other person's shoes. Was this problem the result of miscommunication? Is your employee overburdened? Or is he the victim of inexperience or office politics? Use this meeting as an opportunity to perform due diligence.
  4. Use the "sandwich technique." When delivering a critique, it's important to censure the behavior, not the individual. One of the easiest ways to encourage receptivity is to preface your criticism with a positive statement about the person's job performance or character. Once you've fortified his ego, deliver the bad news. Ensure that he received the message, and knows how to correct the situation. Then close the conversation with an affirmation.
  5. Prepare yourself for defensiveness. Even the most artfully delivered criticism is likely to elicit negative emotions, so steel yourself for the inevitable. Always try to focus on the end result rather than the immediate reaction.



I think thats well said, but I would add another, which I think is very important.
  • Sleep over it. There are many times when by just taking a break, getting a cup of coffee or just addressing the problem the next day, situations become easier to handle. Either the situation has solved itself or you see the situation more clearly.
And remember, the reason for the criticism should be constructive and never personal.

Thursday, July 26, 2007

Book: The one minute manager

I just read the book, the One minute manager by Ken Blanchard. I was pleasantly surprised by how simple it was and how it applies most areas of management. Normally as a manager, you could spend your time making plans, reviewing schedules and preventing problems. At least in IT, the problem with programming becoming managers is the lack of soft skills. I would recommend this book to anyone looking for an easy and clean 3-step process to become a better a manager. Soft skills are extremely important and as the PMI says a PM spends 55-60% time in communications, that is quite a lot.

So lets break it down
  1. One minute goal setting: Set a goal that the direct reports know what is expected and what they are aspiring to get done
  2. One minute praising: If you see something you like, praise it right away. I have personally seen that praisings given in public help a lot
  3. One minute reprimands: Again, if you see something that you do not like, reprimand, pause for a couple of seconds, and then explain why. Close with mentioning that this is not personal and its because the person in question has done such good work in the past but this time she/he slipped.

Another point was that there is close contact with new direct-reports, but the contact becomes less as time goes on since the direct reports become independent but they know whats expected of them. And of course "one minute" is a metaphor for a short period of time.

One point to note is how relevant this book is even now, considering that it was published in 1982!! I guess this goes to show that the longer a book is in circulation, there is a good chance that it might be good.

Recommendation: Do read!

Monday, July 16, 2007

Empathy in project management

Empathy - Identification with and understanding of another's situation, feelings, and motives according to Answers.com

I have worked in companies before as a software engineer where I have failed to see that from my PM. Upper management too sometimes just looks at the bottom line and statistics when dealing with projects.

I feel that as a PM you need to empathize with your team members and people you work with. Look for clues, look for hidden expressions, read body language, coz sometime what you hear is not the way it is.

For example, in a meeting I had once an engineer who was working on a hard aspect of the system. This feature was fairly complicated and quick foundational, so as PM of course I was all ears. But other team members were not, I had made it an option in extended meetings that if the topic does not pertain to you, you may walk out and go and do your work. In this meeting, as usual, a couple of people did just that. I noticed the expression on the engineers face as this happened. As the meeting ended, I told him that he was doing a great job and I liked what he was working as the solution showed itself. He said, thanks, and he felt that he did not feel that way.

Later on, I went to his office and spoke to him alone, telling him again that his work was good and he should keep going. He mentioned that he appreciated my gesture and was going through some personal problems. He was in fact thinking about filing bankruptcy. He went on to say a few more words, not giving details but enough to communicate that he had a few personal problems. I sat there and listened and hopefully nodded at all the right moments. I feel that he was feeling better at the end of the short talk that he could talk to someone.

This is what empathy is about, caring about the project primarily, but also caring about the people doing the work.

Thursday, July 12, 2007

Be a fly on the wall

Sometimes in project management, you want to contribute, make things easy for your team. Some members on your team might find it useful, some might not. Most times, I have seen, PM go overboard and this leads to micro management and too much meddling.

Here is a solution, sometimes, be a fly on the wall. Hover around, see whats happening. Even in meetings, you know that you don't know everything. Let people talk, let them argue over items that concerns them. This will let you discern their interest in the project and also make you aware of the progress within the project.

Remember though, as a PM, its your responsibility or your duty to know as much as possible. Prevent rather than repair problems. Information is really extremely important.

Thursday, June 28, 2007

Why projects fail

I have been on a few failed projects and a few successful projects. A project fails because of many reasons. The reason for this post is because I have been letting this blog slide and I hope to be more regular. Also there is an excellent presentation by the people at Head First. I loved the line "Don't go in the basement" as it happens in horror movies. Seriously, people still do go to the basement. These guys have a nice sense of humor.

If any of the projects that you worked on has not failed, stop right now and leave. There is no reason to spoil a good thing.

The four ways that the presentation mentions is
  • Things the boss does
  • Things the software does (or doesn’t do)
  • Things the team should’ve done
  • Things that could have been caught
According to me there are a couple more
  • The project did not get enough support or did not get the right team - there are times that a project is created because the boss makes a bad call, and that is mentioned in the first reason, but my explanation is, sometimes a project is designed because of market pressure or "We gotta do something". Lackluster support is given, company weight is not put behind product and sales and marketing is flat. This is one where there is an A-Rod and a Jeter but the rest of the team is not that good or on the same page. The whole team (those involved) has to be behind the project 100%
  • Project Attrition - Many key members leave the project. This is self explanatory.
What can you do? Review, check, recheck, gut check, progress check, status check, mood check, attitude check. Watch people in the team, there will be signals and notice if the level of communication steadily tapers off, this is a warning sign.

Tuesday, June 26, 2007

A recipe for success?

I found this blog while surfing around, have not had time to look at the blog in detail or do not know anything about the author (david anderson) but I loved the recipe for success

Recipe for Success: Focus on Quality, Reduce Work-in-Progress, Balance Capacity against Demand, Prioritize

I think that this works very well. Nicely put.
http://haloscan.com/tb/agileman/Recipe_For_Success
http://www.agilemanagement.net/Articles/Weblog/RecipeForSuccess.html

http://blogs.msdn.com/jmeier/archive/2007/03/11/david-anderson-s-recipe-for-success.aspx
Here is a commentary and interpretation on the above recipe for success.


Wednesday, June 13, 2007

Good new

I have passed the PMP. More to come later