Lies, damned lies: What a job title says vs. what you really do
The IT support manager job description for the Boston branch of a multinational real estate company said, "This role will be in a fast-paced environment with low supervision. The candidate is expected to be self-sufficient."
The job title encouraged 20-year support professional Ian Johnson to respond, trudge to multiple interviews, and accept the role. Once translated from woo-you job description language into reality, however, Ian discovered he was now the boss of the guy he thought would be his boss.
OK, well, that shouldn't have been a huge shocker. The description said low supervision, right? You're expected to be self-sufficient, it said, after all. But here's the thing: Johnson wasn't just unsupervised; his hands were also tied. As he learned after he came on board, Johnson was dunked into the deep end of a very deep IT support pool. The erstwhile “support manager” had to beg New York headquarters for the go-ahead for the simplest right-click "grant so-and-so-user this permission."
How did Johnson get himself into this muck? Why, it's just side wash from the flowing river of corporate change. "Following a recent merger, the New York office is taking over much of the management of accounts, the licensing for apps, all the purchasing," Johnson says. "It's driving me and my colleagues [nuts]. We don't have access to anything. If I want to give a person access to a shared drive, I have to put in a help desk ticket to New York, which forwards it on—to Mexico.” Even for something as simple as giving a user rights to access a network drive. It takes days.
Johnson feels burned. He took a job as support manager, but the company's asking him to do something different. This job is not what he signed up for.
Johnson’s not alone. Welcome to the world of deep, steaming piles of technology job descriptions! It's where you wind up doing the work listed in the job description…in your dreams.
Sure, sometimes things change. Perhaps, after you accepted the job, the business decided it really needed an expert in IT auditing, or perhaps it should be risk management. Or, who knows? Maybe it wanted you to propagate ficus trees.
But, hey, be flexible! That's what recruiters and hopeful small business hiring managers say: It's a stellar chance for you to gain experience and skills you can parlay into your next gig. (Translation: Sayonara, better luck down the road!)
Herein, input from technology workers who've tried to fit into these ill-fitting muumuus; an anguished explanation of how one manager wound up unwillingly dumping a pile onto one poor sod; common advice for expectations gone wrong; and finally, some tools to help you steer clear.
Job descriptions and their very flammable pants
Roy Wattanasin, a seasoned IT security professional and speaker, went through the application process for what turned out to be a flamer of a job listing. Wattanasin had insider insight into the listing's creation, though, and brings us its origin tale.
Wattanasin had been working as an information security officer at an educational institution. He left for a new opportunity overseas. In the meantime, there was a personnel shake-up at his previous gig. Lo and behold, right when he was thinking of moving back to town, a job at his old organization was listed; he’d be working for a new security manager. It struck Wattanasin as a great opportunity. So he contacted senior managers he already knew, and his contacts put him in touch with the new security manager, who said, "This is great—I remember you from when you were here!"
The interview went swimmingly. "We'll get back to you," the manager told Wattanasin.
One little hitch: She hadn't actually approved the position that was advertised, much less the specifics of the job description. "She'd have created a new job description," Wattanasin says, "but [the job listing] was used by all parties [in the organization], and it was already on the website." In other words, the job listing was a catch-all that didn’t describe a real position. He applied for an opening for someone with skills the new manager didn't actually want.
It's just one example of how these delusional job listings get created. The job description to which Wattanasin responded was junk, but the organization couldn’t create an accurate one.
Who knows how it happened? Perhaps the position listing came from the security manager's predecessor. Or maybe it was cobbled together from generic, similar online job descriptions to generate one generic, useless blob.
The generic-blob thing happens quite a bit, particularly in information security, Wattanasin says. But there’s a good reason for that: Smart organizations don't list specifics of the technology they use, since the knowledge can be used to attack them. Cyberattackers love nothing more than to find a foothold into an organization's system hidden within somebody's LinkedIn bragfest. For example, a current or former company may talk about fixing some thorny problem, including all the gory system details. The same goes for job descriptions with technology details that can be fodder for cyberattacks. For this reason, job descriptions can be intentionally vague: "vulnerability management," they might say, or "security analyst—infrastructure."
"Generic descriptions are both good and bad," Wattanasin says. They're good for protecting an organization from attack, but not so good for helping job candidates figure out what the hell the job's really about.
Wouldn't you love to meet the people who put these whoppers together? Well, say hello to John. Be kind: It wasn't his fault.
Hi, my name is John, and I'm a BS job description writer…
John Woods felt bad. Really bad. He wrote a job description that he thought was accurate, but, well, things changed—and so did the job.
It was about four years ago. Woods, vice president of information security at PDX, a pharmacy software company, took it upon himself to rewrite what he describes as "a BS description." Woods had been looking for somebody with security chops to integrate into the development process, to make sure PDX was writing secure software.
"I verbalized that fairly simply with the recruiting manager," Woods says. But the job description generated had nothing to do with what Woods asked for. "It had buzz terms from the industry. Maybe he went out and did an internet search to grab samples and distill it into one description." Woods compared the process to telling HR you need to hire a brain surgeon, and they provide a job description for a labor delivery nurse.
So Woods took it over, and his description got very, very specific. He dropped in security certifications: He'd like to see CISSP, maybe a CISA, with XYZ experience, who knew ABC languages—an "everything but the kitchen sink" job description.
In response, the recruiting manager sent him any resume that mentioned the word security. Oh, well.
Woods picked the best of the lot. We'll call him Brad. Brad went to work at PDX, and Woods' teams set about the laudably proactive task of incorporating security into software development.
But then, the business took a turn. It had to restructure. It laid off some people. Woods' team thereby got saddled with additional work. All of a sudden, Brad had to "pivot"—or lurchingly swerve, as the case may be. The job's original scope—software development with security—now had to encompass generalized auditing, engineering, and security analyst work.
"It ended up not being anything really related to the job description I had written," Woods says.
Brad was not happy. This was definitely not what he signed up for. For better and worse, PDX is a small, family-oriented company, meaning Woods couldn't make it up to employees with better salaries or nicer job titles.
It got worse. The company laid off Brad. Ooof.
"It was frustrating," Woods says. "I certainly didn't hire him with an ulterior motive of 'I'm going to wreck his career' or 'Get him in the door and have him do something else.' The business environment forced my hand. Hiring somebody is making a promise you're going to do this job. I was unable to follow through on those promises.”
How to avoid working in Liarville
Warning: The following advice for job seekers is cookie-cutter. You've seen it in countless career articles. But please do unglaze your eyes. It's worth saying many times and in many ways, since not many people go this extra mile.
Namely, do your due diligence on the company, whether you’re a newbie or a seasoned pro. That means 1) doing the necessary research so you'll be prepared to 2) interview the interviewers.
Often, you have to jump through hoops by interviewing with people you won't actually report to. But it is nice to know upfront that you won't actually be reporting to them, so make sure to ask if that's the case.
Want to quiz the people interviewing you? You should. Start with these questions, suggested by technology pros and tech recruiters, including Wattanasin; Paul Cameron, president of IT recruiting firm DriveStaff; and a former senior technical recruiter:
- Is this a new position?
- If not, did the former person who held the position leave? What were the circumstances of their departure?
- Is the job really technical, as the job description says, or is it more about, say, auditing or risk management?
- Does this position report to you, or are you a hiring manager?
- How long have you been in your position? What are the job's challenges? What do you think of the IT department [or whatever department this position is in]?
- If it's a new position, is management in place yet? If so, who's in that flow?
- If not, how long has the department or project been around? How long will it be before the management is set up? How is reporting done in the meantime?
- What does a typical day look like in this role?
And include the following in your due diligence:
Check out the LinkedIn profiles of people with whom you'll be interviewing. Particularly check out the experience of staff to whom you'll report.
Do reconnaissance on the job description. How do descriptions for jobs with the same title stack up to the one for which you're interviewing?
Find out what keywords are typically used for a given job description. Over time, you'll be able to suss out what organizations are actually looking for when they ask for certain job skills.
Assume that jobs are "overfiltered." For example, a few of Wattanasin’s colleagues spotted jobs listings for newly minted security analyst jobs—as in, fresh out of college—asking for applicants with CISSPs. That's nuts. This gold standard of security certifications requires five to six years of work experience, so whoever included CISSP in a low-level security job description has been sniffing too much toner ink.
Watch out for "overbundled" jobs. Is an organization looking for a CISSP with attack incident handling credentials who's also a Certified Ethical Hacker? Often, a job that should be done by four people is squeezed onto one position.
Is your organization hiring? Don’t be part of the problem, says Cameron. The headhunter worked with one company that titled all management roles with some version of "leader." But one senior VP-level exec couldn't get into a big executive conference because you had to be C-level. His title: unit leader. They might as well have stamped him with a bar code for all the good that title did him.
Have a chat with your company's HR recruiters or hiring managers to discuss the job titles that genuinely map to the work responsibilities.
People who work at reception desks are called receptionists. In your employment listing, you can call a receptionist "director of first impressions" if you like. But when it comes time to really describe the exact job duties—"You will be sitting at a desk, greeting people and answering the phones"—you're going to have a lot of explaining to do to all the job candidates who are, like, you know, directors.
Don't get cute. Just be honest. You'll save everybody a lot of head-desk time.
This article/content was written by the individual writer identified and does not necessarily reflect the view of Hewlett Packard Enterprise Company.