I recently met a lead whose business card read “Lead Phoenix Developer.” I asked what that meant, and he explained that he was a technical lead for an project code-named Phoenix. His business card could have read “Lead Developer” or “Technical Lead” and made much more sense.
This almost happened to me today. I’m the conference chair (the program manager for the whole conference) for Agile 2009 (in Chicago, August 2009). Internally, I think that position is called “program director”–but I’m not selecting any part of the actual conference. The program piece is that the position is like a program manager position. I asked to be called the conference chair instead. That’s what I’ll be calling myself!
If you have internal names for jobs, that’s fine. Keep the internal and external names separate.
I spoke with a couple of recruiters this week. They’ve been specializing in finding test people for the last 10-15 years. (I used one of them 15 years ago, the last time I was hiring testers.) They both asked a question like this, “With all this Agile stuff, where am I going to find the testers I need?”
Agile breaks the some of the barriers between developers and testers. Both developers and testers need to write code (or scripts). The developers write small internally-facing tests. The testers write small and sometimes larger externally-facing tests. The difference is that the developers write some code that ships. All the testers’ code stays on-site.
If you’re a hiring manager, make sure you train the testers who are interested in writing code and scripts. If you’re a tester, learn to write some scripts, in some programming language, not a test tool’s proprietary scripting language. If you’re a recruiter, have a talk-to-talk with your hiring managers and tell them the testers they want to hire are worth what developers are worth–because they are developers.
In my recent consulting (workshops and assessments), several technical staff and their managers have told me they’re not sure they are being paid what they’re worth. I ask “How do you know?”
They tell me all the ways they’re working for the organization and how much that benefits their managers. I ask the next question, “Did you tell your manager?”
When you’re looking to hire someone, you can’t have the conversation about what someone has done for you at your company now; instead, you have the conversation about what the person has done for their current and some previous companies during the interview.
Everyone provides some benefit. That benefit is what the position is worth. If you think you’re not making enough, articulate your benefits to your current employer. Assign a dollar (currency) value to your work. Don’t like the number? What would you have to do bring more value?
If you’re looking for a new job, know what you’re worth. And if you’re a hiring manager, think hard about the skills that would bring the worth you desire to your organization. Go back to your hiring strategy and job description. Do they describe the value you want from a candidate? If not, your job description is not working for you. Change it.
Companies don’t pay people because they are warm-hearted. They pay employees to provide value. The more value, the more pay. (We hope. Sometimes, that’s the more expected value, the more pay.) If you’re a candidate, define your value. If you’re a hiring manager define the value you want to receive. Now you’ll have a much better understanding of what you should pay. And, you’ll know what the decision is worth.
Read Sidu’s Avoiding hell at work by spotting Dilbertian job descriptions.Sidu’s on target. That’s why I suggest you do a real job analysis, and write the ad and/or job description with other technical people. People who are not in the industry dumb down the descriptions and ads, and make them worthless for people to filter themselves in or out for your job.
If you haven’t read Hiring the Best …, you may not realize how often I say it’s ok to iterate on job descriptions.Job descriptions cannot be static. To all you HR folks, sorry, you have to work with the hiring manager to determine what’s most important for the position you’re filling now. This particular developer/tester/writer/project manager/whomever is not the same as the last person you hired. So you gotta change the job description.Expect to iterate on the job description as you walk through the analysis, and possibly after your first few phone screens. Even after you bring a candidate in, expect that you’ll know more about what you’re looking for–and what you’re not looking for.Take advantage of that knowledge and iterate on your job description. It will save you time in the long run.
I’m doing a webinar series for Kennedy, starting this Thursday. See Building Effective Hiring Strategies & Job Descriptions To Match!. You can sign up for either or both. I hope you decide to join me Jan 18 and 25, 2007. (I’ll be doing another series in May about how to use different interviewing techniques and how to teach them–assuming this series goes well.)
As with all templates, the key is in the writing. I’m still organizing m site, so if you want to see the page with all the templates, it’s here. Enjoy!
Lisa Haneberg, in her post, How do we define a job - Part 2, develops a prototype for a job posting. She does a great job. She starts with a main attractor, adds in the essential qualities, preferences, and skills, and talks about who should not apply.A job description is not an ad. Posting a job description is not the same as posting an ad. If you’re not posting ads, why not?
It’s not easy to write an ad (although I did devote a whole chapter to it in Hiring the Best …). But you need to write an ad to attract the most suitable candidates, and to prevent the unsuitable candidates from applying.
Here’s the template for an ad. The real key for compelling ads is to work on the writing.
In description prescription, Don Blohowiak asks the question, “How much of a factor do you think job descriptions are in influencing what people do at work all day?” (None is his cynical answer :-)Part of the manager’s job is to review those job descriptions during the year and see where people are outperforming their description (and there will be places they are), and continually monitor any underperformance (and then provide prompt and effective feedback).
An aside: do you know how to write job descriptions? Should I post my job analysis template?
, you may not realize how often I say it’s ok to iterate on job descriptions.Job descriptions cannot be static. To all you HR folks, sorry, you have to work with the hiring manager to determine what’s most important for the position you’re filling now. This particular developer/tester/writer/project manager/whomever is not the same as the last person you hired. So you gotta change the job description.Expect to iterate on the job description as you walk through the analysis, and possibly after your first few phone screens. Even after you bring a candidate in, expect that you’ll know more about what you’re looking for–and what you’re not looking for.Take advantage of that knowledge and iterate on your job description. It will save you time in the long run.