Overqualified Employee is an Asset, don’t lose him

There is a very nice article Overqualified Employee: A Liability Or An Asset? on Rozee. One point I totally agree with and thought I should post it on my blog. Here is its excerpt…

How To Deal With An Overqualified Employee?


Utilize His Expertise

If you have an overqualified employee on the team be sure to utilize his experience rather than feeling threatened by it. His expertise is a valuable asset for you and you can utilize it for the progress of your company.

If you don’t utilize his expertise then he will not be motivated. As author of the article has mentioned here…

Downside Of Hiring An Overqualified Employee:

Lack Of Motivation

… the work will not be challenging enough for him and he will get bored quickly, loosing focus and motivation. When an employee loses focus he instantly starts looking for another job and thus becomes a flight risk.

How to improve quality of your quality standard?

Having quality standards for your organization and project is a must. But putting everything in your quality standard can make your quality standard worse. There are few guidelines you can consider when making a quality standard, but following two are most important I think.

  • Develop a consequence for each quality standard. I like to call this the “Who cares?” test. For each standard you identify, develop a logical, thoughtful consequence that will occur if it is not met. If you and your advisory board can’t identify a realistic outcome, or if the consequence is minor, consider revising or deleting the standard. It’s too easy to throw everything into your quality standards list. More is not always better, so be sure to focus on what matters most.
  • Evaluate the quality standards as a regular part of your project postmortem. Putting practical standards in place is a great first step toward meeting the expectations. So, to ensure that your quality standards continue to pay dividends, it’s important to include a regular postmortem review. Ask questions such as:
    • Were any quality standards ignored? If so, was the consequence significant?
    • Was the product designed with the quality standards in mind, or were they applied after the product was designed and needed to be tested?
    • Did the team take the quality standards seriously, or did they follow the guidelines because they had to?
  • Getting a good read on how project teams viewed the quality standards will help you improve these measures, and over time they will evolve with your organization.
  • There is a good article on Microsoft Office Online providing bit more guidelines on developing a good quality standard and then maintaining the quality of your quality standard 🙂

    How change can bring motivation?

    I always believed that bringing change is one of the key factors which develops people’s interest and keep them motivated. But I was surprised to see that how promoting another person in team can motivate others, specially where situation is worse and people are fed up. Bringing change can charge people up, but we have to see that what type of change is necessary. Sometimes a change can demoralize people, specially when people are already happy with something.

    Another factor to keep your team motivated is to communicate with them and ask their problems, and try to solve it. Again, solving problem will bring change and your team will become more responsible, honest, and motivated.

    Hidden Reasons for slipping project deadlines

    There can be so many factors that affects the deadline and project can be delayed. There is an excellent article 10 ways to get a slipping project back on track on TechRepublic explaining the remedies. But in my opinion tips given by the author are where there are already processes defined and a proper organizational hierarchy is maintained, not just maintained but also everyone at its position has its role and responsibilities defined and he works according to his role. At least to some extent. But what when this is not the situation? Let me explain here by first commenting on the TechRepublic post.

    Overtime was on the top in that post. Author has already accepted that this is an option when you are at the end of the project, and there are better strategies if you are in early stages of project. I agree with that. You cannot work overtime for a long period. Few overtimes are acceptable. I just wanted to mention this here.

    Few other reasons of slipping the project deadline is setting the deadlines blindly, assuming ideal situation and not keeping the buffer, specially when there is a learning curve when you are working on something new.

    Another problem is that if there are lots of senior guys and everyone is imposing his own decisions discarding other’s. Having senior guys is good but everyone should have separate responsibilities and no one should interfere with other. Discussing matters, coordination, and giving opinion is something else. Not having this leads to unstability.

    Another major big problem is with the management when talking in terms of investment. Besides company’s plans few things are obvious where anyone can see that investment has been done at wrong place or investment is not done where it was supposed to be. Like hiring skilled people and paying them good. Finding cheap human resource does not always work. You should know when you have to invest in human resource and when not. And if you already have good human resource then appraise them before you loose a good resource and someone else steals it from you. Keep in mind as long an employee works for a company, he becomes more valuable asset since he has learned so many things and new employee will take time to learn those things. If you can understand this then you already know that time is money. And if employee leaves in the middle of a project, then obviously there is a big chance of slipping the deadline. You have to put extra resource, reschedule accordingly, assign resource etc etc.

    Another one is related to human resource and team. One should have experts and should have responsibilities and roles defined. Don’t expect one to do everything from project management, to design and architecting, to learning, to implementation, to support. Project Manager is one guy, System Architect is another, Developer is another, Designer is another, Tester is another, Network or System Admin is another (sometimes two), and Support personal is one another. If you don’t have enough money to hire all these people then don’t jump into the big business, otherwise you will fail. Start with small and gradually build your team. This is a long term investment.

    Besides human resource, other resources are also important, including facilities. Not providing sufficient resources to the team wastes time and at the end deadlines are slipped. Employees also get frustrated. Even a very small resource or facility has its effect. Not upgrading systems, network issues, not providing healthy environment, and even not having standards and policies are the reasons. Having flexibility is something else and not having proper company policies is something else. Not having these demotivates employees and one cannot give his 100% then.

    One another important thing is forecasting and future planning. If you don’t have the plan and has approach like we’ll see when that will happen, then don’t be surprised if you fail to accomplish your goals.

    When working on projects you should have dedicated resources, not the ones that come on and off. I am typically talking about human resources here. Since working on project and to complete it in time needs concentration and focus. There can be resources who come on and off but don’t assign them critical tasks. Use them for assistance only.

    Processes! Just having separate development and testing teams doesn’t mean you are following processes. There are processes for within individual teams as well. If processes are not defined then this is also a reason for not meeting the deadlines.

    Besides all this I also recommend reading Peter Steven’s blog post 10 Ways to Save a Slipping Project.