How To Welcome a New Dev To Your Team

I last wrote about my experiences joining a new company and what a new developer could do to make their new job a happy job. This time I want to come at the same issue from the other side. What can you do as a developer, engineering or product manager, or founding team member do to help your new developer to hit the ground running and enjoy their new job?

I have been a new developer at two different medium-sized startups (Kyruus and Catalant) and I have been a new developer on a couple small teams, and the “lead” developer on a team of myself. Here are some things that made those experiences great and some things that could have made those experiences better. Unsurprisingly some of these things are similar to what a new developer needs to do.

Be welcoming & be approachable

These two are very similar, but it is important to think about both. Being welcoming is important in the first couple weeks as it helps new devs feel like part of the team, even if they don’t know anyone. Approachability lasts beyond the “new” phase of the job. Both are important in helping the new developer to feel that she/he can be her/his own self and communicate needs and wants.

Be clear about expectations and let them know when they are meeting them and when they aren’t

Some of my most frustrating times have been when I don’t have any idea whether or not I am living up to the expectation that the company had when the hired me, while some of my happiest times working have been when a manager told me that I was doing a great job and meeting expectations.

It seems like a funny thing to base my self-worth as a professional on whether someone else tells me how I am doing or not, but I do, and I’m sure that I’m not the only one.

This quote on Wikipedia says:

Impostor syndrome (also known as impostor phenomenon or fraud syndrome) is a concept describing high-achieving individuals who are marked by an inability to internalize their accomplishments and a persistent fear of being exposed as a “fraud”.

I don’t mean to tread on psychological territory where I don’t belong, but writing from personal experience, there are most definitely times when I feel this. I feel it in my job when I am working on something that is out of my comfort zone. I feel it as a new dad with a 4-month-old baby who depends on his parents for everything (when it feels like we know nothing). I feel it as an adult, which I don’t feel like I yet qualify for that title.

I know there are many devs who feel it too, and it is especially heavy when starting a new job. Giving genuine and real praise is an excellent way to help new devs combat the inner voice that tells them they are a fraud or that they are one bug away from being on the job search again. However it is equally important to give critical but specific constructive feedback. Specific feedback gives new devs areas of improvement to focus on and removes the ambiguity of ‘Am I doing this right, or is it just that no one telling me I’m doing it wrong?’

I want to make sure this isn’t glossed over. The praise needs to be both genuine and real. Real praise, even if just “we are glad you’ve joined the team and you are meeting expectation”, can be very meaningful. False praise really just ends up contributing to the feelings of fraud.

If your new dev is not meeting the expectations of a new hire, I think there are a couple things that you might consider. Do they know the expectations that we have? If not, can we clearly lay them out and let them know that we have some work to do, and that we are there to support them? If yes, then how can we help them meet the expectations? If you’ve tried and failed, then perhaps it wasn’t the best fit (or your new hire might actually be a fraud) and it would serve you both to move on.

My manager here at Catalant has done an excellent job at making me feel like I am contributing meaningfully and meeting the expectations that the company had of me when they hired me, and that makes me really happy about my job. I also had an excellent couple managers at my last company who consistently made me feel like I was growing and helping the team. Thanks Eric.

More than anything that either company has done for me, my managers clearly letting me know (semi-frequently) when I was meeting expectations has contributed more to my growth as a developer than anything.

Be patient

This only serves to reiterate and delve a bit more into patience. It’s easy to be patient with a new dev who comes in and just gets it and crushes cod on a daily basis, mostly because you don’t really have to be patient with them. Your patience will be tested in other ways. Their personality might be a bit different than you expected from the interview process. They might not be meeting your expectations that you have of them. They may want to do things very differently than they way your company has been working.

Be patient.

Give them a chance to assimilate a little bit. Listen to their suggestions. Consider ways you might meet them half way, or maybe part of the way.

Every employee is different, but if someone isn’t meeting expectations, it likely isn’t on purpose. Not letting them know until you let them go doesn’t help anyone. It’s probably not going to be the easiest conversation that you’ve ever had, and it will be hard to hear, but everyone will appreciate honesty and the chance to remedy the situation. They can’t address what you haven’t or won’t explain to them.

Create an environment where new devs are allowed to fail with relative safety

There’s a fine line somewhere between allowing failure to help devs grow and having prod get taken down on a weekly basis. I know that I learn best by making mistakes, however, mistakes that cause outages may not be worth the lesson learned (depending on the relative size of the lesson). New devs need to know that their best code is expected, but that they feel like making a mistake won’t mean public shaming or job loss. A few things in my experience that have helped me feel able to fail:

Knowing that I had senior developers actually spending time reviewing my PRs and work makes me feel like I probably won’t kill everything, and if I do then it’s not ALL my fault.

Creating a solid deployment process and infrastructure also can make for an excellent failure allowing environment. One of my worst experiences professionally was having to do a deployment at like 3:30 AM and having the code break LITERALLY EVERYTHING. Trying to figure out how to fix a bug at that hour under that stress was not conducive to learning from mistakes. I ended up learning a lot, but most of that learning was how much I never wanted to do that again.

At Catalant we are building a nice process of “Continuous Release”. We have a semi-robust test-suite (that is getting better by the day) that runs on all pending commits to master. We also just added a new tool to preview code branches locally against our Docker environment so that my branch can run exactly like it would in the wild. That is neat. Thanks Rick.

This is not to say this is the only way to do it, but it’s awesome to have an environment where I can learn and fail without breaking ALL THE THINGS, only a few things…

Review

Welcoming a new hire to your team can be difficult. New hires are a big investment for your team. You can give your investment the best chance to succeed and be happy when you: welcome them with open arms, are patient with their new learning curve, clearly define expectations, let them know (also clearly) when they are or aren’t meeting those expectations, and create an environment that allows for learning through the right kind of failure.

What good things and bad things have companies done for you?