One of our roundtable topics of our last French Riviera Craftsmanship Meetup was about collecting things that you shouldn't do to your newcomers as a manager. If you are just a developer, still, you shouldn't do them, but it is less likely anyway."

During our careers, we will be newcomers again and again from time to time when we change teams or jobs. This fact means that most of us will have a long list of what our manager should have done differently. Or in case we are managers ourselves, we should have done differently with the newcomers.

Obviously, this list is far from being complete! :) Some happened to me, some to others at the group, some we just thought about. Let's imagine that all of this has happened to Bob throughout his career. I hope you are not like Bob!

Your manager sits you away from the rest of team

Did it happen to you that you joined a new team and you were not seated in the office of your team? Once Bob joined a new team as a total newcomer both to the developer world and both to the company. He got his desk and he asked around who is who. There were a project manager and two devs, one of them was an intern. After a couple of days, Bob realised that these guys are never there at his meetings, not even at the standups. Finally, Bob understood that it's not just that certain parts of the team were in another office and yet other devs were in a third office, but he understood that he was actually alone from his team in that corner. Too bad. It slowed down his learning path and integration quite significantly. His manager knew that it's a bad situation, but he asked for a couple of months patience until the next floor reorganization.

Witch-hunting

Witnessing witch-hunting is never a good thing. But having such an experience as a newcomer can be even more demotivating. If you see that people are chased because of a mistake, will you take any risks or will you do the bare minimum to survive at work? It depends on the person. Bob as a newcomer saw such a scene at one of his first meetings and he's still a top-performer. Bob decided to intervene right there and confront the manager and he continued even after the meeting by calling the manager aside to make him understand what he - the manager - did was bad. Yes, Bob was newcomer only to the team and not to the corporation or to the industry. Still, it had a long-lasting effect on him, Bob still brings up this topic every once in a while. In fact, it was Bob introducing this topic at the meetup.

No mentor assigned

You might be a newcomer only to the team, knowing well the company's ecosystem, or maybe you are a very social extroverted person who knows his ways all around in just a couple of days. In those cases having a mentor might not be very important for you. But if you are a complete newbie or too introverted, having a dedicated mentor can move you forward by weeks or even months in your learning progress. Not to mention that being a mentor is an important task and also part of the learning curve. Being a mentor and having a mentor can be a real win-win task.

Choosing the right mentor is also an important management skill. Once Bob was assigned to a mentor - Mike - who was on vacation when Bob arrived. When Mike came back he sent a mail about his farewell party. Whaaaaat? - asked Bob - You were supposed to be my mentor, Mike. Mike didn't even know about it and obviously, it was not of his business anymore. He apologized and gave a quite exact but still respectful characterization of everyone in the team.

No tools given

This I already covered in my article on my imaginary perfect first day at a new job. It can be quite annoying when you are not given the tools to do your job from the first day. This includes a laptop, but also the different software, accounts and permissions. Once Bob, instead, received an 800 pages long internal documentation. Sweet!

No clear agenda

As a manager, it's your task to give Bob an agenda about his ramp up. What should be done by who and by when? Of course, if Bob has a good experience, he might figure out that this is needed and he can be proactive by asking these questions from his managers. But if Bob has to bring this up himself, it means that either his manager doesn't care enough, or he is missing some experience in integrating people into the team. The latter is better because inexperience is easier to battle than negligence. Don't forget if something gets measured it will get improved, that principle applies here too. If you have an agenda, you will inherently try to follow it and you will start contributing better. Have an ambitious but not too aggressive agenda to avoid burn-out and big disappointments in the beginning.

No clear expectations

Bob should know what is expected of him. First of all, what gets measured gets improved. So if Bob knows the expectation, most of the cases he'll do better. But clearly, if he doesn't know what is expected who he should decide what to do? Let's assume he figures it more-or-less out on his own. There are two ways ahead of him. Bob will do less and his manager will be disappointed making Bob also disappointed. Or Bob will work his ass off, most probably it will not be valued well enough and Bob will burn out already in the beginning. What is worse?

No introduction

Not everyone is a network (wo)man. If we still believe the stereotype, most of us - developers - are not. Leaving to your newcomer to explore the floor, the different teams, stakeholders, etc. is a mistake. Take a few minutes of your time, bring the new team member around and introduce him to others. You might even invite the people to the coffee room. Even if you don't go to the office in order to live your social there, knowing who is who is always a good thing.

A final question

Have you seen people who were enthusiastic when they arrived in the team, but after a while, they stopped being themselves and started to do the least possible in order to survive? What do you think went wrong? What happened to them? Any of these problems, or maybe something else?

This article has been originally published on my blog.