
Subscribe to
Computerworld
|
October 14, 2003 (Computerworld) -- If yours is like many other organizations, your hiring freeze has lifteda little. Maybe you have one or two open requisitions now, or maybe you think you'll have one in a month or so. That's great. Now it's time to think about what kind of person you require in your group.
Notice that I didn't say the kinds of technical skills you require. You certainly need someone with technical skills. But if you have only a limited number of vacancies, it's even more important to think about the kind of person you want to hire.
Here's how I think about devising a job description:
First, I think about the people with whom this new employee would work. Would this person work as part of an extended team, or with just a few people? Who are all the other people, and will I need someone with negotiation skills, or someone who can talk to customers, or someone who can translate between the technical marketing folks and the developers to define the requirements? These people all require excellent communication skills, and those skills are different for each position.
Next, I think about the role's activities and deliverables. What will this person do all day, each week, each month, each year? Developers just sit and code, right? Nope. Developers discuss designs with one another, talk about requirements, explain what they are thinking to testers and sometimes write initial product documentation. They debug, not necessarily alone, and participate in peer reviews. Learning how to use a compiler is different from learning these technical communication skills.
![]() |
|
| Johanna Rothman consults on managing high-tech product development, focusing on project management, risk management and people management. You can reach her at jr@jrothman.com or by visiting www.jrothman.com. |
Now I'm ready to think about the technical parts of the job and determine how many years of what kinds of experience I require. And I can decide which technical and nontechnical skills I can trade off once I start meeting candidates.
None of the skills above is encapsulated in "four years of Java experience" or the technical tool of your choice. Yes, you need to look at technical experience, but don't weight the job description too heavily toward technical experience. Use the job description to offer a distinct opportunity to a candidate, not something so generic that your postman will buckle under the weight of the resumes you receive.
Technical people are much more than the sum of their technical skills. Some are introverted and prefer to work with one or two other people; others are extroverted and are happiest in large groups. Some think from the top down and others from the bottom up. Some rush to judgment; others are able to consider multiple solutions to a particular problem until they have to make a decision. Great teams comprise different types of people, not same kinds of people with all the same kinds of technical experience.
Don't make the mistake of thinking that the only differentiator for the technical people you hire is their technical skills. Technical skills are relatively easily taught and learned. How people communicate with one another, their drive, their sense of responsibility, their problem-solving abilitiesthose skills are valuable parts of each person. You'll create better teams when you hire people for reasons beyond their tool experience.
|
|
Print this Story |
|
Send Us Feedback |
|
E-mail this Story |
|
Digg this Story |
|
Slashdot this Story |
|
|
|
|
|
|
|
|
All Zones Application Performance Zone Enterprise-Class Security Zone Enterprise Solutions Zone The File Data Management Zone Grid Computing on Windows Zone Security Management Zone ITIL Best Practices Zone The SAS Zone Storage Virtualization Zone The Data Center Management Zone |
|
|
| ||||||||
| ||||||||
| ||||||||
|


| Independent Report by Forrester Research, Courtesy of MKS: "Selecting the Right Requirements Management Tool — Or Maybe None Whatsoever" Many of today's requirements management tool purchases are misguided: Application development and program management professionals often buy requirements management tools for the wrong reasons and select tools that are out of line with their needs. In this independent report, Forrester advises app dev organizations to be realistic about the problems that a requirements management tool can address, the level of tooling that they require, and their ability to build and maintain tool integrations.
Download this white paper now
See more Whitepapers ![]() |

| Detect, identify, and locate RF interference in 802.11 WLANs. AnalyzeAir software provides IT network professionals with the vision they need into the hidden world of RF, providing them with the ability to see the spectrum in a visible and intelligible format. AnalyzeAir software lets you see, monitor, analyze, and manage all the RF sources and wireless devices that influence your Wi-Fi network's performance and security, even if those devices are unauthorized or transient. AnalyzeAir Trial Software v3.1 highlights the features found in AnalyzeAir Software using a set of saved spectrum files. Replay the data and experience the visibility that AnalyzeAir Wi-Fi Spectrum Analyzer provides. Note: The trial software is limited to a player version only. It does not communicate with an AnalyzeAir PC card so it does not collect actual spectrum data. Register for this trial now.
|
| About Us Advertise Contacts Editorial Calendar Help Desk Jobs at IDG Privacy Policy Reprints Site Map |
|
CIO The Industry Standard |