Ask HN: Things to do/don't in the first week and the first month in a new job?
Looking for answers from the more experienced people here who have changed jobs multiple times in their career and were able to start making impact quickly in a new team, specially SWEs.
12 comments
[ 2.0 ms ] story [ 35.2 ms ] threadIsn't this absurd. If you found a way to automate things, shouldn't you just take CTO on call and tell him that you have found a way to improve team's productivity. I think in this way you would be adding value to the team/company, which would eventually be favorable for you during your appraisal.
I did try to get it fixed, but it was my first year in this 300+ IT personnel project and it was an already long before me known piece of technological debt.
I automated retrying those 30+ minute builds depending on which error messages popped up. Sometimes it was that, sometimes it was also another team's module version bumped that day that broke it.
It was fine for months. I joined other enginneers on hour long compilation time breaks for daily java. I never mentioned any of this to nobody. I just had to look up the progress sometimes.
One day I mentioned the fact to my direct superior. I met her at the lunch place, and confirmed that I'm doing my best having an 1,5 hour lunch because I had a glance at the 40-ish minute mark and the local build had to be redownloaded and restarted, which I automated - do I promptly used my time to quiet my mind and have a better meal than usual.
A 1,5mo later me and my 2 colleagues were laid off, and reportedly replaced by a remote team from a remote country. I am extrapolating quite a bit, but I gathered my superior taken this as a signal that we're redundant, because she overestimated the level of automation that went into this. Maybe she understood that I automated away the debug process? I don't have a straightforward answer.
I really didn't think much of that exchange until the later surprising ending was relayed to me by her. My last month there we spent wondering what went wrong. This is my best guess.
You can easily go from being the superstar player on your team to being in the worst doghouse possible, simply with a change in your manager.
Yes, I have been there and done that.
If the new manager tells you one thing in person and then a different thing gets recorded in your personnel file, that’s a really big sign that you need to pay careful attention to.
So, when it comes to things like this, you need to make sure that you are always working in the style your manager wants, and on the things they want, and not letting your attention get sidetracked on something else — even if that something else could help greatly improve your life at work.
try to figure out the codebase, find the docs and the person who maintains them.
try to figure out who wrote/maintains what part so you know who to ask for help.
Figure out if you should try to get into the middle/meat of the codebase or if you should start working on the edges. (Architecture/culture dependent).
Schedule 20-30min intro/coffee call with anyone who will accept.
Don’t try to do too much, you’re new, onboarding takes time.
Don't pass judgment on the team, it’s practices, it’s work, etc until you can establish some empathy and context for why/how things got there.
Do listen a lot. But really do this always anyway as your default mode of communicating.
Do make small improvements to the onboarding process. It’s an easy way to ship in your first week
Do find ways to make small, but meaningful improvements.
Do have a “beginners mindset”[1] regardless of what you’ve accomplished in the past.
Do appreciate what is different about this place, it’s culture, working norms, values, etc - esp the unspoken ones that might be taken for granted. Write those down for future new people.
Do schedule 1-1s with your lead and teammates. Maybe your skiplevel. Connect with them as people.
Do be open and growth oriented. Expect to not like something at first, but give it time to let it grow on you and gain context before passing judgment.
Do collaborate a lot. Pairing is caring when you’re new. Esp when remote, building together can help grow your relationship with teammates. (They should want to collaborate to help onboard you)
Do demo a lot, but make it about what the team did together in your collaboration, not about you.
Do couch your observations and ideas as questions, not strong assertions or pronouncements. It lets you probe the issue. Instead of “WE SHOULD TEST WITH PYTEST!!!” Maybe try “I notice we used pythons built in unit testing, just curious if there’s history there on how that came to be?”
Do understand how your team is measured and incentivized.
1 - https://en.m.wikipedia.org/wiki/Shoshin