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.
Don’t come in with too many ideas and no context on the org.
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.
Great points. I would say some of the most annoying new members are the ones that go around saying "you should have used [insert whatever hot tool] instead" after spending an hour learning about a project just because they read it somewhere. It can take months before you understand the decisions and context behind a software project that has been maintained for a while.
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.
Sure. But in the first six months or so, be more humble in how you voice them. Not "We should do this!" Instead, "Maybe we could look at doing it this way..."
I think it's always good to voice then humbly. Just because some has been on a project for years and is an expert doesn't mean they know everything and should be an ass about their delivery.
My $0.01: don't tell anyone if you find a way to automate something (if it's not in your job description). If you do automate something away (of your job), don't tell anyone you don't trust very much.
>My $0.01: don't tell anyone if you find a way to automate something (if it's not in your job description).
Isn'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.
Anecdotally, in my singular relevant experience I had some really long running builds that sometimes failed, because some tests (unrelated to my team) had a race condition or accessed unreliable services.
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.
Everything depends on your manager, and their manager, etc….
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.
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