When I've seen "old hands" change jobs, the thing I often see them struggle with is the psychology of no longer being the domain expert. People underestimate how much deep knowledge they possess that is specific to their company. The longer the tenure, the more this is true. And most/all of it will be useless at a new place.
This is not a bad thing. And it is a good thing to branch out and see a broader perspective. But it's hard to prepare one's self going from being the person that knows everything about everything to being the person that knows nothing about anything.
This strikes home for me. I moved jobs recently after being at my last company for 10 years.
I felt pretty overwhelmed at the beginning. Everything from the tech, deployment process, style guide, PR process, etc might have to be relearned. I had consolidated a lot of access at my old company too.
I was really worried that I wasn't producing like I should at my seniority. This has since gone away though.
> I was really worried that I wasn't producing like I should at my seniority. This has since gone away though.
Absolutely had this in my new role, I'm about to hit a year on and have an excellent performance review which has since assuaged my concerns of imposter syndrome or having lost my touch after spending two years in a public-sector hellhole. Went from "Star QB" in an MS shop to "Holy Shit WTF is this Kubernetes shit even doing and how do I get my job done." Stressed as I may have been, it was temporal and I've gotten good lessons from it.
If I have any takeaways from this past year:
For Managers:
Add in some amount of check-in one-on-ones to keep folks aware of their performance and standing. As good a manager as my supervisor is, ours were oriented towards ensuring I was happy with the role and not wanting to leave quickly and waste the 30K recruiter fee. For that matter, I'm not one[0] to go seek validation from others and especially not when they're already over burdened with "real" meetings.
For Engineers:
Even if you're not "Senior" in terms of $TECHNOLOGY, you're (hopefully) Senior in terms of your soft-skills. If you're left scratching your head wondering "how the fuck do I get this deployed" or "what the fuck is the development cycle" or "why the fuck is there an 11 step baby-sitting process for the local development workflow" - these are opportunities to add in documentation, scripts, or process changes to the firm. If you've done your shopping right, they're probably amenable to these changes.
Personally, I scripted our local Docker Compose development workflow such that one has a clean-slate environment with one script, and can build and patch any project's Docker image / Docker Compose service with one script as well. Somehow we lacked this, but everyone had their cotdamn minds blown when I put that out there for feedback - and here I was thinking it was some silly scripts they'd likely turn their nose up at.
New job, lots of, to me, low hanging fruit ripe for automation and documentation. The team has been adrift for a long time and all the juniors just accepted broken processes as facts of life.
Every time I have someone walk me through the completely undocumented process for x, I take notes and mark the best candidates for automation.
I then go through the process a second time, adding all the api calls and semi-automate the process so instead of logging into four different consoles in the browser hunting for values and setting minor things in different places, you can up front declare seven variables, and just copy/paste chucks of code that will perform all the steps for you. You are still acting as the error handler.
For low frequency tasks, it usually ends there. For high frequency tasks, I take the time to add error handling so it can just be part of a pipeline.
It's crazy to me that the team has put up with these processes for so long, I've been turning tasks that used to take 4-12hours and highly error prone and turning them into well documented code copy/paste jobs that takes about 15 minutes from start to finish, the vast majority of which is waiting for a build pipeline to finish.
> I was really worried that I wasn't producing like I should at my seniority
This is precisely the effect I'm describing. For most tech jobs, especially at higher levels, the generic tech knowledge can be a fraction of what's necessary to get a job done. Thus people notice a drop off in their output and freak out. A good senior engineer will pick up the new things quickly, but one can't expect to replace 10, 15, 20 years of hard earned wisdom in a month or two.
I've struggled with this in every job change, even after my first job of 1.5 years: I owned my own little project, and in that tiny corner of the company, I was the expert. Going from being an expert to onboarding again feels like being forced to speak a new language. You know you're smart, but you can't articulate it.
This is true for me even though I haven’t lasted more than 3 years for each of my previous 3 employers. Domain knowledge, it seems to me, is the hardest to get up to speed on because you can’t google or SO that sh*t!
Totally. All you can do is soak up internal documentation and map prior knowledge to your current situation.
On the other hand, that new perspective can have value. Sometimes things are the way they are for a reason, other times it's path dependent, other times it's inertia.
Taking notes with your "new eyes" and thinking about how to improve things can help. But don't share until you've had some successes and built some credibility.
This was very true for me, switching jobs after six years where I had become a domain expert. There is definitely a psychological aspect that makes it difficult—you feel awkward being the noob when you're used to being the expert. There is also just a plain skills gap—you apply your skills differently as an expert than a noob and so you will need to relearn to operate in that new context.
When switching jobs, I looked for something that was different, but not so different that I would be overwhelmed. I was still a bit overwhelmed. I think it took me almost two years to reach my "comfort zone" again. It was worth it though. I built up a lot of new ways of thinking about things that I never would have had I stayed with my original job.
This is what makes me really undecided about switching jobs. I've been working in the same domain for almost 20 years. I think I'm a very competent SWE, but I also think my domain knowledge is what really impress my customers.
Can you do the job with your eyes closed at this point? 20 years is a long investment to throw away, why not just ride it out the rest of the way and use your spare energy and money to do stuff on the side.
If everyone was a tourist, there'd be no local culture to experience.
If you're happy where you are, stay there. Don't get too high and mighty, learn what you can from the people passing from one domain to another without staying in one spot too long, but don't feel pressured to do what they do as if you are missing out on an essential experience of life.
"People underestimate how much deep knowledge they possess that is specific to their company."
This is very narrow deep knowledge which might not be useful in most organization and may not be applicable to other jobs
> people underestimate how much deep knowledge they possess that is specific to their company
ha! yes
acronyms people think are just known are completely different. founders at a new company just throw them around willy nilly because they fawn over some specific person's books and tweetstorm's for the last 5 years. cultish metrics you or they happen to believe in because they heard Google did it once, 10 years ago.
This is not a bad thing. And it is a good thing to branch out and see a broader perspective. But it's hard to prepare one's self going from being the person that knows everything about everything to being the person that knows nothing about anything.