Key Qualities of Objectives
Good objectives will have the qualities listed below, all of which are designed to... Click here.

OK, so maybe that's three answers, but you do need to give a rounded picture. In fact, you should also think of technical and nontechnical dimensions to the objectives as well. We all tend to focus on rapidly evolving technical skills, but personal and character issues might need to be addressed, too.

A job plan is designed to get the best value from your staff by ensuring that they are well-equipped for their current assignment and to prepare for their next one. Using that as our basic requirement, let's look at the process for defining a set of good objectives.

The most obvious source of objectives is the job at hand. At least some of the objectives of each team member must be aligned with the objectives of the team. That's usually going to mean the delivery of new, updated, or fixed software or components. Those kinds of objectives are relatively obvious, so that a technical lead might have an objective to deliver a scalable, technical, Web-based architecture for the business system.

You may also ask your people take on responsibilities outside of code cutting. For example, you might ask one of your team to define and promote a new development process, or to set up a quality forum. Such a scheme can be difficult to include in a general performance assessment, so the objectives section of a job plan can be useful for giving credit where credit is due.

Remember that any objectives must be measurable, which can be quite difficult for the more nebulous tasks. That means you have to agree on some kind of deliverable. If you've asked someone to do a comparative study on Web development environments, define the form of the expected result at the time the objective is set. You might specify that the result is a report discussing the pros and cons of each product, with a general recommendation. That provides something concrete to analyze, and you might want to add a deadline as well.

Career Development
Some people just want to be programmers for the rest of their lives. I recently bumped into someone I hadn't seen since university days. Her daughter is now in the same class as my daughter, and we started chatting about work. I commented that I rarely do any programming, with most of my time spent on communication, management, and other overhead activities. She replied that her company is always pushing her into marketing as she's considered too old to be a programmer, but that's what she wants to do—program.

This is an example of how many companies assume that technical jobs are for recent graduates, and that as you get older you should become more interested in "serious" things like management or marketing. Curiously enough, other engineering disciplines don't seem to inflict this on themselves, creating special honors for their best and brightest. While I'm not suggesting every company follows Apple Computer's example by creating a Fellow program, you do need to be sensitive to your team members' long-term objectives.

Typically as part of your job plan you should discuss what that employee would like to be doing in one or two years' time. Do they want to be a manager, a technical guru, or are they happy plugging on as they are? Whatever they feel, you need to help plan their path to these future roles. If, for example, some poor misguided soul wishes to become a manager, you might set her an objective of successfully leading a team. That could be a good learning experience, including the discovery of whether she likes taking that kind of role.

Note that I say successfully lead a team. We need some means of making the objective meaningful and measurable. Even here we have to agree what successful means—perhaps on-time delivery of working software, or perhaps quality of planning and communication skills. Make sure the objectives are precise, measurable, and meaningful.

The desire to become more expert in some area can similarly be planned. Someone may want to move from programming to architectural design, where objectives can be clearly defined around the development of skills in architectural definition. However, if someone is happy to just plough on as ever, you have to be more creative. Apart from anything else you'll need to check that they realize that their remuneration is also likely to be static.

Continuous Learning
Too many people seem to think that investment in training will just lead staff to move on to new jobs. I'm sure this started out as a joke, but too many skinflint, humorless managers took it straight. I'd say the reverse is true: If a company doesn't invest in me, I'm less likely to want to stay with them.

This means that training should be a key component of the job plan. Objectives are a good way of deriving training requirements, so they go hand in hand. By comparing personal targets and known skills, you can see where training is required.

If someone has to build a new server-side component for your new Web-based information system but has no server-side experience, it's clear that they will need training in that technology. But it is also important to remember that you may need more personally oriented skills. Many technical people are reluctant to speak in public; when they do, they make a mumbled presentation. There is little point in learning something without a practical application behind it, you could make a group presentation one of the deliverables for a performance review.

Many technical people are also reluctant to speak their minds. This is especially true in companies where conformity is highly valued. If you're not getting enough response from a team member, set that person an objective of making a more direct contribution in meetings. This could be backed up by assertiveness training.

Take It Seriously
The laughable quality of human resource management in most tech companies and departments has lead us all to take job planning too lightly. This adds to the tension that already exists in anything to do with performance review and job planning. You need to defuse it, and make it a two-person effort. You're not laying these goals on a resource, you're working together on it with a member of your team.