Ask HN: I'm changing my job after a 15-year tenure. How should I proceed?
I decided to get out of my comfort zone. Try something new, I told myself on and on for the past 3 years. And I finally did it. I'm changing jobs.
I'm going to a new company, where I'll be doing something slightly similar to my previous role, but in a totally new field. I don't know anyone there. The people seem extremely friendly and fun to work with. This is what I felt in the hiring process.
It feels like I forgot how I got good at this. Technically, I have no doubts to get things done. However, on the people level, I have no clue how to get started. How do I make "new friends" at work?
What do you usually do when you switch to a new company? How do you go from the "new clueless person at work" to "oh hey Mike, I'll need your help this afternoon"?
142 comments
[ 2.7 ms ] story [ 192 ms ] threadVery much agree with this one, particularly with remote work. Most people get too many emails, and will naturally prioritize emails from people they know and have a reputation with compared to a new person.
Even quick introductions before meetings as people filter into a meeting room. You don't talk about your hobbies and family before a meeting starts with 30 people on Zoom, but that's certainly permissible with a couple people as people enter the room.
I've only done 6 to 12 months stints, so no advice from me I'm afraid.
Instead, be yourself, and if you have to try for something, try not to upset other people.
Ask for asking Mike for help, just do it. He knows you're new and the company has told him to help you get going. You'll stop being the clueless new person after you've learned about the company's stuff.
For fully remote it’s a much bigger challenge. I try to get involved in social slack channels and connect with people that way. Also finding ways to talk face to face on Zoom etc goes a long way.
This is underrated. Especially when remote, you have to constantly remind people (and especially your manager) that you’re doing something.
You don’t have to be annoying about it, but let people know when something is done instead of just changing the Jira status.
Let's start with the basics. Be a nice person, approachable and someone easy to work with. This will remove the barriers and your co-workers will be more willing to contact you first! Honestly, these qualities will get you far.
Get "into" the company's culture. There might be internal pain points (ask questions, people will be more than willing to share their pains. If you listen you will easily make connections). Same goes for the inside jokes.
Finally, from experience I know the first to three months are the most difficult ones. And that's fine! Accept it and don't be harsh on yourself. You sometimes will be doubting yourself, feeling low, but all of that will pass. It always does!
I don't mean any offence, but you haven't really then have you - that's quite a different situation, your average tenure is less than 1.5y, more than tenfold less than OP's.
I imagine (haven't done it myself) it's psychologically quite different to leave somewhere you're so established, and start somewhere new when it's so long since you've done that. You're used to it. I'm not saying it doesn't have challenges, but I think they're at least different, and anyway you're used to embracing them.
I’ve also done gigs for 7, 5, 2 years, one for 8 months and now I’m 2 months into my new gig. I would concur that ramp up speed has been pretty similar at most. I’m not sure the first move (after 7 years) was harder than the others.
Honestly, I think it tends to be harder emotionally to walk away from the situation. From the familiarity to the network, it can feel weird leaving that all behind, even if there are obvious reasons you need to leave. Once you’ve made the break, starting new tends to be similar: spending a few months getting familiar with the exact tech stack, the people, projects and business. Usually after a handful of months you’ll start feeling in the groove and know enough of the environment to feel like you are making serious contributions.
Congrats on new things! I just switched to a new thing myself!
That said, I am still contributing the community, albeit a little slower. Hoping to have a first-rate Swift syntax done in the next month or two, plus continuing to plug away on some Package Control work.
Congrats on the new role and continuing to push yourself!
One other point worth repeating came from a friend who was a Marine: "You have 6 months before you're part of the problem." Once you are on your feet anywhere, do try to create the change your teammates have been desperate for but lack the enthusiasm to push for. Use your New Person Karma up-front.
Compared to the OP, your situation doesn’t tell you this at all. It tells you that you know for you, the first to three months are the most difficult ones.
You have no way to know what years 4-6 are like or years 8-10 or years 14-15.
The problem OP has is very different from the one a job-hopper has. You’re experiencing months 1-3 with a plan of leaving in 1 year. OP is likely thinking of months 1-3 with years 5-10 in mind.
I can probably keep some kind of fiction together long enough to get to my next VC-funded shitshow gig.
But if I do that, after 2,3,4,7,12 years, it’s going to be obvious to the people I work with I’m a fake weirdo who’s miserable to work with and not a genuine person. This will be true even if nobody else works there for 15 years — it’ll get passed down from new hire to new hire.
I did a 7 year stint as a contractor in which I worked at 7 different places, plus multiple smaller ad-hoc projects. Most contracts started with 1-3 month engagements. Most were also extended multiple times. But I never made any assumptions about extensions.
Knowing that I was only ever going to be somewhere short term made it a while lot easier to be be fully honest with people, instead of just telling them what I thought they wanted to hear. I found it put me in a great position to point out problems or give advice and recommendations for improvements based on my experience without any worries about upsetting anyone who was personally invested in the existing status quo. Because the consequences of the personal relationships weren't so critical, I would be leaving anyway
Knowing I was only there temporarily also made me much more conscious of writing up or handing over knowledge of the things I worked on. I always tried to make sure I was building up the client to succeed after I left.
I always wanted to do a great job, so doing something poorly because I didn't have any long term consequences was never really a factor. Many clients reached out and offered repeat business too, so the lack of long term consequences isn't really true anyway. If you do a good job, it adds to your future revenue stream.
I try to carry this mentality forward now I've returned to more conventional employment. Being honest about improvements needed, and working to help the team succeed in the long term.
ha, love to see this so pragmatically written
I gave advice for author's question: _How do you go from the "new clueless person at work" to "oh hey Mike, I'll need your help this afternoon"?_
My advice merely helps the author to speed up the process to get there.
In addition, I never join and plan on leaving in 1 year. In contracting, sometimes you work a month, sometimes 4 years. But you always go all in, regardless of the assignment.
Just like the scorpion didn’t plan to sting the frog?
I've been to many gigs where burned out or incompetent permanent (!) employees made a complete mess almost running company to a ground. Incompetent leads, even CTOs desperate for a fix.
Yet, as a contractor you come and help the companies *
* there are incompetent or selfish contractors as well.
You don't know that
People have commented on the blotchiness directly, so I do wonder how many conversations I just haven't had because of it.
If anything, it's the opposite. I have more career opportunities than ever:
1. You learn new skills -> you become more employable
2. You leave on good terms -> most of your previous companies are waiting for you with open arms (more opportunities, safety net, upper hand in negotiating salary)
3. You discover yourself -> what you want, what are you good at and where can you go next.
I would take it with a grain of salt. Contracting and living in a big city is very different to small towns and/or permanent roles.
We're looking for people who would like to stay with us for, say 3–5 years, at least. While our tech stack, culture, etc. isn't that special, it still takes time to acclimate.
Perhaps you are a very talented specialist in very narrow niche? People like that are always useful, and can skip between jobs as they please. Although, I'd probably do stuff like that on a consulting basis, instead of a salaried employee.
I firmly believe you are looking at the short side of the stick. Ask yourself, what can you do for people to stay for 3-5 years? You don't need special stack or culture, just listen to individual's needs (plenty of books written on this subject).
Some places I worked at, the time just flew. I honestly wanted to stay there longer because the whole assignment was like a Swiss watch.
1-2 years is a red flag, but it's mostly a red flag of a bad company, not the employee. I base this on my experience and interviewing devs.
There's a people aspect to it, a time aspect, and a technical skills aspect.
For people, you need to develop rapport. A lot of struggle at the beginning is getting to know the right people. This is easier in the office where introductions are more fluid and you run into people.
On the time front, you become an expert on the systems a company employes as your tenure increases. You help design systems and understand the tradeoffs in the decisions that are made rather than walking in and saying "This is odd and I've never seen it before. Why is it done this way?", with answer quality varying on how long ago the decision was made. I've worked at multiple companies where people retire to start collecting their pension and come back a few weeks or months later working as full time consultants because they have deep knowledge of why things are setup like they are, the hiccups that will be encountered during a system change, etc.
You seem confident in the technical aspect, but certainly if you put out work product that doesn't perform well or isn't documented well, people aren't going to proactively be coming to you with questions.
"Oh hey Alice, I got this problem with X. Do you know who can help with X?"
"I think Mike knows about X"
...
"Oh hey Mike, someone told me that you have worked with X. Is that correct? I could use some help."
Do this for every problem and you'll get a good sense of who your colleagues are and what they work with
Shadow me for a day and memorize everything I’m told to do. Hold me to each of those —- by specifically verifying how and what I did —- learning the company process along the way.
How'd that go? What were the failure modes? Who really nailed it?
One specific piece of advice is going to be to remember that your old company was your old company. Some things about the way it worked -- from its coding practices to its tooling and framework choices to its meeting structure -- were right, some were wrong, and most were just arbitrary and didn't matter in the long run. Don't be too keen to try to remake your new company in the image of the old one because that's what's familiar to you. Take some time to understand the new company and what does or doesn't work about it, and also where the existing sentiments lie.
When you do draw on your experience to offer a suggestion that you try X like they did at your old company because the Y the new company does just isn't working, you want the reaction to be that half the team has been saying it for years, but they haven't had anyone with the depth of experience with X to make the change.
From the other side, I've onboarded a lot of engineers in the past and the best ones have been "yes, and?" people. So you'd explain a process to them, they'd say yes and try to figure out what comes next. e.g. if someone explains that changes are released via a pipeline, the best on-boarders I've seen would say "yes, and what stages are in the pipeline and how do they progress?". Where possible I'd recommend the pro-active questioning approach.
Be You.
I've been at my current job for three months. It's a small startup. I went from "where is the loo" to onboarding new employees in that time. Why? Because I'm an expert in my field. The landscape changes, but your expertise are going to carry you through. I'm having to re-learn a number of things I haven't had to think about in almost 20 years, but it's all there. Give yourself time to ramp up. And, one more thing:
Ask questions. Ask until you understand. DON'T BE AFRAID TO SOUND DUMB.
I tell new coworkers and managers this: I'm going to ask questions that may sound dumb- not because I'm dumb, but because I need to be able to relate information at its banging-rocks-together level. If they don't appreciate that, then I'm in the wrong place.
This is such good advice. If you don't understand something, chances are very good that others don't.
It is important to know when to take your questions "offline". That is, don't hold up a meeting with 10 people in it while you get an understanding of component X. Take a note and follow up with the component X team directly.
I'd add: document what you learn so that other employees can learn it without asking questions. Plus you'll understand it better. If it is not confidential, ask if you can share it publicly. That'll have the double benefit of increasing the world's store of knowledge as well as the profile of the company.
The don't be afraid to sound dumb is also spot on though.
I’m in a similar position, at a big company for over 10 years after working in startups. I was technical when I got there but over time as I got more immersed in the business my tech skills have eroded. I’m now in a unique position as an executive that doesn’t translate super well to a lot of the opportunities at companies I might be interested in. I’m feeling a little stuck and I’m not even getting to interviews on anything I’ve posted for so far.
Curious if others have had this experience and how did you navigate it?
The only advice I can give (i've received a lot of good advice here) is to always interview. Always be up-to-date on the job market, with respect to skills, technologies, coding savviness, etc. Interviewing in the beginning may take a lot of your time, but if you do it consistently, it'll only helping you in future interviews. Don't be afraid of rejections, hell, even embrace rejections as a mean to get better in the future.
I was always afraid of having my skills eroded or even becoming obsolete as it got to a point where I was no longer learning new things on the job, so I had to push myself and make myself learn (most times on my own personal time). That's what pushed me to get out of my comfort zone, and do something that I know will be annoying and heck even make me scared.
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.
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.
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.
I think I'm headed somewhere similar shortly. Hopefully I have the same success as you!
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.
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.
Impostor syndrome strikes again! I think this is the reason why I end up committing what I’d consider n00b mistakes relative to my age and experience.
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.
+1 to this. A lot of young engineers stumble on this part. Heck even I stumble in this part every now and then.
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.
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.
you name it.
Enjoy!
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.
Make an effort to listen to people. Keep your ego in check - avoid saying “Well at my old company we did …” - just listen to what people are doing here and now.
I would also say try to maximise informal 1-on-1 time with other people, ask them about their work, their opinions, etc. If you are in a larger group don’t opine, just listen. If you have questions, don’t interrupt the group - use it as an opportunity to go ask the relevant person after and build a 1-1 relationship.
Try to keep a smile on your face. Avoid dark humour or joke-complaining.
Edit: Say yes to everything, at least once, for the first year. Any time anyone invites you to a drink or a talk or a meeting, just say yes.
Groupthink is when people, seeking validation from a group and to preserve harmony and cohesion, withhold their opinions causing the group to make suboptimal decisions.
If you think you will have to do this, don't join the company. Groupthink means the company doesn't foster psychological safety, which is the top predictor of team performance.
This is not only bad advice, it's probably unethical too. You are expected to work in the best interest of the company, and the company is expected to not punish people for speaking up about their ideas.
What you described works if you want to advance yourself at the expense of the company, but again, it is not ethical.
You are just exploiting information asymmetry, and anyone that likes doing that in a good faith organization should be let go. Highly political people are a waste of time.
I’m sick of this black and white attitude being spread about how displaying any kind of thoughtfulness to your coworkers or your professional life is unhealthy for you.
It is called critical thinking, collaboration and professionalism.
Isolating a new person for having a good idea is being unprofessional and passive aggressive. Using your numbers to psychologically abuse a person just for having a good idea sounds more like prison culture than a real engineering organization.
It also creates a culture of mediocrity which scares away talent, and a breeding ground for psychopathy.
Just do your job, which is to solve problems, not creating new ones. Focus on the problem to be solved.
When you are being paid by a company and acting on behalf of the company, wear the company employee hat instead of the roman politician wannabe hat.
"We hire smart people to tell us what to do" - Steve Jobs.
Those are the textbook first steps of the workplace psychopath.
Then comes establishing a network of patrons and pawns, confronting your rivals and the psychopatic ascension, where useless patrons and pawns are forgotten or even eliminated.
Obviously you and I interpreted the original comment very differently.
We should be happy living in caves and punish people that suggest anything better... until the tribe across the river with bronze weapons kills us.
yes. the key is to listen first. so it sounds like you’re in agreement with me and the GP, and everything else you said is because you want to be upset.
Such good advice. At your old company you were a known quantity so if you made a dark joke or whatnot, you got a pass: "oh, Dan is just in a crabby mood today".
At a new company you don't have that store of social capital. You're building it day by day.
I personally did everything I advised not doing in that post, and learned the lessons, so I will just tell you my experience of it, and YMMV.
For me, the downside of telling the war stories was the opportunity cost - I could have spent that time listening, and as the new joiner the information and rapport is way more valuable than the status gained from telling the story and entertaining, impressing, or educating people.
The other downside is that people are eager to please a new joiner. They might sometimes say “Yeah we should do that here! Why don’t you be in charge of it!” But this is just to please you - you don’t actually know enough yet about what is happening in the new company to know if your way will bring value. Now you are busy spearheading a tangent that may have no value rather than continuing climbing the learning curve.
If you are starting a remote gig, doing camera-on video 1 on 1s with all the people you I would encounter (and often one level above) was extremely helpful for me as it gave me a chance to introduce myself and set the context for those who were not involved in the interview process.
I would always finish by asking for advice on what it takes to be successful at X company, people loved that question and shared tips that shed light on internal culture rather than the typical platitudes. Good luck!
Strong agree on this. I also recently switched jobs and I asked this question of everyone I interviewed with. I got thoughtful answers from every single person, and several common themes stood out that convinced me the company's core values really wound their way through the fabric, rather that just being trite platitudes.
Second, realize that you will be the clueless newbie for a few months. Not in terms of tech or experience, but in terms of all those amorphous "I know how to get things done" tasks. You are going to have to sit with that and, while it won't be comfortable, it'll get better over time.
I've done this a couple of times in my career, though my longest tenure was ~8 years. My advice for "newbie oldsters" (just made that up right now) is fourfold:
* realize the value of new eyes to the company. You can see things that others don't because they are inured to their current situation. You only get to be a new employee once at each company. Enjoy that advantage, uncomfortable as it may be.
* take notes on those things that are interesting to you. Publicly document them (if they aren't) or improve the docs (if they are). Writing down something will give you experience in the domain and give you a chance to talk to folks when you ask them to review it.
* resist the temptation to prescribe in these notes or in conversations, especially early on. The team is excited to have you but if you come in and say "at OLDCO we did it this way, which is far superior" you will be wasting that excitement. The exception to this is if you see an existential threat to the company due to its practices (no backups, critical SPOFs). An open mind and asking "why" with an eye toward learning will serve you better.
* attend any social events that the new company has; as many as you can. Those non-work work events can be a pain in the butt in terms of taking time away from your personal life, but you can meet people outside of your team or even inside your team. And those informal ties can prove extremely helpful when you have a work problem in the future. ("Oh, we need to get design to sign off on that? I'll ask Joe who should be looking at it; we chatted at the Friday morning coffee a few weeks ago.")
Finally, some of this will come with time, but it usually takes 6 months to a year to have the internal credibility and confidence and knowledge to really make things happen. Take the small wins while you can and keep going.
However, 3 years ago I made a mobility move within the company to a different division. To non-experts the new role looked similar form the outside, but almost everything was different: the people, (most of) the systems, even the culture, how the work was organized and appreciated, and so on. I experienced some sort of a culture shock. One of the problems I had to address in the new role was attrition and I kept telling people to give some time to their jobs to get a better understanding of what it was about and what opportunities it offered, and fought the same battle inside with myself to walk the walk not just talk the talk.
What I kept reminding myself about was that I should not compare the new role to the old one over and over again (except when there was some specific need). Instead, I just believed that my experience would help me help others. I was still the most senior guy in the team and after understanding where the biggest needs were, I started thinking about how I can address them, and came up with ideas which I went on to implement. They were much appreciated.
Another thing that worked well for me was to put all the warnings and indirect information I had received before my move on the back seat and give everyone a chance to start with a clean slate. I was very disciplined about that and as a result I could fix some historically very tense relationships between locations. I think if you approach people in an open-minded fashion, most of them will be happy to cooperate (except those whose interest dictates the opposite).
Also, don't be afraid to ask questions even about dumb things. I found that a lot of people with some experience are happy to share their knowledge and explain things to you. Listening to them will create mutual respect. And you will also understand who knows what and who you can count on.
Just be patient with yourself and you will find that you have the skills to be good at the new place.
EDIT: fixed some grammar problems
Why?
You're a lead, you should be able to see problems a mile away. Your new company should trust your expertise to anticipate and fix problems.
Examples:
I joined a company with a Mac product that would peg the CPU for days. It was impacting sales. Took me and another developer ~6 weeks to refactor some bad design decisions in a critical area. Pegging the CPU for days dropped to 1-2 minutes. (If I wasn't allowed to fix it I was going to leave.)
I joined another company that was using a beyond end-of-life web programming language. The lead developer resisted my efforts to transition to modern Javascript, and resisted my efforts to transition to modern hosted source control. It ended poorly, although there was a lot of relief when the leadership announced that they were switching to Github. (I should have asked them to lay me off so I could collect unemployment.)
I joined a company where a small team had a project spread over 3 git repos, with tons of little dlls. Simple refactors that Visual Studio could automate would take all day. I merged everything into a single repo, and merged many small dlls into larger dlls. Build time was much shorter, and refactoring was possible. (If I wasn't able to fix the problem, I was going to leave.)
This is an opportunity to change the things you didn't like about yourself in your previous role, and reinforce the things you did. I never took vacations. I had a reputation for always being available on Slack, no matter the day, or the first person on an incident call. Those things are still important to me, but work/life balance is, too, and with no reputation, I can be whoever I want to be. I want to be quick to respond, but only when a system tells me I need to, not because I'm trolling Slack on the couch at 8pm.
Ask a lot of questions. You know enough to be hired, but nothing about the new place, so ask! Give your new peers opportunities to be experts, and eventually they will do the same to you.
Try not to live in the past. This is a place I could use work myself. Rely on the things you've learned, but realize the situation is different, and if you compare now to then, you'll be disappointed. Remember, it took 15 years to get to "then." There is a possibility that it was more than just time, but it will take time to figure that out.
Assuming best intentions, you got to the place you are by being yourself. So, do it again. Rely on your instincts. Look at the world as a recent grad starting their new job, and do it again. You think you forgot how to do it, but maybe you never really knew "how" before, you just did it. If you did it once, you can probably do it again.