Career

Old Dogs, More Tricks: Transitioning to a New Career

January 20, 2014

Credit: Seattle Municipal ArchivesWhen you transition to a new career, there’s a lot to learn – and just as much to unlearn. Thriving in your new environment means adapting to new values, tools, and practices.

In previous generations, stability was the rule. You worked your way up – “from the mail room to the corner office” – along a set trajectory, often with a single company. Switching career tracks was a sign of inconstancy, or desperation.

Now, it’s almost expected. Who even has a mail room, anymore? Engineers move into management, business, or law. They change focus, disciplines, or sectors. Today’s employment landscape rewards engineers with the perseverance and courage to forge their own trajectory, applying old skills to fresh challenges.

This doesn’t mean it’s easy, of course.

What is Valued?

Credit: Seattle Municipal ArchivesEvery engineering sector has a different conception of value. Learning which characteristics or practices are rewarded, and which are discouraged, is key when transitioning to a new career.

Take the case of Todd Rhoad, Managing Director of BT Consulting. His engineering career began in consumer products manufacturing as a project engineer with a focus in automation and machine design. Tiring of the industrial automation grind, he made a night-and-day switch… to semiconductor research and development.

“This was a significant transformation of my technical expertise,” he writes, “from broad and general to very specific and deep.” Whereas consumer products manufacturing demands a generalist – with knowledge of materials and process engineering, manufacturing technology, ergonomics, and so forth – his new position demanded tight focus. To get ahead in his new career, Todd needed to discover and work within a conception of value.

“I studied how engineers around me gained prestige, power and opportunity. This was driven by their specific expertise.” Engineers in the R&D sector were valued for cultivating deep understanding of focused areas of scientific or technical research. “I watched how these highly educated engineers created their area of expertise,” Rhoad writes. “I emulated it by learning to develop expertise in specific areas of physics and chemistry by studying the latest research on a specific topic. I learned their research in great detail, to the point where I could recall every aspect of their research.”

Credit: InCaseRhoad’s case is a perfect illustration, where an engineer thrives in their new career by learning a new conception of value. Had he continued as a consumer products manufacturing engineer in an R & D shop, his new career would have ended before it properly began.

“The metamorphosis was made possible by some simple advice from a mentor, who told me to blend in to my environment,” he concludes. “It took me some time to truly understand what that meant and how to actually do it.”

What Do You Need to Learn?

When it comes to career transitions, software engineers have it rough. The industry changes constantly as new modalities, technologies, and applications emerge in a steady stream. When your entire field can change around the work of a kid plugging away in his dorm room, or a software giant twitching in its sleep, learning to thrive with career transitions is a definite must. Frequently, this is a matter of learning how to learn, and doing it openly.

Credit: Seattle Municipal ArchivesFor William Robson – a 30-year veteran of software engineering – identifying what he needed to learn to succeed was a core competency. “My employment spanned from a division of ITT, with 1700+ employees, down to an owner/operator with only 50+ employees,” he writes. “The bulk of my career was spent in or around larger development teams, accompanied by massive process control, project planning, and immense budgets. Often, with far too much management and far too little common sense… When I directed teams in this environment, a large percentage of the angst and frustration was caused by the environment and not from the products or co-workers.”

By later in his career, Robson was in diametrically opposite circumstances, “a complete disconnect from that environment.” He’d moved from institutionalized software development to the Wild West, taking on a business analysis team in a small company. “Every decision was off the cuff, and every project was initiated as if we had never had executed one previously. Instead of managing a software product and technical teams, I found myself managing a team of business analysts. Mainframe application development was replaced with web-based front ends running extremely complicated database back ends.”

How did Robson manage the transition? By identifying what he needed to learn and working with his team to make it happen.

  • “Call on your previous organization and planning skills to prepare for the challenge. Prioritize the things you need learn or adapt to. Lay out a map that will bring you the most needed training/skills first.”
  • “Gain the trust of co-workers or subordinates by acknowledging the areas where you need to get up to speed, then utilize their help to do it. If you are honest and reciprocate their kindness they will be happy to help you progress.”
  • “Share your plan to succeed with your boss. He/She probably hired you for a good reason. You don’t have to admit every weakness, but demonstrate your willingness and efforts to catch up. Make sure you know your boss’s priorities for you.”

Credit: Nicholas Morgan“Dig deep,” he advises. “If you have a long history somewhere else of working on a different technology, be willing to admit that you will be starting over in some areas. That means after-work study or an increased effort that may have not been exercised since you first started in the industry.”

That’s not to say your new career will be a permanent, uphill slog. In Rhoad’s case, the process of acquiring new technical and scientific expertise became nearly automatic. “The process, over the years, became fairly simple,” he writes. “For each new area I wanted to study, I would read three technical papers and verify the results. Where knowledge is important, the actual quantity that you need to become an expert requires investigation. Once you learn what it is, it’s easy to reproduce.”

Beware Your Comfort Zone

No engineer comes into a career transition without applicable skills, regardless of how dramatic the change. Clinging too stubbornly to old ways and values is a hindrance, but applying your existing skill set to new challenges is probably a large part of why you transitioned in the first place.

“Bridge the gap between old and new,” Robson writes. “Your old project process may not work in your new environment, but aspects of it will. Learn the new system, then find a way to utilize the best pieces from each system to create one that is even better.”

Credit: Seattle Municipal ArchivesThere are basic skill sets and analytical approaches which are near universal. Project planning, methodical problem solving, and the ability to organize and analyze large volumes of information are engineering core competencies, regardless of which field you enter. Math doesn’t change much. Still, you have to be very cautious when evaluating which skills and approaches from your previous career should carry over into the next. It’s all too human to reject new things in favor of comfortable, old standbys. Be sure that you approach the processes and tools of your new career with the respect they deserve.

“Be willing to divorce your old ways, if necessary,” Robson writes. “No one wants to hear a manager start a meeting by saying, ‘at my old job, we…’ Instead, say, ‘I see that we use X process, how is that working? Is there anything we can do to improve it?’”

You’ll no doubt apply the lessons and experience of your previous career, moving forward. When transitioning, however, remember to emphasize ‘bridging the gap,’ not doing a new job with your old tools. Show up on day one ready to apply what you’ve learned… and to learn it all again.

Have a job transition story of your own to tell? We want to hear it. Put it in the comments below.