Issue No. 02 - March/April (2006 vol. 23)
DOI Bookmark: http://doi.ieeecomputersociety.org/10.1109/MS.2006.41
Warren Harrison , Portland State University
The days when people stayed with one company—or even one profession—for their entire working life are long gone. Aronson and Sullivan point out in "The Decline of Job Security in the 1990s: Displacement, Anxiety, and Their Effect on Wage Growth" (Economic Perspectives, vol. 22, no. 1, 1998) that the median time in a job ranged from three to eight years during the 1990s. The amount of time in one job is probably even lower in the software development industry.
While some job changes are involuntary, a good many are planned career moves. We have many reasons to change jobs: better pay, new challenges, more responsibility, better hours, less stress … the list goes on.
Planning for career changes
Sometimes opportunities show up unexpectedly. However, more often than not, we plan our career changes for years. To prepare for that next big opportunity, we enroll in graduate-degree programs or accumulate professional certifications. As a college professor, I continually receive inquiries from both students and early- and mid-career professionals asking my opinion as to what the next hot area will be so that they can get the jump on everyone else.
These individuals are clearly looking to the future and trying to prepare for the skills and knowledge that might sell well in three or four years. They realize they can prepare by learning these new skills now, so they'll be ready when the next hot area is in demand.
Besides being asked to predict the future, I often receive requests from both current and prior students to serve as a reference for a new job or a graduate program to which they are applying. These people often share two similarities: they need the letter in a week, and they're just one name out of 40 on a class list, having never taken the effort to distinguish themselves from the other 39 students in the class (except maybe by asking me what the next hot area will be).
From what I can tell, most job seekers think a good reference is like having blue eyes—either you have them or you don't. They also think you're stuck getting references from a small set of people. The list of usual suspects seems to be managers, coworkers, and former professors.
However, the value of this group as a source of references is (if it ever was) quickly slipping away. In the case of past supervisors, many companies, wary of potential lawsuits, are directing their personnel to refer reference checks to the human resources department, which will simply confirm whether the individual worked there. Even if the job candidate's company hasn't adopted this policy, usually the last person you want to know that you're leaving is your supervisor. As far as coworkers go, do you really trust your professional future to the person in the cubicle next to you? The workplace is awash in personal jealousies and irrational conduct. The candidate's chances might be better in Las Vegas. Speaking as a college professor, unless a student has taken an active role in keeping me up-to-date on what he or she has been doing, after a couple of years, about all I can say is that at one time this student had this class from me, received this grade, and then graduated. I've actually had students I hadn't seen for six years ask me by email to serve as a reference for a position they were applying for. What could I possibly say about them? For all I know, they could have spent the last five years in prison.
Managing your references
Any of us might change jobs in the future, and we know we'll need references if and when the time comes. Yet few people realize that just like managing your education and training for the future, you can manage your references too.
If supervisors, coworkers, and former professors aren't the best references, who are? I usually tell my students to look for professional peers, if not from a different company, at least from a different department or group. In general, this avoids the petty jealousies and hidden resentments that seem to go hand in hand with working with someone on a daily basis. It also avoids potential confidentiality issues that often occur when the reference might let something slip about the way your company develops software or does business (another reason many employers have adopted a "call human resources" policy).
On the other hand, you want to give your peer reference some ammunition so that, when your potential employers call, he or she can say something besides you dress well. So your exposure to these individuals can't be purely social. Ideally, you want to have been involved with them in a way that showcases whatever qualities you'd like them to be able to discuss. What qualities might these be? Well, in my experience, employers want to know more about your character than whether you can program well in Java or if you have experience developing embedded applications. There are plenty of ways to find out about your technical qualifications without asking your references.
Some of the qualities you'll want to demonstrate to your prospective references include teamwork, persistence, work ethic, maturity, responsibility, attention to detail, empathy toward others, and organization, to name just a few. So the trick is to find ways in which you can meet technical peers and exercise these qualities.
Fortunately, virtually all metropolitan areas with a critical mass of computer and software companies offer substantial networking opportunities. While there are many ways to get the kind of exposure you're looking for, one convenient way is to become involved with a local IEEE section ( www.ieee.org/web/geo_activities/home/index.html), a local IEEE Computer Society chapter ( www.computer.org/chapters), or a local ACM chapter ( www.acm.org/chapters/maps). Many offer regular section or chapter meetings as well as special events such as workshops and job fairs. In many areas, they also advocate for their local software and computer industry in terms of governmental policy making.
Once you join a local section or chapter, get involved! While simply attending the monthly meetings can be a great networking opportunity, being an active contributor will accelerate your ultimate goal of developing technical peers who can serve as references. As with most volunteer groups, the section or chapter always needs people to do the work necessary to keep the local organization functioning. This can range from work-intensive (but oh so visible) roles like president or event chair to more modest commitments like helping out with workshop registrations.
Make an inventory of the qualities you'd like to showcase, then regularly evaluate your participation in terms of this list. Usually, this means volunteering for various duties within the organization. Start establishing a list of potential peer references and make sure they're paying attention. Many individuals who try to use local professional organizations to network fail to approach the problem in a systematic, planned way and just assume their mere presence will lead to visibility.
At the same time, don't expect too much too soon. Asking people to serve as references after two monthly meetings and working the registration table at a fund raiser is clearly inappropriate. This has to be viewed as a long-term effort, just like attending graduate school at night, or studying for a certification. And ultimately, it will be every bit as valuable.
This strategy for acquiring peer references is clearly time consuming and a great deal of work. But as with most things in life, you only get out of it what you put into it.
What do you think?
What's your opinion of references when hiring new employees? In your opinion, what's the ideal reference? Do you have any particular strategies for managing your own references? Please write me at firstname.lastname@example.org.
I'm delighted to introduce a new regular column in IEEE Software that begins with this issue. Grady Booch will be writing the On Architecture column.
Grady is recognized internationally for his innovative work on software architecture, software engineering, and modeling. Grady served as chief scientist of Rational Software Corp. from its founding in 1981 until it became a part of IBM, where he is currently an IBM Fellow. Grady is one of the original authors of the Unified Modeling Language and was also one of the original developers of several of Rational's products. Grady has served as architect and architectural mentor for numerous complex, software-intensive projects around the world in just about every domain imaginable.
Grady has six best-selling books, including the Unified Modeling Language User Guide and the seminal Object-Oriented Analysis and Design with Applications. He's published several hundred articles on software engineering, including papers published in the early 1980s that originated the term and practice of object-oriented design.
I'm sure you'll enjoy Grady's new column as much as we enjoy being able to provide it.