So you may not have a lot of experience with switching jobs yourself -- I don't myself -- but you've probably got a lot of experience being on the other side of

So you may not have a lot of experience with switching jobs yourself -- I don't myself -- but you've probably got a lot of experience being on the other side of things, being on established teams in an established company and having new people join. 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.