Showing posts with label success. Show all posts
Showing posts with label success. Show all posts

Wednesday, 1 September 2010

Appraisal and Performance Criteria


I must have got at least a few stares and a few comments from friends that the post around How to handle Bad Appraisal was a employer perspective and very little thought was given for how one feels like when the appraisal goes wrong.

I felt it was not a employer perspective, instead it was a perspective on how one should cope up with such situation no matter what you are employee or employer... anyways, since I deal with development Teams more closely .. I also got a question that said that usually the Key Result areas or the performance evaluation critieria's are not made very clear, bench marks are not set , there are no clear definition of success and fail parameters and thus when it comes to appraisal time the developer / engineer thinks that he was the best and did the best and the Manager thinks that there was good work done, but there are a lot of things that did not go well.... So here I thought I would put together a few questions that can be used as indicators to one's performance . These questions would help define cleared goals and/or also in turn help a better appraisal process....

1. Attitude

Q. How does he/she perceive his/her job?
Q. How does he/she perceives he/she role in the Team?
Q. Do he/she stand by the Team, helping them on issues and small troubles?
Q. Do he/she needs to be called for help? or he/she walks by to help others?
Q. How does he/she take change?
Q. How does he/she work in absurd condition? tight deadline and power outages or urgent work needed to be solved but machine is slow, or long hours and so on.
Q. For a failed commitment how does he/she react? Blame on others, things, accepting mistakes, or retrospecting to improve?

2. Understanding

Q. How well does he/she understand the requirement and makes other understand it?
Q. How well does he/she adapt to the project and helps other adapt?
Q. How much of self time is spent on exploring the requirements?
Q. How much of value does he/she add to the Project?
Q. How many challenges or questions are raised by he/she
Q. How much depth is the understanding? like a high level feature understanding or a detailed scope?

3. Communication

Q. How does he/she communicate with the Teams.
Q. How frequently does he/she update about the actual progress to others?
Q. How much time is spent by him/her on the interactions related to project tasks with the Team?
Q. How well the person says YES or NO?
Q. How well does he/she explain the reason to those YES and NO

4. Reaction

Q. How does he/she react to a changed requirement at the last moment?
Q. How does he/she reacts when he/she is not center of attraction?
Q. How does he/she react to immediate and drastic change?
Q. How does he/she react to negative changes?
Q. How much of cribbing, whining, crying does he/she get past a task he/she is not supposed to do?

5. Skills

Q. How fast does he/she do his/her work?
Q. Are the core competencies utilized best?
Q. what are his/her best skills? Does he/she improvise on them?
Q. Does he/she document what and how he/she is going to do the task?
Q. Does he/she demonstrate frequent and consistent improvement?
Q. Does he/she actually do things instead of just talking about them?



6. Quality

Q. Is the quality of work done good?
Q. How many iterations happen when he/she does some work like estimation? Plans etc?
Q. How many bugs are created on the work done by him/her?
Q. How much of re-engineering and rework has been done on the task done by him/her?
Q. How much self initiatives are driven by him/her in improving the quality of the product?
Q. How many bugs are caught during the testing, by the customers, by him/her self?

7. Organization

Q. How does he/she manager his/her time?
Q. is he/she planned and organized?
Q. How is his/her desk kept? clean, dirty?
Q. How well does he/she plan the meetings and other times?
Q. Are the estimates given by him/her met? if not why?

8. Ownership
Q. Does he/she care about the module and takes he/she is doing?
Q. Do he/she take responsibility and show authority on his/her task?
Q. Is he/she passionate about what they are doing?


Well these are just those few questions that you as a Manager needs to ask yourself when you are putting someone on a performance appraisal. Pull these questions, customize it to your Team and let them answer these for themselves.. Your development Team's may get the best answers for themselves... Keep a lot of scope for project or release driven retrospectives as they are the best indicators of how one did...

In the end remember this is just one way to know what improvements you need to pull over for your Team instead of having a discussion "I did everything you asked me for, now why is it a bad appraisal?" or "You did OK , but not great"



Friday, 25 December 2009

Be Capable, Success will follow - Raju Hirani in 3 Idiots



Second time in the row I saw this movie today 3 IDIOTS a bollywood masala movie from the maker of Munnabhai MBBS and Lage Raho Munnabhai, Raju Hirani, from the producer of 1942 a Love story , MunnaBhai series, based on Chetan Bhagat's 5 point someone and with the lead played by Aamir Khan. This movie really entertains, its a block buster but also leaves us with some questions that needs some serious thoughts. Leaving the entertainment side, Hirani definitely gives us back a lot of lessons to learn from...

1. Success doesn't mean Money
2. Learn your lessons well
3. Attitude is needed, A Good one definitely
4. Teachers need to learn first
5. Do what is your passion
6. Be Capable first, Success follows ability


To give you a gist the movie is about 3 students and their life in an engineering college, based on facts events, mentors , attitudes, approach on life.. it ends up with the lead who guides and takes life innovative way, brings on change with his Iris attitude. He goes missing and I will leave the plot to be explored by you. I liked the dialogues and each of them are hitting my minds since last 2 days... here I write about them...

1. Success doesn't mean How much Money you make or what designation you hold.
A few years ago, a talented Engineer in his early career left the Team I lead. He came to me and said "I need a promotion, I am OK with my Role in the company, Team and my salary."
I asked "All of a sudden, whats in your mind?"
he said "All my friends now are Team Leads and Managers, they earn 5 figures, its time for me to grow. I also think that my peer is my bigger competitor here and I can go out and grow more than him or my friends"
I said "Do you want to grow because your friends have? Or you want to grow because you think you deserve it?"
He said "I am getting old now, I think I deserve to grow"
I said "So You want a jazzy designation to impress your friends? Or you think the jazzy designation would be justified by what you do?"
..... The guy left us, A few years later the guy got in touch with me and said.. "maybe I should have taken the role when I was ready, I think I screwed up a lot of projects because of inexperience and abilities"

In Summary : If we make more money from our jobs or have bigger designations doesn't makes us more successful than others.. eventually it is what we do and what we turn around that makes us more successful. Early Feb I wrote this about success.. worth read to connect

2. Learn your lessons well
We learn our lessons, but do we learn it well? So you would ask me what does this mean!!!! A couple of years ago a Software Company made a disaster of their product. They Outsourced the product development, not enough analysis done on the requirements, technologies, no efforts on process, no definition on what to achieve, No stakeholders defined, no ownership taken, The Team had an attitude of money buys service and who gets money has to do things. They failed miserably, The outsourcing partner did not understand what to do and how and they took the company in ditch. The company recovered.. formed its own team, got a new product done to begin, got the foundation of a great product ready. They learnt their lessons and they got well out of it. Eventually when they progressed to newer development they hired 100 people in a month to do the rest of the development.. another disaster in way!!! if you had learnt your lesson well you would have Built the Team not formed.


3. Attitude, Have one a Good One
We always talk about it in our blogs.. so I dont elaborate much now... but its very important that you have an attitude that leads you to be capable of doing things...

Attitude, is what keeps us going. Attitude is what reveals our characters... Attitude is what is required... You have one is the basic necessity. And when you have one, dont leave it..



4. Books are friends and teachers, Do all friends guide well? Also Teachers need to learn first.

Well they definitely need to. I think we as mentors, Guidance sources, advisers and drivers to our Teams also need to learn TEACHING first. Not only our educating systems needs to be changed, but also the way we teach. When I say education system I refer not only on how we teach our kids, but also our employees, teams and members of organizations... This movie has a character called "Silencer", the guy who believes that he can dump the book in mind without understanding what it means... but its not his fault, because the examination he writes or the questions he answers to the interviewers or professors is based on what books teach.

In one of my previous companies we had a SQA (Software Quality Division), this department would audit and evaluate all the projects done by the company, define flaws , recommend suggestions to improve the quality process. However the members who were a part of this had a bible book in front of them to refer to it... and when they did not find something in the book, it meant the project did bad on quality ;)... In one instance our product involved a short term (1 day) project. The requirements were one liners as the customer needed it very very urgently. But since it was not a bug, nor a change request nor a full feature we did not have SRS and other documents for it... result? SQA recommended not to go ahead with the project, result????? wanna guess????

I have also seen that many of us dedicatedly believe in what text books says.. for instance principles of Agile... Ask a Developer who involves himself in Agile, he would know that demo and integration of feature, code and qa is an ongoing process. Nothing is complete. Ask a Text Book Agilist He would want a document, a start and end of the feature and time lines... Books are our friends (Not all friends give perfect guidance)

5. Do what is your passion
If you are passionate about doing something, then do it. Dont do something that you are not passionate about. But remember lean your passion in a way that you still have a day Job. Passion is needed in what you do, but it cannot be converted in what you are doing. Passion is the part of your character, that tells how much of your character actually exists.

6. Be Capable first, Success follows ability


If you are passionate and capable... Success will follow. Google did not start big... it grew, it followed its path, showed its capability, success could not hide long, it followed. Gandhiji took his abilities and followed a path, success (Independence) came along. If you are running behind success then you are ruining those abilities of you that you can definitely succeed with. If 1M Unique readers is your blogs goal, and if you focus only on SEO, promotion and marketing... without putting the actual writeups (ability of your blog to get readers) you will not succeed, you may see short term benefits not success.

Pele the football God once said "When I step on ground, I just want to play good football, Wins and Goals come along when playing the best football"
A Painter puts all his imagination in his paintings... he doesnt know when he starts on what he wants to get out of it... but when he puts all his efforts without thinking of results he creates a "Mona Lisa"....

As the Hindu Grantha of Bhagvada Geeta says "Do your Karma, Dont think of fruits, they will come with your karmas"

Tuesday, 22 December 2009

Successful Manager : How not to messup Delegating

Do you delegate? Do you believe in delegation? Do you just delegate or you are involved? Are you a chicken or pig in our story? Well all these questions sometime shine in your minds, rest of the times you ask yourself. If not more, some of your seniors bring this to you when you start taking more and more responsibilities. In our step towards finding the orgasms of Management we explore this vital skill we call “Delegation”.

When we as Managers decide to trust others with appropriate responsibility and authority so they can achieve the set of tasks designed that were meant for us, we call it Delegation. But do we use and misuse delegation? Yes we do, don’t we? A long time ex-colleague got me on gtalk today and told me how much he is enjoying his new BDM role... with a flavoured cream on top he added this statement “I don’t have to do all the rubbish, I just delegate the rubbish to others so I can do better things”.
I asked back “what do you earn?”
he said “Experience and challenges at the cost of my work getting done by others in time”
I asked “What do you loose?”
I got no answer.... So the point here is we as managers believe in delegation, and yes we have to.. Delegation is an art through which we groom our future, we prepare our subordinates to take up tasks that we do, thus add value to their growth. We move over those tasks of us that we can easily do, to be done by others for reasons like “Time” , “More work” , “Building the next level” etc etc. But do we really use Delegation effectively? I think Yes, I think No.... meaning sometimes Yes and sometimes No... So here we put down some tips on delegation, better of how to handle Delegation..

1. Identify what to delegate
It’s very important that we know what we need to delegate. Many of us really really don’t know. For instance everything that we take to one of my fellow colleagues he wants to do it, all by himself. His answer on any task would be “I will do it” in return he loads up himself with a piled set of tasks that he cannot do all by himself. I always use a dinner course technique when deciding what to delegate... as in When you get a plate full of food, all the food that you love... what do you do? You pick the best of things that you love and that too in certain limits... You don’t have only ice cream for dinner.. so when you have tasks to do... go by the dinner menu technique.. pick your items you want to have and pick the items that you want others to have... pick the quantity correctly so that you don’t have to loosen your belts when you are done ;)

2. Who benefits?
Yes you do. But who else? Ideally we think of benefits for us when we delegate... like I delegate the task so I can go home early. Or I delegate the task so I can do something more important. I think when you choose items you want to delegate you should also think of benefits of the delegation. A more simplistic view is when you delegate tasks that are second line that you are doing and that can help:
1. Get someone else too able to take care of in your absence
2. Prepare the person to the next level
Benefits that the person doing it will derive from it have to be explained better, This will ensure that the benefits of delegation have multi routed outputs. Thus increasing possibilities of the task succeeding.

3. Identify the person
If this fails the whole delegation model fails. The person who the task needs to be delegates needs to be picked up well. For instance you cannot pick up a Jr. Developer to do a Code review for you if you are an architect, it may be good for him but in the end a disaster for all. Imagine having a Air hostess getting control of a Airbus 380, even if the pilot thinks autopilot works? Or imagine the pilot turning the mode of the plane to autopilot when in a stormy situation? Yes the person doing it has to be chosen. Keep the following things in mind when you choose:
1. Is he ready to do it.
2. Is he capable of doing it.
3. How much of time he needs from you to do it? Do you have time to give him?
4. What happens if he fails?
5. What happens next if he succeeds? Do you have expectations to be managed?
6. Will the person do this without having to move out of what is hi core interest?

4. Understanding
Its very important that you as a delegator explains the delegated task very well to the person who is going to take it up. There has to be a very clear understanding on :
1. What needs to be done.
2. What are the ways to do it
3. Who , How , When to contact for what
4. Success and failure criteria.
5. Process and guidelines.
6. Expectation from you in terms of results and steps in results.
7. Final output

5. Time, Support and Help
You can’t just delegate a task and vanish. Delegation brings more and more responsibilities... Once you delegate you have to follow up with the person (Not to micro Manage) but to ensure that the required help and support is seek. Ensure that you give enough time to the person to understand and get adapted to the task. Follow up so the person seeks required help and support from all sectors that involves his/her task. Facilitate whatever possible to let the person get a good control and fall into the correct and positive rhythm. Ensure that required authorities and responsibilities are listed to the member. If its a checklist its well and good. Imagine a security guard asked to protect a premise not having access to the premise? Remember even if the person doing the task is responsible for it, you as a delegator is the accountable authority for it.

6. Review , Evaluate , Feed it back.
Yes.. Frequently review it, evaluate the status, provide guidelines and feedback appropriately. It cannot be worse than not reviewing a delegated task. This can break the moral of the person doing it because he/she may think that it is less important and thats why it is delegated, also the task will loose its own importance.

7. You don’t need to be a Manager to delegate, You don’t need to delegate things to others
Yes. You necessarily not be a manager. Imagine a part of the code you are supposed to work is also being worked by someone else... you can delegate a part of your task to your colleague. Imagine you have to go pay bill for your phone and your friend is going out to do something, can it save some time for you? The other side of delegation is you don’t need to just delegate things to others...you can delegate it to yourself.

8. Prepare a checklist
Always. When you delegate a task, make sure you have your own checklist to follow up. It would be good to create a checklist for the person who is doing it. This helps in clear definitions of things to do.

9. Credit reasonably
A lot of times leads and managers think that delegation is a easy way to succeed. They get someone else do the task and prefer claiming the credit for it. This creates a very bad culture and over and over gives a broken moral to the team. Ensure that the credit is given to the people who are doing it. Leadership is on how best you get it done, leaving others to learn from things and at the same time letting then have their share of cake they deserve.

10. Failures
Before delegating analyse the risk and consequences of failures. You may not want to delegate a task that will involve a huge deal that can change the future of your company. If you are the best person to work on, DO IT. Seek help and manage delegation in doing it. Define the failure items , potentials and criteria so the person doing it knows what NOT TO DO and avoid. Also be supportive if a delegated task fails.. this can else turn a disaster.

11. Be Reasonable
Amit a day ago gave me an example on how his lead would give a task to him without his knowledge of how and what to do, and also giving an estimate that is unreasonable, forcing him to do it. Finally when it came to review and seeking responsibility how his lead would not turn up. This shows that you maturity level is low and you need to grow up to give a reasonable time to everyone you delegate the tasks because they are not as experts as you are.

Saturday, 28 July 2007

Commodity Leadership

While I dont intend to discuss the Harry Potter and the Deathly hallows secrets by any chance on this blog I am forced to write about something that is a part and parcel of todays fast moving business world. One of the reason why Professor Dumbledore could not succeed to be a Master Of Death or rather be the most powerful Harry Potter character is that he was a Commodity Leader, This was revealed and discussed in the last few chapters of the Harry Potter and the Deathly Hallows.

So for the readers and the feeders of this post who will definately ask what exactly does it mean by Commodity Leader.. here is the answer for you:

1. A Leader who wants to achieve some goals or keep on achieving goals for himself is a commodity leader

2. A commodity Leader only thinks about saving ways to own success, this is revealed by the insecurity and subsequent defensive acts done.. Guess why Lord Voldermort is a commodity Leader?

3. The difference between the leader and the commodity leader is Secrets... Harry Potter never kept secrets , Dumbledore and Voldermort did, like I said its revealed by the insecurity the fear of failing or the fear of getting overtaken by another strong competitor creates this issue.

4. A commodity Leader reacts, A leader goes for it with the Team ofcourse, So when Voldermort knew about the passage of Harry from Dudseley's to the Order safe zone or to that matter the whole of the journey of Harry to the Godric's hallows all through Voldermort did was reacted, when it came to the end Harry was not afraid to go for Voldermort in the abandonned forests to fetch Voldermort. Similarly an attack on a commodity leader turns into reaction very soon some way or the other.

5. A commodity leader prefers favourisms, No wonder Dumbledore or Voldermort or to that matter Thicknesse? everyone had there own sets of reservations as far as favoursisms are considered. Dumbledore to Harry, Voldermort to Luious Malfouy Or Snape to Draco and so on... the favoured may or may not be capable.

6. A commodity leader understands critisims as complains and empowerment as delegation

7. A commodity leader is selfish and the play is for glory..

8. Praises and curses matter to the commodity leaders, they cant sustain curses and they can't stay without praises which makes a world difficult for them for long since praises comes with curses.

9. Commodity leaders find wrong in anything that is not them, While The Elder Wand was a key to success did Voldermort really trust Snape? Or Did Dumbledore trust anyone else for the Magical limits ever?

While the commodity leader continues to be a leader and tries to enchant the growth of the organisations one of the cause of failures of early startups is commodity leadership. The ways to get out of commodity leadership is essential but while we think about the ways to thin about practical leadership lets decide on what House of leadership we would like to go? Choose the house than letting others choose whether you want to be a leader or not... let the magical wand choose what type of leader you are...

Friday, 2 February 2007

Success is in ????????????

The more of a Manager we be the more we loose on the leadership front… this I have noticed over a period of time while Project Managing…. While I think about all this I realize that this really has nothing to do with Manager or being a leader but rather with everyone be it a developer or QA or Manager… I think success is a radish that everyone really wants to achieve and for that they do anything and everything… I thought I would put up some points that can tell you where we fail in defining success:

Success is in:

1. Empowering the team to handle their tasks but not driving them to solutions….
2. Involving the Team into decision making and not defining what they have to do to achieve a solution…
3. Meeting as a Team to discuss problems and solutions not just taking it away…
4. Responding to queries and exploring solutions rather than waiting for them
5. Being Yourself rather than pretending to be someone else
6. Sharing the experience with everyone and not keeping things within fearing that everyone will be what you are….
7. Listening to what others want to say rather than pretending to know you know everything
8. Telling what you know and exploring the options within but not defining it to be the ultimate solution
9. Reflecting rather than being Opaque… so that other's can have a space to expand
10. Prompting rather than commanding so that everyone gets help wherever required… and still can balance themselves
11. Suggesting rather than dictating so that you learn what is in store with others
12. Connecting rather than isolating…. Like …How good it will be to involve the Developer while we discuss the requirement changes with the BA
13. Digging it rather than wrapping it with some make ups…. Like do you think that there is more of a problem in the solution?
14. Encouraging rather than hiding the credits… Like… This is something that was a problem since long… I am sure this solution will be liked by everyone
15. Focusing rather than deviating…. Like we discuss about all the issues in the company when doing a personal appraisal…
16. Being specific than generalizing like "Saket missed the bug which is causing the broken application" … rather than saying "QA missed the bug or dev did a faulty code to screw the app on a whole" (Sorry Saket that was just an example)
17. Marshalling rather than getting driven …. Like Agreed that this is a problem but for now our objective is to resolve XXX problem… lets come back to this when we have resolved it.
18. Challenging than accepting everything like "do you think that's the ultimate solution?"
19. Reading it to the bottom not just the heading