Design, deliver, and run enterprise blockchain workloads quickly and easily.
All servers and systems
Fasten your seat belt: We are about to journey into the minefield of self-destructive career moves in IT. Below we identify some of the most common forms of self-sabotage, as described by technology pros who have themselves experienced career mishaps or witnessed others do so. We also gathered input from IT headhunters, career coaches, and others who have coached the fallen, the baffled, the ultimately unteachable.
In no particular order—except that No. 1 is truly one of the most common—here we go:
This is one of the most common ways to run a tech career off the rails, and it's easy to see why. Techies get complacent, or they get overwhelmed by the time commitment and energy needed to acquire new skills and master new technologies.
IT career coach Elizabeth Lions sees a lot of tech people sunsetting when they hit their 50s or 60s. "Sometimes they want to go in, do their 40 to 45 hours, and go home. They just want to ride out their careers and don't want additional reading," she says.
In fairness, many techies have seen all the IT career pendulum swings: offshore, onshore, back offshore. It's hard to get them excited about new IT trends. Keep in mind, however, that companies that lack skills in-house will look externally, whether those skills are cloud, IoT, Hadoop, or the know-how necessary to prevent data breaches.
Here's another insult-to-injury scenario: You sign on to the training ordeal, but your company outfits you with yesterday's technologies. That happened to Rohit Keserwani when he was working as a senior business analyst at ZenSar Technologies, a computer repair service in Johannesburg, South Africa. Six years ago, Keserwani was chosen as a candidate for training in business intelligence, data warehousing, and analytics. It was a grueling, nine-month program—without pay. There was a sweet pot of gold at the end of the misery, though: In the end, most of the candidates got placed at senior positions in the industry.
Fat lot of good it did them. They would have been better off learning Hadoop, the big data technology that was rapidly kicking data warehousing to the side. "We were so overwhelmed," Keserwani recalls. "Most of us chose to not see the fact that data warehousing is a sunset field. I corrected my course only later when I realized this and got into data science—another booming area that is seeing an acute shortage of talent."
Keserwani's happy ending: He's now a senior business intelligence consultant with Equifax.
This was actually one of the seeds that spawned this listicle: One of our editors witnessed a discussion about the dangers of deprecating your own work on a women's technology forum. Examples include self-damaging comments, such as, “The code needs work, but I’m sure you guys will be able to spiff it up.”
Don't do that. The world is hard enough without placing your own career banana peels. It’s good to know your weaknesses, sure, but how do you measure your skill? If colleagues tell you repeatedly that your work is wonderful, maybe you should believe them.
The opposite of self-deprecation is taking too much credit for your work. "I manage a team of people," says John Woods, CISSP and vice president of information security at healthcare technology provider PDX. "If I said, 'Yes, I did these things,' constantly, rather than recognizing the individuals who contributed and did the work, that would certainly be detrimental to my career. You have to take credit for the things you do and not deprecate your own work, but you also have to recognize others who help you accomplish that work."
A while back, Woods worked on a team led by a guy like that. Let's call him Dean. Dean was a great leader, except when it came to recognizing his team's accomplishments. That's when everything was completely about Dean. Eventually Dean left the company. He stayed in IT, but as far as Woods knows, he never advanced past team lead.
Moral: A team isn't made up of just one person; it's the sum of all its parts.
A successful IT career requires more than just tech skills. You also need soft skills such as problem-solving, communication, networking, and presentations.
It was the last one that spelled doom for one of Keserwani's managers, back when he was a business analyst at the State Depository in Johannesburg. The manager, who was really bad at presentations, realized that Keserwani could cover up for his shortcomings. He put Keserwani to work handling initiatives that included client-facing engagements. The manager eventually lost his position, and Keserwani wound up generating exposure for himself and valuable industry contacts.
Moral: Don't stay comfortable. Identify your weak areas and get yourself some skills training.
This one's a bit counterintuitive: Don’t you want to be indispensable so they don't dump you? But if you're indispensable, how can they bump you up?
At one point, Keserwani was working for the Standard Bank of South Africa, which had an extremely complex business ecosystem. It took at least a year for most consultants to become productive. At the same time, the team structure was unstable, and there was a high attrition rate.
Keserwani wound up being the only person on earth who understood the bank's systems. It put him in a situation where he had to fight tooth and nail to get released from his position.
In the meantime, he lost a few opportunities for a better career. "I had to burn the midnight oil to prepare a training course (along with documentation) and train five people before I was allowed to leave," he says.
Lesson: Don't become an irreplaceable, unmovable monolith. Train colleagues who can replace you, and develop documentation to ensure that work doesn't suffer in your absence.
LaKiesha Tomlin is a hiring manager in the aerospace industry who also owns Thriving Ambition, a coaching service focused on STEM careers. Tomlin recently worked with somebody she calls a "brilliant young engineer." He's typical of many engineers she works with every day in that he lacks communication and interpersonal skills. "Most of them believe they can reach the top echelons of a company by getting a couple of degrees and certifications," Tomlin says.
The engineer—let's call him Jerry—is looking to land his next promotion in software development. A few months ago, he had a big interview with a group he'd love to work with. It didn't go well.
During a coaching call, Jerry told Tomlin how he'd answered some of the questions. She spotted the problem right away: It was a behavioral interview, where they asked questions about hypothetical situations or the candidate's experience in a given situation.
"In almost every answer, he never gave them specific examples about his experience. He consistently talked about textbook theories and case studies," Tomlin says. "As you can imagine, the interview panel was not impressed."
OK, so, no big deal, you might think. Next time, get specific about your own experiences. Not a career killer per se—just a blown interview, right? Well, no, not really. Jerry is what you might call a self-sabotage sandwich. He has layers of #Fail. Tomlin gave him advice for his next interview, but he rejected it. He's still waiting for his next promotion.
Tomlin thinks the main takeaway is to be open to learning new things and not believing that you know everything. "No one knows it all," she says. Fair enough, but Jerry also made another classic techie mistake: sticking to general theories instead of getting concrete. Simply put, that's nuts when you're working in the very quantifiable field of IT. In IT, you can and should get to the nitty-gritty when you're going after a promotion, a new job, or a new project.
Which brings us to...
Tech people often fail to quantify their achievements. That's a shame, given how easy it is to do that in IT. Paul Cameron, president of IT recruiting firm DriveStaff and administrator of an outplacement resource called Speedupmyjobsearch.com, says the ability to quantify is a big advantage for IT pros.
"They can see from Day 1 how much uptime there is, how many workstations, what technologies are being used," Cameron says. "If they document that from the day they walk in, then do it again on their six-month and one-year anniversary, then they can quantify how far they've helped the company advance. They can justify a raise or promotion." Everybody Cameron places does that. He sends emails to make sure they do.
A practical way to make it happen is to keep a journal of your work. Terry Kim is the CEO of NexGenT, a startup that teaches networking, data center, cloud, and cybersecurity skills. Kim tells clients to keep weekly journals. "A lot of IT pros don't understand how big an impact they've made," Kim says. "A weekly journal can be rolled into an executive statement that can be very powerful. You have proof of what kind of jobs you've been involved with."
It's a no-brainer, but nobody thinks to do it.
The first 30 days on a job or new project present you with a golden opportunity to network. Newbies have a great line to use: "I'm the new guy/gal and still trying to learn about this [place/project/technology]. Can we do lunch?"
This is a good way to apply a thick layer of layoff repellent, Cameron says. When it's time to cut costs, management looks around and says, "Who'd we just hire? Joe? OK, let's lay off Joe." But if a few managers say, "Hey, wait, I really like Joe. I could use him in my department," you can become the next transfer, as opposed to the next head on the chopping block.
Cameron has put together a useful video series that can help with both onboarding and the "quantify your work" tip.
Tech people are often introverts, for whom networking can be torturous. They could, but seldom do, solve for their lack of people skills by applying their flair for programming.
In plain English: Try scheduling networking automatically. For example, Cameron suggests, compose a follow-up email to go out to somebody you want to keep in touch with. Schedule it to go out in, say, three months.
This is common in tech job interviews, but it also happens when IT pros are trying to get on a new project. Cameron frequently hears from job candidates who fielded questions about a particular outdated application. All too often, the candidate immediately starts telling the interviewer about a better way. "They'll say, 'You don't want to use that technology, you want to use this'—without knowing why they use that technology in the first place," Cameron says.
For example, Cameron has one client who uses outdated technology, and almost everybody who walks in the door criticizes it. But the company has a good reason: Its biggest client is a huge bank that uses legacy software. The only way to integrate with its systems is to match up the old software. Walking in the door to interview with Cameron's client and dismissing that technology is an insult. Of course they know what the latest technology is. Assuming you're telling them something they don't already know is akin to telling an interviewer that he is stupid. "That definitely hurts you, in a big way," Cameron says.
A related misstep is to answer one of those "tell me how you've solved X problem" questions by just relating how you've done it. There are always 150 ways to solve a given problem, Cameron says, and the interviewer, likely a tech geek, has their favorite way in mind. Guess the wrong way, and you're dismissed as a dope.
A better way: Answer by saying something along the lines of, "The way I've done it successfully is X, Y, Z. How do you do it?" In other words, turn questions into conversations instead of excuses for somebody to assume you're dumb.
"This is the mistake that engineers [often] make," says NexGenT's Kim. "They wait until they're told what to do, instead of saying 'Hey, Mr. CEO or VP or IT director, what's the IT budget? What are the top three projects you're working on? Can I contribute? Need any research done?'"
Many IT pros are inundated with mundane tasks like dealing with support tickets. When they finally get some downtime, they often blow it on web surfing and other unproductive activities. Instead, they should look around for high-level—as in C-level—projects and volunteer to work on them.
Don't have the time? A lot happens on maintenance weekends or nights. It's a perfect opportunity to dive into a project. From there, you can learn the intricacies of an IT project lifecycle, from execution through to the mundane tasks that come after the main project is done.
Kim once worked with a junior-level tech support staffer at NASA named Andy. He had six years of IT experience in the military but didn't know how to advance in his civilian career. Andy wanted to become a network engineer. Kim advised Andy to volunteer for security and compliance projects because security is a key focus at most companies. Within six months, Andy was working as a network engineer at NASA.
He got there by volunteering for projects related to malware defense and tightening the security perimeter by upgrading firewalls. Within 90 days, he got a 30 percent pay raise. Part of that was showing up, gaining skills, and being seen on a high-visibility project, but a big part of it was also documenting his work (see how to correct mistake No. 7 above).
Andy didn't need a college degree, certificates, or even all that much experience. All it took was looking around and asking upper management where help was needed and then jumping in wherever it made sense.
There's a ton of opportunity here that often goes untapped. For one thing, upper management often relies on vendors because they don't have all the necessary skills in-house. How about if you become that in-house expert? Kim suggests reading up on the latest trends and doing due diligence on a given vendor. This can give you a lot of credibility with your CIO and can garner you a good amount of influence.
Another smart move is to build relationships with vendors, manufacturers, and partners. If you know how the ecosystem works and what resources are available in it, again, you gain cred. Plus, it's a wonderful way to network. Upward mobility—as in job offers—can come through opportunities you harvest from the ecosystem. Manufacturers have account teams, product specialists, engineers, and more. They're at your disposal. Learn from them. If the manufacturer has partnered with a value-added reseller and your company gets that VAR to run a 30- or 60-day equipment trial, consider it brain-picking and networking time.
Another often-missed opportunity: If you don't do due diligence on a vendor, you're missing possible opportunities to save your employer money. You can become a hero if you vet the technologies and keep an eye on the manufacturer to make sure it doesn't take advantage of a lack of oversight.
This has to do with confirmation bias. Like all humans, tech pros tend to stick to their guns, even if new data shows they are wrong. PDX's Woods has seen this play out with networking teams. In previous jobs and, to a certain extent, in his current position, it seems that whatever the problem is, it's not the network. In fact, Woods knew one network pro who had a T-shirt that read, "It's not the network."
This attitude stuck even when Woods showed various network teams hard evidence that the problem was the network, and even though his teams did things to correct the problem in the past that showed it was almost purely a network problem. "That reflects poorly on those individuals in meetings," Woods says. "Not just with me, but with the CTO and the president. They were unwilling to change their views in the face of evidence that they were wrong."
How wrong? "We had system logs," Woods says. Don't be that guy or gal. If you are, don't be surprised if you wind up on the help desk—or the sidewalk.
This is just a sampling of ways tech pros blow their careers. There are so many more mistakes we could add to the list. For example, a choice one is being thin-skinned, whether it’s an inability to gracefully accept feedback—say, for the quality of your code—or bristling at the use of the term "guys" when applied to a mixed gender team. Getting project estimates way wrong is another one. And failing to negotiate salary is a perennial problem, not just in IT but most fields.
Enough rubbernecking for one day. Keep your eyes on the road, and keep up your journal!
This article/content was written by the individual writer identified and does not necessarily reflect the view of Hewlett Packard Enterprise Company.