Should I stay or should I go? Part 1
A framework for when to look for a new role
I don't know if it's just the software industry or the SF Bay Area, but there seems to be constant pressure to consider changing roles. There's always a new wave of technology that you see many of your LinkedIn connections flocking to (GenAI being the latest one at the time of writing). Or you see colleagues leave their roles and wonder why and whether it's worth checking out the constant stream of recruiter pings. You may have heard the rumour that you need to move up and out to get promoted. At the same time, you see counterexamples where distinguished engineers stay at a company for 20 years. The "job for life" no longer exists, but is there merit in "hanging in there"?
I have a simple framework for deciding when to change roles or companies, and it boils down to two questions:
Are you learning a demonstrable skill that will further your career?
Are you being recognised reasonably for your contributions and ability?
If the answer to either question is no, it's time to look around. If you answer no to both, get out ASAP!
Let's break these questions down.
Are you learning a demonstrable skill that will further your career?
We should always be learning at our jobs (following on from Always Being Curious). However, we need to be doing valuable learning. Obviously, you should be learning about things that interest you, but it also needs to be:
A demonstrable skill or something you can explain in your next interview. References must be able to speak positively about your skills. When you're moving to another role in the same company, your current manager(s) and peers need to vouch for these skills without you preparing them for questions.
Something that will further your career, i.e. applicable outside your current role and company. New technologies are an easy area to focus on, especially early in your career. Whether domain knowledge is valuable is a tricky question; there is a fine line between gaining knowledge about the industry versus how your company does things in the industry (which may only be valuable in your role). It is best to take the time to understand why your company does things a certain way and why certain decisions were made; this is transferrable knowledge. You may not always get the opportunity to design a complex system, but you can learn why it was built the way it was. You can also learn how your company applies new technologies to their products to benefit users; I argue that learning how to choose and apply technologies is more valuable than the technologies themselves (but that is another post).
Are you being recognised reasonably for your contributions and ability?
We all have a sense of how well we are respected by our managers and peers and whether that matches our expectations of our own performance. Some patterns you may see:
Are you in the queue for a promotion and waiting for someone above you to move out so you can move up? If the senior person is your mentor or someone you admire, this situation may be okay. It's not okay if a promotion is based on how long you've been at the company and whether it is your turn.
Are you getting the opportunities to work on exciting projects, or are you just treated as a warm body? Obviously, you're not always going to get the best projects, but missing out more often than not is a sign. Also, your team may not be set up to drive the projects that are exciting and necessary for your growth.
Are you getting training opportunities like attending courses or conferences that others are also getting?
To be clear, you should have open and honest conversations with your manager to ensure they are clear about your career goals. If you feel it is not being listened to, that's the signal to look elsewhere.
Why leave if you're learning something OR you're compensated well?
There are cells in the matrix that are orange and not red. I treat these as signals to start looking around. There's no need to leave immediately, but you should start scoping opportunities.
Why leave if you're compensated well but not learning? Isn't this an easy life? Unfair as it is, our perceived value, especially to prospective managers, degrades over time if we don't invest in ourselves. It's not a great look to refer to a project you did several years ago in your interviews when you've been in your current role for a while. The time you spend NOT learning or demonstrating growth now limits your future potential; are you being adequately compensated for that? Not learning also puts you at risk of being put out to pasture forcefully rather than by choice.
Why leave if you're learning something but not being recognised? Isn't this the value proposition for graduates joining the big cutthroat companies? I simply put this down to mental health; you need to decide if the opportunity cost is worth it.
Poor reasons for staying in a role
Even with the framework I describe above, there's always inertia to moving roles that you should overcome. Here are a few that I've seen and faced myself:
"The team needs me": If you're good, the team will always need you. You'll get thrown onto projects and never find a good time to leave. We all have a bit of ego and think you're critical to the team's success. The reality is that (a) shouldn't be the case, and (b) if it is, the team needs to wean themselves off a single point of failure.
"My project hasn't delivered its full value":
This is a tough one to work through because the first question in interviews about a past project is, 'What value has it delivered?' This is especially difficult for senior engineers who work on large and long-running projects. You may not see the true value of your work for months or even years. Even after leaving Atlassian for a couple of years, ex-colleagues have graciously reached out and told me, 'Do you remember that X you were working on? It's finally released to users!' The thing is, you're probably providing oversight and not directly working on the project at that point. You've probably already started on another project (as per the previous point about always being busy). Draw a line on your deliverable (finished design, have the project funded and begun execution), and you are free to move on once you have completed that.
"I'm scared to get on the interview train again.":
It takes a lot of work to get into interviewing again. Interviews are like a big, long test (at least a day just in interviews per job, but also long in elapsed time and preparation), affecting your work and personal schedules. You have other aspects of life to consider.
There's also the fear of failing to deliver. We all feel terrible if we fail a test at school, and not getting through interviews feels like a failure. We think, "Maybe I'm just good where I am because I'm part of the furniture", "Are my skills sharp enough, especially because I'm not coding on a day-to-day basis as an architect or tech lead?"
To help, I can offer my experiences when changing companies:
I'll be honest: It needed a lot of prep, especially coding practice. As much as I don't buy the leet code-style interview questions, they exist, and you need to get through them to truly demonstrate your value. Having said that, trust your design skills and project examples. Lightly read up on the system design examples to keep the typical prompts in mind (function and non-functional requirements, incremental build of a solution), and practice presenting a project to a leader (which you are probably doing already). I know some people do regular practice interview rounds every couple of years. They're not actively looking, but it offers a way to tamp down these fears. Then, if something actually comes up, they can jump.
"Will I do a Daniel Ricciardo?" - For those who aren't Formula 1 fans, Daniel Ricciardo
is/was an excellent Australian driver racing for a premier team. Then, perhaps not feeling respected by the team and likely to become the number 2 driver, he surprised everyone by moving to be team lead of a struggling team. He did okay there, then surprised everyone again to move to a third team where his performances fell off a cliff, effectively ending his career. While moving roles always has risks, his situation is a reminder of truly understanding how your manager and peers see you through open and transparent discussions. I think he moved too early, to begin with, when his team still had a chance to recognise his talents fairly.
Why doesn't time-in-role factor into the decision?
The short answer is that time-in-role correlates to decisions to change roles but should not be the cause. I value the variety of experiences I was exposed to early in my career, where I was shifted from project to project every 3, 6, or 12 months. As junior engineers, we can quickly add value to projects and move on to learn new things. A senior engineer, however, likely needs more tenure to understand a new domain, find and address problems suitable to their level, and learn those valuable skills.
There is also the angle that changing roles only sometimes means changing companies; this is probably a topic for a follow-up post.
Summary - so, am I jumping to a GenAI company?
Someone recently asked me, 'Would you consider moving to an AI company to catch the AI wave?' Do you feel you're missing out? I mapped my current situation to the matrix and simply answered, 'No, because I haven't learnt what I wanted to in my current role.' My answer may change in a while, but I'm comfortable knowing it would be my choice then and not FOMO.