How do you address unproductive employees?

I just read an article by Scott Reeves at Forbes on this subject. He made a lot of salient points and the article is worth reading (click here to see article) but he missed a basic point: how do you make employees accountable?

Many employees confuse accountability with micromanagement. As Scott says in his article, micromanagement will never succeed. Employees resent micromanagement. Your team needs to understand that it is you job to produce predictable results. Your team needs to understand it is your job to get measurable status on a regular basis for all employees. Sounds like micromanagement right? Well the difference between accountability and micromanagement is in the process of getting the information and what you do with it.

Here are the signs of a micromanager:

• Ignoring pre-agreed to reporting points and asking status more frequently
• Getting mad at people for missing status
• Constantly changing working assignment
• Dictating implementation instead of requirements

You have to give people a chance to do their job in a positive environment. You need to look at problems as just things to be solved. You need to engender trust so you can get the truth when you ask for status.

Without an environment where there is accountability and trust, you will never help employees improve and you will never manage problem employees out of your organization. Every employee should know what tasks they should be doing. Every employee should know if they can go home at the end of the day or if they need to work harder. Every employee should have a schedule.

Employees should be involved in making their own schedules. Managers need to work with them where appropriate. Some employees are not experienced enough to develop schedules on their own but they should be involved in the process. Dictated dates are artificial and you will not get buy-in. You need employee buy-in to have reasonable accountability.

Once everyone has a schedule, you need to track it. At the beginning of a schedule, weekly meetings can suffice. At the end of a schedule during integration periods, daily meetings are often required. Do not expect everyone to be making their schedules on time.

From here the process of objectively identifying unproductive employees is easy. They are the ones who chronically miss their schedules.

Your number one goal should be to make them productive. Managing employees out and finding new ones to replace them is costly and it is worth some effort to try and turn them around. This requires a positive attitude on both the employee's and manager's part. If this fails, then the accountability based on real schedules will be an important piece of documentation in taking further or final steps. If it reaches this point, you need to follow your company?s policies carefully.

More later ...

How do you develop predictable schedules?

Let's go back to basics. I believe predictability is the main reason to have schedules in the first place (see my earlier post on schedules). The only way to get predictable schedules is to pick good tasks. So how do you pick good tasks?

Here are the basics on how to do it:

• Pick tasks of reasonable size (10 days maximum)
• Make sure the result is measurable
• Legitimize design time, test development time, integration time, etc.

If the duration for your tasks are too long, then you will not know your task is running late until it is too late. Slips in long tasks cause slips in releases. The only way to mitigate this risk is creating smaller tasks. This may require more scaffolding to test intermediate results. It may require longer schedules. If your goal is predictability, you need to tell your team that predictability is a priority for you and it is ok to identify shorter tasks, even if it results in a longer schedule. Longer schedules alone will not provide predictability. You need smaller deliverables.

Each task should have a measurable deliverable. Without a measurable deliverable, the schedule and the task are meaningless with respect to predictability. It is easy to create a task whose description is "Coded new APIs" but at the end what do you have? All you have is that code. Does it tell you that you are finished? Does it tell you it works? What if someone finishes the coding but it takes twice as long to get working? Identifying a separate integration phase does not help either because you cannot tell how far along you are. Instead I suggest a task description like "coded, developed tests, code reviewed and checked in 5 APIs". If the original goal had 15 APIs, then I would create three of these tasks (or whatever fits in 10 days). This sends a clear message that the task isn't done until it includes all of its pieces and is measured.

Finally, make sure that tasks include explicit time for design, code review, etc. It is easy to either slip because of these items or worse skip them. They are not the most fun tasks for engineers, so make them count. Without these items, it is easy to slip a schedule late in the game because of a lapse in up-front hygiene.

This is hard and your teams will need both practice and help to succeed, but it will payoff in success and rewards.

More later ...