Thriving after a career change: Accelerate your learning on the job
Seven years ago, I switched careers from academia to tech. I gave up my tenured position as a professor of philosophy at the University of Missouri and became a junior level software engineer at a startup in Chicago.
I was forty-one years old at the time, and the oldest person in the startup except for the CEO and the founder. There were about thirty-five people in the company, and the average age was, if I recall correctly, twenty-six. And I knew less about my job than anyone else. Even though my new colleagues were great to work with, this was an abrupt and jarring transition.
Starting a new career, especially at my age, was daunting. I had gone from being an expert in my field to being a rank amateur overnight. Although I loved my new job, I wanted to waste no time advancing in my career. This meant learning as much as possible about the tech world, as quickly as possible. I’ve gotten better at this over the years. Here are a few lessons I’ve learned.
Two types of skills
I think about work as requiring two different sets of skills:
- Knowledge relating to your specific role. For me, this involved programming, software engineering best practices, agile methodology, and so on. Roles outside of tech will obviously be have different skills. But regardless, these “role-skills” (as I’ll call them) are the things you do on a daily basis to get your job done. They’re usually the ones that are listed on a job advertisement.
- Knowledge and skills of people who have a global view of the business. These people are the ones in the C-suite, the other executives, product managers, public relations, investors, and so on. They are the skills that are necessary for devising and communicating business strategy, figuring out which products to prioritize, etc. This category is a little more amorphous, because the business environment itself is amorphous.
Obviously, you have to focus on role-skills, at least initially. They are table stakes, and you‘ll fail if you don’t have them. But there is still some nuance here.
In my experience, there are two competing goals when you’re learning your role-skills. On the one hand, successful people are known throughout their organization for having expertise in a specific aspect of their work. These are the people whose opinions carry the most weight, and who get approached for advice. People with specific expertise are promoted quickly and they’re seen as leaders in their corner of the business. Besides all of that, it’s also satisfying to develop expertise in something. So there is good reason to specialize.
But on the other hand, there are excellent reasons to be a generalist, too. Very few professional jobs are so narrow that you can be an expert on every aspect of the work. Although teamwork is important for everyone, you have to possess a certain level of independence, too; and this requires broader knowledge. Furthermore, professional roles are changing all the time because of shifts in the economy and the business landscape, not to mention the dizzying rate of innovation in technology. If you’re too narrow, you’ll miss changes that directly relate to your job, and this is dangerous to your career.
So which should you be: a specialist or a generalist? The answer is that you need to be a specialist and a generalist in your role-skills.
But since there are only twenty-four hours in a day, and we’re only human, we have to be strategic about how we spend our precious time learning. You should think strategically and choose a T-shaped skill set very intentionally.
Having a “T-shaped” skill set means that you’ve got deep knowledge in one area, but broad and shallow knowledge across different areas. For example, in my role as a software engineer, I decided very deliberately that I’d become an expert in Python programming because that specific skill would be most useful across a variety of roles at different businesses. But I’d also learn about cloud computing infrastructure, web development, and other areas. However, I deliberately decided that I would not try to become an expert in those areas. My knowledge of them was (and still is) somewhat shallow compared to what I know about Python programming. Although people sometimes come to me for advice about Python, I go to other people when I need advice about cloud computing infrastructure, for example. But I’m not clueless in those areas, either. I can still set up cloud computing infrastructure, and I can write a basic web application.
In my experience, this is a very good strategy for developing your role-skills. Choose one area in which you’ll go deep, and a set of adjacent areas where you’ll still learn, but won’t ever be an expert.
Getting outside your role
For a lot of very smart and successful people, developing one’s role-skills is enough. If you’re really good at your job, you can be promoted, make a good living, and enjoy your work. I’ve worked with great colleagues who were passionate about a specific aspect of their work, and wanted to do as much of it as possible, and develop as much expertise in that area as they could. They are valuable colleagues and they can enjoy a high level of job satisfaction.
But there are some risks entailed by becoming too specialized. Obviously, you can wake up one morning to discover that technology, economics, or the business environment has moved past you and your skills are no longer valuable. But another risk is far more common, which is that your efforts may lack impact even if the quality of your work is outstanding.
If you get into the habit of focusing exclusively on your exact role requirements (e.g. as a software engineer who concentrates exclusively on writing code), then you run the risk of being assigned to projects that are low impact or maybe even doomed to failure. This is very common, and it’s bad for your professional future. In my previous positions, I’ve been assigned to work on projects which were obviously of no value to the client. This meant that the project would eventually be terminated and there would be some head-scratching around the office about why we ever agreed to do the work in the first place.
Every manager in the world will swear up and down that nobody who worked on such a project would ever be penalized for the project’s failure. But let’s be realistic. The impact of one’s work is a proxy for how well you do your job. If your work was part of a failed project, then this damages the perceived quality of your work.
So you want to know the context of your projects — you should be able to answer the question of why those projects and not others have been prioritized. If you do, then you can help shape the work that you’re doing, rather than being a passive worker.
But how do you pull this off? If you’re in a well-functioning organization, it isn’t difficult. Here are a few strategies:
- Talk to your manager. Make it an explicit goal to get a better understanding of the business. Write it down during your company’s review process. Tell your manager that you want to gain a better understanding of the ‘big picture’. Unless your manager is incompetent, they should be supportive because it will be mutually beneficial.
- Get into meetings. It’s easy to gripe that there are too many meetings, and that they distract from “real work”. This is often true. But if you’re relying on others to relay discussions back to you, then you’ll inevitably lose some valuable information. In particular, even if you’re informed of the outcomes of discussions, you’ll likely miss out on the reasons for important decisions. Get yourself an invitation to a manageable number of meetings where decisions are being made. You’ll probably learn something about the business that will help you later.
- Ask more questions. It’s all-too-common during a problem solving session for the person who understands the broader business context to remain silent. In my experience, when engineering discussions are happening, non-technical people in the room may hesitate to offer information and opinions because they falsely believe they have nothing to contribute. They need to be invited into the discussion. If you’re making decisions entirely for technical reasons (for example), then you should deliberately stop the discussion for a moment and ask the non-technical people for their input. They can tell you whether these decisions will have unintended effects on the value of the work.
- Get in front of a non-specialist audience. Your work, even if it’s highly technical, has consequences for non-specialists throughout the business. But it’s too common for people outside one’s particular working group to be kept out of the loop. It takes a deliberate effort to invite your colleagues to learn more about your work and how it impacts them. I’ve found that my non-technical colleagues really appreciate a small effort to communicate the important implications of even the most specialized technical work. This could be done through a formal presentation, a lunch-and-learn series, or a regular email update.
Being an impatient middle-aged guy starting over in a new career, I’ve spent a lot of time thinking about why one person’s career trajectory may be flat, while a similar person’s career takes off like a rocket.
To be sure, there are countless factors that impact one’s career success. But I keep seeing the same pattern play out over and over again:
A person with a solid skill set for their specific role will be dramatically more successful if they also have knowledge and skills that are broader than their job requires.
Understanding the business context of specific decisions, communicating well with colleagues outside your usual group, and using that information to shape your work is what creates high-impact work. And when it comes to having a successful career in which you can grow professionally, the impact of your work is what matters.